FS#45199 - [wine] Unhandled page fault

Attached to Project: Community Packages
Opened by Mika Attila (SneakySnake) - Thursday, 04 June 2015, 09:13 GMT
Last edited by Sven-Hendrik Haase (Svenstaro) - Friday, 11 December 2015, 17:15 GMT
Task Type Bug Report
Category Packages: Multilib
Status Closed
Assigned To Florian Pritz (bluewind)
Sven-Hendrik Haase (Svenstaro)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 20
Private No

Details

Running a windows executable with wine 1.7.44 crashes with "Unhandled page fault".
Here is output for running `wine explorer`:

wine: created the configuration directory '/home/snake/.wine'
wine: Unhandled page fault on write access to 0x00000caa at address 0x7f70c501ee7f (thread 000b), starting debugger...
err:seh:start_debugger Couldn't start debugger ("winedbg --auto 10 28") (2)
Read the Wine Developers Guide on how to set up winedbg or another debugger
err:module:attach_process_dlls "gdi32.dll" failed to initialize, aborting
err:module:LdrInitializeThunk Main exe initialization for L"C:\\windows\\system32\\explorer.exe" failed, status c0000005
err:ole:CoGetClassObject class {71f96385-ddd6-48d3-a0c1-ae06e8b055fb} not registered
err:ole:CoGetClassObject no class object {71f96385-ddd6-48d3-a0c1-ae06e8b055fb} could be created for context 0x1
err:explorer:make_explorer_window Could not obtain an instance of IExplorerBrowser

wine 1.7.43 works fine.
This task depends upon

Closed by  Sven-Hendrik Haase (Svenstaro)
Friday, 11 December 2015, 17:15 GMT
Reason for closing:  Fixed
Additional comments about closing:  Closing for now as a wine dev said it's fixed.
Comment by Zuyi Hu (hzy) - Thursday, 04 June 2015, 16:33 GMT
I think this problem was caused by gcc 5.1, I have rebuilt this package with gcc 4.9 and it works fine.
Comment by Sven-Hendrik Haase (Svenstaro) - Friday, 05 June 2015, 05:04 GMT
Try rel -2. If it works, it's going to be a little slower performance-wise than the last version until https://bugs.winehq.org/show_bug.cgi?id=38653 is fixed.
Comment by Gerhard Bogner (slashME) - Friday, 05 June 2015, 11:14 GMT
rel-2 works for me.
Comment by Mika Attila (SneakySnake) - Friday, 05 June 2015, 11:23 GMT
(OP) Release 2 works here.
Comment by Gustavo Alvarez (sl1pkn07) - Friday, 05 June 2015, 14:10 GMT Comment by Steven Honeyman (stevenhoneyman) - Friday, 05 June 2015, 14:53 GMT
Release 2 seems to work only *after* running explorer in WINE at least once.

Example: WINEPREFIX=/ramdisk/test/3 wine notepad
(where /ramdisk/test is owned by you and /ramdisk/test/3 does not exist yet)

Comment by Steven Honeyman (stevenhoneyman) - Friday, 05 June 2015, 14:57 GMT
Ah, then winecfg doesn't open. I get:

Unhandled exception: page fault on read access to 0x00000000 in 64-bit code (0x00007fde9697b2c4).
fixme:dbghelp:elf_search_auxv can't find symbol in module

And "my computer" is completely empty in notepad.
Comment by Sheng Yu (magicfish1990) - Friday, 05 June 2015, 19:33 GMT
rel-2 still not work for me.
Unhandled page fault and initialization error.
Comment by Thomas Weidner (thomas001le) - Friday, 05 June 2015, 20:46 GMT
rel-2 also not working here, some programs work, others crash...initialization of a fresh .wine directory causes reproducable crashes
Comment by nerdix (nerdix) - Saturday, 06 June 2015, 11:00 GMT
Same here:

multilib/wine 1.7.44-1

$> winecfg
err:seh:call_stack_handlers invalid frame 7fff851b5730 (0x142000-0x240000)
err:seh:raise_exception Exception frame is not in stack limits => unable to dispatch exception.


multilib/wine 1.7.44-2:

$> winecfg
wine: Unhandled page fault on read access to 0x00000000 at address 0x7f214597d2c4 (thread 0009), starting debugger...


downdrading to multilib/wine 1.7.43-1 works



Comment by Gerhard Bogner (slashME) - Saturday, 06 June 2015, 11:10 GMT
I can confirm that while most of the apps I use work with rel-2 (in an existing environment), winecfg does indeed fail to start. (The output of $> winecfg is attached.)
Comment by Daniel Kamil Kozar (XAVeRY) - Monday, 08 June 2015, 06:03 GMT
Issue is known upstream, and most probably related to a regression in gcc 5.1. See https://bugs.winehq.org/show_bug.cgi?id=38653 .
Comment by tj (firekage) - Monday, 08 June 2015, 21:32 GMT
Same error here. I posted it on WineHQ and they said that this is Arch package version problem. I also can't run for an example winecfg with the same error:
[code][firekage@arch_desktop ~]$ winecfg
wine: Unhandled page fault on read access to 0x00020000 at address 0x7f29d4578bbe (thread 0013), starting debugger...[/code] also apps that had virtual desktop window now don't have it at all. I run stema with virtual window and it was launched in this window, now it launches without it as "native" Arch apps (games does not work).


