Bug 246426 - emulators/wine-devel: fixme:esync:do_esync eventfd not supported on this platform
Summary: emulators/wine-devel: fixme:esync:do_esync eventfd not supported on this plat...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Gerald Pfeifer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-05-12 23:15 UTC by VVD
Modified: 2020-05-31 00:34 UTC (History)
3 users (show)

See Also:
vvd: maintainer-feedback?
vvd: merge-quarterly?


Attachments
Fix "fixme:esync:do_esync eventfd not supported on this platform" (517 bytes, patch)
2020-05-12 23:15 UTC, VVD
vvd: maintainer-approval?
Details | Diff
Ugly hack of minidump file. (405 bytes, patch)
2020-05-14 14:05 UTC, Gen Otsuji
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description VVD 2020-05-12 23:15:53 UTC
Created attachment 214434 [details]
Fix "fixme:esync:do_esync eventfd not supported on this platform"

12.1 amd64.

$ rm -rf ~/.wine
$ winecfg
0024:fixme:esync:do_esync eventfd not supported on this platform.
002c:fixme:esync:do_esync eventfd not supported on this platform.
002c:err:seh:raise_exception Unhandled exception code c00000fd flags 0 addr 0xf600d488
0024:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0)
0024:err:seh:raise_exception Unhandled exception code c00000fd flags 0 addr 0xf600d488
$

Builded with: OPTIONS_FILE_SET+=STAGING

Found this error message "eventfd not supported on this platform" in staging patch eventfd_synchronization. 2 more patches depends on it.
Build options fixed lines with "fixme:esync:do_esync":
-W eventfd_synchronization -W server-Desktop_Refcount -W ws2_32-TransmitFile

