[Bug 38636] New: Golang programs hang

https://bugs.winehq.org/show_bug.cgi?id=38636

Bug ID: 38636
           Summary: Golang programs hang
           Product: Wine
           Version: 1.7.38
          Hardware: x86-64
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: -unknown
          Assignee: [e-mail]
          Reporter: [e-mail]
      Distribution: ---

Created attachment 51547
  --> https://bugs.winehq.org/attachment.cgi?id=51547
Log file with WINEDEBUG=+all

I've tried on several occasions to run Golang compiled programs.  I've tried
cross-compiled programs and programs compiled directly under Windows.  The
results are the same.  Things that involve "asynchronous" interaction
frequently hang.

Here is a dirt simple example:

package main

import (
  "log"
  "net/http"
)

func main() {
  log.Printf("Hello");

resp, err := http.Get("http://www.google.com/")
  if err!=nil {
    log.Printf("Error: %v", err)
  } else {
    log.Printf("Response: %v", resp)
  }

log.Printf("Done");
}

I'm attaching a log for this program with WINEDEBUG set to +all (since I have
no idea how to filter it down).  Since the output was enormous, I truncated it
to the last 1000 lines.  If you need more, let me know.

Any suggestions on how to workaround this or help to debug it?  I don't know
much about WINE, but I'll gladly help since this issue has really been a thorn
in my side.

If you want to build the executables under Linux, I posted a short guide to
making this work at:

https://groups.google.com/forum/#!searchin/golang-nuts/tiller/golang-nuts/Al...

I set the following environment variables before compiling:

export GOOS=windows;
export GOARCH=386;
export CGO_ENABLED=1;
export CXX=i686-w64-mingw32-g++;
export CC=i686-w64-mingw32-gcc

I hope I covered everything.

Thanks.

[Bug 38636] Golang programs hang

https://bugs.winehq.org/show_bug.cgi?id=38636

Qian Hong  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 38636] Golang programs hang

https://bugs.winehq.org/show_bug.cgi?id=38636

--- Comment #1 from Michael Tiller  ---
I should point out there is an extensive discussion of this issue in various
places.  I don't pretend to know all the details, but it seems like it has to
do with how the Go runtime requests system time information via the Windows
API.

Here are some links to discussions about the interactions between the Go
runtime and Wine:

https://groups.google.com/forum/#!topic/golang-nuts/nhJOw71rw7k

https://bugs.winehq.org/show_bug.cgi?id=38272

[Bug 38636] Golang programs hang

https://bugs.winehq.org/show_bug.cgi?id=38636

--- Comment #2 from Qian Hong  ---
Hi Michael Tiller,

Thanks for the bug report.

I can confirm your bug, I can also confirm this is a duplication of  bug 38272,
which is a duplication of  bug 29168.
I tried the hack attached in https://bugs.winehq.org/attachment.cgi?id=51589 ,
and it works both for your test case and the test case in bug 38272.

It's a tricky bug though ;-)

[Bug 38636] Golang programs hang

https://bugs.winehq.org/show_bug.cgi?id=38636

--- Comment #3 from Nikolay Sivov  ---
Regarding Go runtime it would be interesting to test if public timer API works
accurate/fast enough with Wine. Discussion starts at
https://bugs.winehq.org/show_bug.cgi?id=38272#c6. If mentioned functions are
good enough it makes sense for Go to start using them on Windows, and avoid
shared memory. But again, it should interest someone from Go project to test
it.

[Bug 38636] Golang programs hang

https://bugs.winehq.org/show_bug.cgi?id=38636

--- Comment #4 from Michael Tiller  ---
Qian,

Thanks for looking into this.  But I'm not quite sure how to interpret your
response.  You linked to a patch (that apparently works).  Is patch likely to
be folded into Wine at any point? (or, perhaps it has already?!?).

If not, does that mean I'm left having to build a special purpose version of
Wine for this case?

P.S. - I will mention Nikolay's suggestion to the Go community to remind this
off this API issue.  In the past, there has been resistance to modifying Go in
a way that some perceive as a workaround for Wine.  But the line is a bit fuzzy
here.

Thanks!

[Bug 38636] Golang programs hang

https://bugs.winehq.org/show_bug.cgi?id=38636