Sorry - don't know how to attach file here.
Comment by Dennis Busch (Dennis) - Friday, 12 June 2015, 05:37 GMT
Attached is the output of running winecfg here. In addition to that, the information string at the bottom in the "Program Error Details" dialog which pops up appears garbled (containing many empty rectangles as if the strings raw bytes are not decoded correctly).
Comment by Moabit (Moabit) - Friday, 12 June 2015, 05:54 GMT
Here is a screenshot when winecfg is run. Also note the horrible font rendering, which I experience in other wine applications (and is why I tried winecfg in the first place).

http://i.imgur.com/ndCK09H.png
Comment by tj (firekage) - Friday, 12 June 2015, 10:44 GMT
Yes, i have the same font rendering just like you. Can't read it, use it.
Comment by Joakim Hernberg (jhernberg) - Saturday, 13 June 2015, 13:21 GMT
FWIW, 64bit reaper is also broken with 1.7.44-2 for me. Seems to have problem displaying dialogboxes, including the updating wineprefix one. Fonts seem messed up too... Any chance that would could get a gcc-multilib-49 package (and dependencies), until this is fixed upstream?
Comment by Gustavo Alvarez (sl1pkn07) - Saturday, 13 June 2015, 13:32 GMT
anyone has tried this? https://bugs.archlinux.org/task/45215

working for me with GCC 5 with wine-staging (1.7.44 and older), i'm not sure if works with vanilla wine

tested with some programs (share, perfectdark, avisynth, virtualdub, etc) and games like World Of Tanks and GuildWars2
Comment by Joakim Hernberg (jhernberg) - Saturday, 13 June 2015, 14:48 GMT
Yes, adding export CFLAGS="${CFLAGS/-O2/} -O0" and export CXXFLAGS="${CXXFLAGS/-O2/} -O0" to the buildscript appears to fix my issues after superficial testing. Looking at /usr/bin/makepkg it appears that using the !buildflags option does something completely different. Gonna run my problem application for a while now, to see that nothing else pops up.
Comment by Daniel Kamil Kozar (XAVeRY) - Saturday, 13 June 2015, 14:55 GMT
Changing -O2 to -O0 works for wine 1.7.45 as well. At least winecfg and wine explorer work without any issues, I haven't tested any further than that. It would be good to know the performance impact that such a change carries.

Also, building 1.7.45 might fail : if it does, apply the patch posted here - https://bugs.winehq.org/show_bug.cgi?id=38713
Comment by Joakim Hernberg (jhernberg) - Saturday, 13 June 2015, 15:08 GMT
FWIW, I just built multilib wine (with -rt patch) 1.7.45. I have libunwind installed but ran into no linking problem.
Comment by Joakim Hernberg (jhernberg) - Sunday, 14 June 2015, 10:42 GMT
After testing my target app for a while (64bit reaper), it appears that adding export CFLAGS="${CFLAGS/-O2/} -O0"; export CXXFLAGS="${CXXFLAGS/-O2/} -O0"; to the buildscripts solves my issues, while using !buildflags doesn't appear to fix anything.

As far as I am concerned you can implement this fix and close the bug.

FWIW, I implemented it yesterday for wine-rt in the AUR, and although there aren't all that many users, no one has cried foul yet.
Comment by tj (firekage) - Wednesday, 17 June 2015, 09:15 GMT
Could somebody write how to add this fix to buildscripts? I would learn something new, but i'm not an expert when it comes to job such like this.
Comment by Sven-Hendrik Haase (Svenstaro) - Wednesday, 17 June 2015, 13:53 GMT
I built 1.7.45 with -O0. That's slow as crap but maybe it works a bit better. Please report results.
Comment by nerdix (nerdix) - Wednesday, 17 June 2015, 14:06 GMT
Thank you for the new package.
I confirm 1.7.45-1 is working here.
Comment by Moabit (Moabit) - Thursday, 18 June 2015, 00:39 GMT
1.7.45-1 works fine in terms of launching, although I still have the font rendering regression. This might be unrelated, although it occurred at the same time as this bug.

http://i.imgur.com/pqshYZT.png
Comment by Joakim Hernberg (jhernberg) - Thursday, 18 June 2015, 08:41 GMT
FWIW, I have been running reaper+plugins with wine-rt 1.7.45 compiled with -O0 for a few days now. No signs of any troubles, the problems with displaying dialog boxes is gone, the huge fonts are gone, and wineconf also runs fine on x86_64. Haven't tried many other programs though.

I guess the proper solution to this problem would be to create gcc compatibility packages, so that we can build wine with the old gcc (until upstream fixes the problem)..
Comment by Gustavo Alvarez (sl1pkn07) - Wednesday, 09 December 2015, 19:16 GMT
  • Field changed: Percent Complete (100% → 0%)
https://bugs.winehq.org/show_bug.cgi?id=38653#c23 says it gcc 5.3 will fix this issue . now, in arch, gcc 5.3 is in testing. time to try if gcc 5.3 solve the wine optimization problem?
Comment by Sven-Hendrik Haase (Svenstaro) - Friday, 11 December 2015, 16:58 GMT
Does this persist?

Loading...