Other error messages are from regression in 5.8: https://bugs.winehq.org/show_bug.cgi?id=49131
Comment 1 Alex S 2020-05-13 10:16:41 UTC
Does it work when compiled with devel/libepoll-shim?
Comment 2 VVD 2020-05-13 13:00:06 UTC
(In reply to Alex S from comment #1)
> Does it work when compiled with devel/libepoll-shim?
How to do this?
Didn't find option in emulators/wine-devel port.
Port libepoll-shim-0.0.20200223 installed.
Comment 3 Alex S 2020-05-13 13:48:42 UTC
(In reply to VVD from comment #2)

Something like:

CFLAGS+=	-I/usr/local/include/libepoll-shim
LDFLAGS+=	-lepoll-shim
Comment 4 VVD 2020-05-13 19:04:32 UTC
(In reply to Alex S from comment #3)
> CFLAGS+=	-I/usr/local/include/libepoll-shim
> LDFLAGS+=	-lepoll-shim

Gone:
> 0024:fixme:esync:do_esync eventfd not supported on this platform.
> 002c:fixme:esync:do_esync eventfd not supported on this platform.

But other errors - no.
Tried turn off STAGING, downgrade to 5.7 with and without STAGING - doesn't work.
Or
> 002c:err:seh:raise_exception Unhandled exception code c00000fd flags 0 addr 0xf600d488
> 0024:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0)
> 0024:err:seh:raise_exception Unhandled exception code c00000fd flags 0 addr 0xf600d488
or just eat 100% of 1 core of CPU for long - till I kill it with -9.

Do last version of wine-devel work for somebody?
Comment 5 Gerald Pfeifer freebsd_committer 2020-05-13 19:11:44 UTC
(In reply to VVD from comment #4)
> Do last version of wine-devel work for somebody?

Unfortunately likely not.  There's one patch I plan on reverting and
one I plan on backporting, which should happen by Saturday, and that
kind of breakage should not happen, even if it's a -devel port.

The STAGING option, on the other hand is experimental and I do not
recommend using it unless you want to engage upstream or hacking
things yourself.
Comment 6 Alex S 2020-05-13 19:19:26 UTC
(In reply to VVD from comment #4)

> But other errors - no.

Probably unrelated then.

> Tried turn off STAGING, downgrade to 5.7 with
> and without STAGING - doesn't work.
> 002c:err:seh:raise_exception Unhandled exception code c00000fd flags 0 addr 0xf600d488

You almost piqued my interest. Almost. Try https://github.com/shkhln/freebsd-lib32-companion-ports/blob/1aff798add915fcb787627aa50a63240bde2b5ac/emulators/wine-devel/files/patch-dlls_ntdll_signal_x86_64.c.
Comment 7 Alex S 2020-05-13 20:27:18 UTC
Looks like it's https://bugs.winehq.org/show_bug.cgi?id=49139.
Comment 8 Gerald Pfeifer freebsd_committer 2020-05-14 08:07:49 UTC
(In reply to Alex S from comment #6)
> You almost piqued my interest. Almost. Try https://github.com/shkhln/freebsd-lib32-companion-ports/blob/1aff798add915fcb787627aa50a63240bde2b5ac/emulators/wine-devel/files/patch-dlls_ntdll_signal_x86_64.c.

Are you the author of that?

This looks like really good stuff!  Would you mind submitting this
upstream?

Do you need help with that?
Comment 9 Gerald Pfeifer freebsd_committer 2020-05-14 08:16:03 UTC
(In reply to Gerald Pfeifer from comment #5)
> There's one patch I plan on reverting and one I plan on backporting

Done:  https://svnweb.freebsd.org/changeset/ports/535220

  Revert 1ccd638b1aa85fb3c43b49d69d279cd509ebdc21 from upstream which
  causes problems upon startup while, hopefully, a fix will be created
  upstream. (This changes tools/winegcc/winegcc.c)
  
  Backport 23543f20058d1655d3ad552474ce99c01bbd78ea from upstream which
  landed after the Wine 5.8 snapshot (and should be included in the next)
  and avoid crashes related to fonts.
  
  With these two changes Wine should mostly work again.

> The STAGING option, on the other hand is experimental and I do not
> recommend using it unless you want to engage upstream or hacking
> things yourself.

Keep in mind this is a -devel port and STAGING is a non-default option
(which adds code that's not in the main upstream tree).  Working with
Wine upstream and Wine Staging upstream is a great idea to ensure Wine
remains viable, or even turns better, on FreeBSD.

(I always keep an eye such that Wine keeps building on FreeBSD, but there
is more as we see here, and any help is very welcome!)
Comment 10 Alex S 2020-05-14 08:56:39 UTC
(In reply to Gerald Pfeifer from comment #8)

> Are you the author of that?

Not exactly. This is simply copy-pasted from signal_i386.c.

> Would you mind submitting this upstream?

In fact I do mind Wine's real name + email policy for submissions, otherwise it would be already there.
Comment 11 Gen Otsuji 2020-05-14 12:16:46 UTC
(In reply to Gerald Pfeifer from comment #9)
> (I always keep an eye such that Wine keeps building on FreeBSD, but there
> is more as we see here, and any help is very welcome!)

Hello, I want help as possible as I can somehow.

I sent the wineHQ to two patches.
https://bugs.winehq.org/show_bug.cgi?id=49139
https://bugs.winehq.org/show_bug.cgi?id=49155

I think the first patch is a workaround or even a solution of the regression of
wine on FreeBSD Version 5.7 and 5.8.
second patch is a patch that is avoiding a crash of some application
( null pointer exception )

I hope this will help.

Regards
Comment 12 Alex S 2020-05-14 13:01:56 UTC
(In reply to Gen Otsuji from comment #11)

Now, that is interesting. How did you find the null pointer? I don't remember ever seeing any reasonable backtraces from amd64 Wine.
Comment 13 Gerald Pfeifer freebsd_committer 2020-05-14 13:10:44 UTC
(In reply to Gen Otsuji from comment #11)
> Hello, I want help as possible as I can somehow.
>
> I sent the wineHQ to two patches.
> https://bugs.winehq.org/show_bug.cgi?id=49139
> https://bugs.winehq.org/show_bug.cgi?id=49155

This is cool, Gen!

From my experience Wine seems to be accepting patches by mail (only),
following some guidelines such as including a Signed-off-by: line:

  https://wiki.winehq.org/Submitting_Patches

Can you give that a try?  Happy to lend a helping hand in case - feel
free to drop me a note by mail at gerald@pfeifer.com and I'll be happy to.
Comment 14 Gen Otsuji 2020-05-14 14:05:39 UTC
Created attachment 214492 [details]
Ugly hack of minidump file.
Comment 15 VVD 2020-05-14 14:24:15 UTC
Last update allow to run winecfg, but
> 0024:fixme:esync:do_esync eventfd not supported on this platform.
> 002c:fixme:esync:do_esync eventfd not supported on this platform.
still here like a warnings.

What about add this as dependency of STAGING: 
> CFLAGS+=	-I/usr/local/include/libepoll-shim
> LDFLAGS+=	-lepoll-shim

Something like:
> STAGING_LIB_DEPENDS=    libtxc_dxtn.so:graphics/s2tc libepoll-shim.so:devel/libepoll-shim
Don't know how to add CFLAGS:
> STAGING_CFLAGS=         -I/usr/local/include/libepoll-shim
or
> .if ${STAGING:M}
> CFLAGS+=	-I/usr/local/include/libepoll-shim
> .endif
Comment 16 Gen Otsuji 2020-05-14 14:34:13 UTC
(In reply to Alex S from comment #12)
> Now, that is interesting. How did you find the null pointer? I don't remember 
> ever seeing any reasonable backtraces from amd64 Wine.

Hi. Alex S
Ummm, I tried to regenerate the scene of debugging, but I've lost.
I could not regenerate the 0xC0000005 error or 0xC00000FD error.
I didn't know that bug is null pointer exception bug , before I tried 
try and error.

I used the crash message file that the application generated.
In that message, code(I think it was 0xC0000005 or 0xC00000FD)
and the address(0x7bXXXXXX). that address is kernelbase image-base.
then objdump -D kernelbase.dll.so and the function name (LocalLock) revealed,
(if image-base linker option is not there , I don't know how to calculate it, though),
and after that in the function looking carefully, printf debugging, 
and I tried some try and erro and I've found that bug, luckily.

P.S.
And I'm using patch "Ugly hack of minidump file." attached above.
usage is "winedbg /tmp/minidump.mdmp"
Comment 17 Alex S 2020-05-14 14:47:16 UTC
(In reply to Gen Otsuji from comment #16)

Thank you. I'll give that a try with some other crashes.

(In reply to VVD from comment #15)

Warnings are completely harmless, while linking epoll-shim might expose bugs in it. On the other hand, esync is supposed to be faster than regular Wine, so there some benefit to getting it working. (Assuming the performance difference exists on FreeBSD; it would be nice to check that.)
Comment 18 Gen Otsuji 2020-05-14 15:03:05 UTC
(In reply to Gerald Pfeifer from comment #13)

Thank you, Gerald. I'll mail to you by tomorrow night.
I'll give it a try. thank you.
Comment 19 Gen Otsuji 2020-05-14 21:21:48 UTC
(In reply to Gen Otsuji from comment #16)
I again try to regenerate the bug
I moved all the files/patch-* somewhere in the $HOME,
And then svnlite update /usr/ports/emulators/wine-devel .
and delete STAGING option.
and build again.

So, I've regenerated the bug!

And following is the summary of 
what I did after encounted this bug.
(only the right paths omitted unnecessary things).

The application generated the Crash infomation.
Unfortunately there wasn't backtrace.

The info has the line of
Exception   : C00000FD at 000000007B058D66 NA to 0000000000000000
It is stack over flow error(?) at 0x7b058d66

7b058d66 is an address near the kernelbase
(EXTRADLLFLAGS has -Wl,--image-base,0x7b000000 in Makefile.in)

so objdump -d kernelbase.dll.so | less +/7b058d66
this search goes well and
the address is in the 000000007b058cf0 <LocalLock>: function.

so I grep'ed the LocalLock in kernelbase directory, and hit memory.c.
And then I try to understand the HLOCAL, hmem,is_pointer(),__TRY,__EXCEPT_PAGE_FAULT, and so on with grep'ing.
And I also put the debugging info fprintf(stderr,"HELLO %d\n",__LINE__).
every where in that function, (I recommend don't do this in __TRY block.:-)
And finally I find the *p|=0 (if this p is null?)

P.S.
> 0024:fixme:dbghelp:MiniDumpWriteDump NIY MiniDumpWithHandleData
from this line that wine has generated, I found the minidump stuff.
but where is the writed dump?
Comment 20 Gen Otsuji 2020-05-14 21:30:26 UTC
(In reply to Gen Otsuji from comment #19)
And also just in case,
I grep'ed the code that has "is_pointer(XX)" but "if(XX==NULL)" doesn't exist.
because this hit another codes, I've added it in the patch just in case.
Comment 21 Alex S 2020-05-14 23:38:50 UTC
(In reply to Gen Otsuji from comment #19)

Thank you again. That clarifies a few things.

> So, I've regenerated the bug!
> ...
> Unfortunately there wasn't backtrace.

Can you add a reproducer to your bug report on bugs.winehq.org? What you found is likely a consequence of some bug, rather than the actual root case and Wine developers would almost certainly be interested in double checking it and maybe even analyzing it further. 

> from this line that wine has generated, I found the minidump stuff.
> but where is the writed dump?

As as far as I can see, there aren't any minidumps by default. This is controlled by the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug registry key. "Debugger"="winedbg --auto %ld %ld" (default) prints backtrace on console, something like "Debugger"="winedbg --mindump oops.dump %ld %ld" would produce a minidump either in the working directory or the directory with the crashed executable (not sure which one). Of course, if automatically printed backtrace isn't useful, minidump wouldn't be useful as well — it's the same information after all.
Comment 22 Alex S 2020-05-15 01:29:37 UTC
(In reply to Alex S from comment #21)

> root case

s/case/cause/
Comment 23 Gen Otsuji 2020-05-15 02:20:56 UTC
(In reply to Alex S from comment #21)
Hi, Alex.
> Can you add a reproducer to your bug report on bugs.winehq.org?

In fact, the reproducer of this bug is a certain proprietary software(exe):
metatrader5 5.00 build 2361 .
I want to know how to add the reproducer.
I haven't written the test application(exe) for reproducing the bug,
but I clicked the menu(Tools) of that exe running and clicked a certain
always the same sub-menu(Options (Ctrl+O)) it has crashed,
and generates the Crash info.

> What you found is likely a consequence of some bug, rather than the actual
> root cause 

I think it depends on software but true, because with the collection of
the patches in my files/ directory without the "kernelbase/memory.c patch",
I couldn't reproduce the bug (like my trial in comment #16).
Clicking the sub-menu appeared to be going well.
But I think bug-fix may be protected by double or more walls.
So, Just in case some software calling barelly LocalLock(!) with null,
this patch'es turn. :-)

> and Wine developers would almost certainly be interested in double checking
> it and maybe even analyzing it further. 
the application is metatrader5 5.00 build 2361.
(and the metaeditor5 would not compile(Internal compiler error).)

> This is controlled by the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows 
> NT\CurrentVersion\AeDebug registry key.
> "Debugger"="winedbg --auto %ld %ld" (default) prints backtrace on console,
> something like "Debugger"="winedbg --mindump oops.dump %ld %ld" would produce
> a minidump either in the working directory or the directory with the crashed
> executable (not sure which one). Of course, if automatically printed backtrace
> isn't useful, minidump wouldn't be useful as well — it's the same information > after all.

I wrote following line to the system.reg

[Software\\Microsoft\\Windows NT\\CurrentVersion\\AeDebug] 1588843654
#time=1d62451bdaae8ac
"Auto"="1"
"Debugger"="winedbg --mindump oops.dump %ld %ld"

But I don't know why there isn't oops.dump, and --auto doesn't print backtrace on console.


Thank you.
Comment 24 Gen Otsuji 2020-05-15 02:34:35 UTC
(In reply to Gen Otsuji from comment #19)
shame.
s/writed/written/
Comment 25 Gen Otsuji 2020-05-15 03:08:48 UTC
(In reply to Alex S from comment #21)
> Can you add a reproducer to your bug report on bugs.winehq.org? 
I tried: https://bugs.winehq.org/show_bug.cgi?id=49155#c2
Comment 26 Alex S 2020-05-16 15:01:10 UTC
(In reply to Gen Otsuji from comment #25)

I just realized in your case null pointer dereferences are to supposed to be catched by __EXCEPT_PAGE_FAULT macro (didn't pay attention to that part at a first reading), which is precisely what the previously mentioned signal_x86_64.c patch fixes.
Comment 27 Gen Otsuji 2020-05-17 10:14:34 UTC
(In reply to Alex S from comment #26)
> I just realized in your case null pointer dereferences are to supposed to be 
> catched by __EXCEPT_PAGE_FAULT macro (didn't pay attention to that part at a 
> first reading), which is precisely what the previously mentioned 
> signal_x86_64.c patch fixes.

Yes, with your signal_x86_64.c patch, and without my memory.c patch
(which is very harmful and danger), things go right. the error disappeared.
Thank you very much.

And because I'm so happy, I introduced your patch to wine-devel mailing list.
I'm very sorry without contacting you in advance.
Comment 28 Alex S 2020-05-17 19:12:17 UTC
(In reply to Gen Otsuji from comment #27)

> And because I'm so happy, I introduced your patch to wine-devel mailing list.

Did you? I don't see it.

> I'm very sorry without contacting you in advance.

It's a straightforward copy-pasted code with zero changes, so you don't need my permission anyway (from the copyright point of view). That doesn't apply to every patch, but this one is definitely trivial.
Comment 29 Gen Otsuji 2020-05-18 10:59:36 UTC
(In reply to Alex S from comment #28)
> > And because I'm so happy, I introduced your patch to wine-devel mailing list.
> 
> Did you? I don't see it.

Yes. It's appeared in th archive.

> 
> > I'm very sorry without contacting you in advance.
>
> It's a straightforward copy-pasted code with zero changes, so you don't need my
> permission anyway (from the copyright point of view). That doesn't apply to
> every patch, but this one is definitely trivial.

I'm relieved to hear that.
Thank you very much.
Comment 30 Gerald Pfeifer freebsd_committer 2020-05-31 00:34:15 UTC
Closed based on various improvements both upstream and via backports for
the last two snapshots / versions of wine-devel.

Thanks to all of you who helped!