--- Comment #5 from Qian Hong  ---
Hi Michael,

(In reply to Michael Tiller from comment #4)
> Thanks for looking into this.  But I'm not quite sure how to interpret
> your response.  You linked to a patch (that apparently works).  Is patch
> likely to be folded into Wine at any point? (or, perhaps it has already?!?).

I guess the patch I mentioned won't be accepted by Wine, it's a bit too hacky,
also I'm not sure if there would be some unexpected side effect. That hack is
just a proof of concept to show what's wrong.

If you don't mind build Wine by yourself, you can certainly try that patch, see
http://wiki.winehq.org/BuildingWine and patch Wine by yourself, maybe that
could be a temporary solution for you?

[Bug 38636] Golang programs hang

https://bugs.winehq.org/show_bug.cgi?id=38636

Sebastian Lackner  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 38636] Golang programs hang when using time.Sleep() and time.Now() (KSYSTEM_TIME members in KUSER_SHARED_DATA are not updated)

https://bugs.winehq.org/show_bug.cgi?id=38636

Anastasius Focht  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |[e-mail]
         Resolution|---                         |DUPLICATE
            Summary|Golang programs hang        |Golang programs hang when
                   |                            |using time.Sleep() and
                   |                            |time.Now() (KSYSTEM_TIME
                   |                            |members in
                   |                            |KUSER_SHARED_DATA are not
                   |                            |updated)

--- Comment #6 from Anastasius Focht  ---
Hello folks,

since you already mentioned bug 38272 in comment #1 the chance was pretty much
100% of being an exact dupe.

Please refrain from creating alternate discussion thread here, bypassing
existing tickets/discussion threads. This leads to fragmentation = harmful.

Resolving this as dupe of bug 38272 ("binaries produced by Go 1.4+ compiler
hang when using time.Sleep() and time.Now() (KSYSTEM_TIME members in
KUSER_SHARED_DATA are not updated)").

Bug 29168 is the one that collects all kinds of apps/games ("Multiple games and
applications need realtime updates to KSYSTEM_TIME members in KUSER_SHARED_DATA
(Star Wars: The Old Republic game client, GO 1.4+ runtime)").

Regards

*** This bug has been marked as a duplicate of bug 38272 ***

[Bug 38636] Golang programs hang when using time.Sleep() and time.Now() (KSYSTEM_TIME members in KUSER_SHARED_DATA are not updated)

https://bugs.winehq.org/show_bug.cgi?id=38636

--- Comment #7 from Michael Tiller  ---
Anastasius,

(In reply to Anastasius Focht from comment #6)
> Hello folks,
>
> since you already mentioned bug 38272 in comment #1 the chance was pretty
> much 100% of being an exact dupe.

It may very well be that these bugs are duplicates.  I am not at all familiar
with Wine so I have no way of making that determination.  The fact that both
bugs happen to involve Go is, to me, hardly a basis for claiming that there is
a "100% of being an exact dupe".  They deal with completely different aspects
of the Go runtime (clocks vs. http).

I'm not arguing with you that they are dupes.  As I said, I'm not expert enough
to say.  But I am arguing with your implication here that reporting this bug
separately was a waste of time and/or sloppy on my part.  Think about it this
way, if somebody comes along and has a problem with Python do you want them to
say "Oh, I see there is another bug in here about Python, but for a program
that is doing something completely different...It must be the same bug".  They
will either not report it or they'll add it on to some other issue for which it
is completely inappropriate and confusing.  It is much easier to mark one
ticket as a duplicate of another than it is to sort out the confusion of
multiple people arguing about multiple bugs under the same ticket.

It takes time to localize an issue and create reproducible bug reports.  If you
think it is a dupe, then mark it so.  But don't blame people who are reporting
the bug for not knowing enough about the internals of WINE to completely triage
the issues.

We all have a role to play in this eco-system.  I did my best to do my part and
minimize confusion rather than jumping to conclusions based on my limited
knowledge.

[Bug 38636] Golang programs hang when using time.Sleep() and time.Now() (KSYSTEM_TIME members in KUSER_SHARED_DATA are not updated)

https://bugs.winehq.org/show_bug.cgi?id=38636

Ken Sharp  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #8 from Ken Sharp  ---
Closing