http://bugs.winehq.org/show_bug.cgi?id=19443
Summary: Wine itself segfaults when running Geneforge Product: Wine Version: 1.1.26 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: wanderer@fastmail.fm
Past versions of Wine (1.0.1 and earlier, and I think some later but I haven't confirmed that) were able to run the demo of Spiderweb Software's "Geneforge" with only cosmetic problems. I have now purchased the full version (which should be binary identical to the demo except for being registered), and updated Wine to the current latest git version. The install went fine, but now when I try to run the actual game, Wine itself dies with a segmentation fault no later (and sometimes earlier) than the moment of loading the actual game world.
I've been trying to get useful debugging information, but nothing I've done so far has been at all fruitful. The instructions on using the Wine debugger don't help in this case, as it doesn't seem to be the Windows program which is crashing, but rather the wine executable itself; my normal course in this type of situation is to fall back on gdb, but 'gdb wine Geneforge.exe' produces esoteric errors and (when those seem to be dealt with) complains that Geneforge.exe is not an ELF binary, which naturally it isn't.
What can I do to get useful debugging information to figure out why Wine is crashing?
http://bugs.winehq.org/show_bug.cgi?id=19443
--- Comment #1 from Andrew Nguyen arethusa26@gmail.com 2009-07-24 11:53:09 --- If this is a regression between two Wine versions, please perform a regression test:
http://wiki.winehq.org/RegressionTesting
http://bugs.winehq.org/show_bug.cgi?id=19443
--- Comment #2 from wanderer@fastmail.fm 2009-07-24 18:46:11 --- I've bisected all the way back to wine-1.0.1 (which was reported as working by someone else in AppDB), and the same crash still happens.
I did this without installing the compiled wine each time, of course. If this could lead to false results, then I may need to retry in a more exhaustive fashion.
If that's not likely to be a problem, however, then that means that the problem is likely in something other than Wine - and that, in turn, probably means that I need that debugging information so that I can figure out where I need to look. (The only thing I can think of at the moment are my graphics drivers, but I wouldn't expect problems there to manifest in quite this sort of way.)
What is the recomended way of getting debugging results from running the Wine executable itself, when it does not automatically provide them?
http://bugs.winehq.org/show_bug.cgi?id=19443
--- Comment #3 from Vitaliy Margolen vitaliy@kievinfo.com 2009-07-24 19:48:05 --- Attach terminal output http://wiki.winehq.org/FAQ#get_log
http://bugs.winehq.org/show_bug.cgi?id=19443
--- Comment #4 from wanderer@fastmail.fm 2009-07-25 06:07:19 --- Created an attachment (id=22604) --> (http://bugs.winehq.org/attachment.cgi?id=22604) Crash running Geneforge with git from 2009-07-25
Attached, but almost certainly completely useless; I get messages much like this with every program I run under Wine, and I got messages more or less like this even back when I didn't get the crash.
Also, there is a message which was printed in the terminal but did not get dumped into the file despite the &> redirection; that message reads simply "Segmentation fault". I am inferring that that message is being printed not by anything to do with Wine but by the system, and that what it means is that Wine itself - or something on which Wine is relying - has attempted an illegal memory access.
http://bugs.winehq.org/show_bug.cgi?id=19443
--- Comment #5 from Vitaliy Margolen vitaliy@kievinfo.com 2009-07-25 11:32:07 --- (In reply to comment #4)
Also, there is a message which was printed in the terminal but did not get dumped into the file despite the &> redirection; that message reads simply "Segmentation fault".
Enable core dumping (ulimit -c unlimited) and make it crash again. Then load that core file under gdb (gdb core) and get the backtrace (bt). Attach it here.
http://bugs.winehq.org/show_bug.cgi?id=19443
--- Comment #6 from wanderer@fastmail.fm 2009-07-25 20:00:20 --- Created an attachment (id=22619) --> (http://bugs.winehq.org/attachment.cgi?id=22619) Coredump from segfault
Gladly. (I would have done that from the beginning, except that I think this is the first time I've actually found out how to enable creation of core dumps; most information about them just assume they get created automatically.)
It's too big to attach directly, so I'm trying a URL instead. In case that also fails, try http://fraglimit.net/~wanderer/core.28477.gz.
http://bugs.winehq.org/show_bug.cgi?id=19443
--- Comment #7 from wanderer@fastmail.fm 2009-07-26 07:57:46 --- Okay, I apologize; by the time I had the core dump, I'd forgotten the "attach the backtrace, not the dump" part of the request.
Unfortunately I still don't have that attached, because nothing I've figured out so far has made gdb produce any useful information in responses to 'bt' even with the core file apparently loaded. When I try 'gdb core.28477' as you suggested, I get the usual gdb header message and then
== "/tmp/core.28477": not in executable format: File format not recognized ==
If I try 'gdb -c core.28477', I get
== [New Thread 28495] [New Thread 28494] (no debugging symbols found) Core was generated by `Geneforge.exe '. Program terminated with signal 11, Segmentation fault. #0 0x7efbe4a1 in ?? () (gdb) bt #0 0x7efbe4a1 in ?? () (gdb) ==
If I try it with $SRCDIR/wine as the program name, I get exactly the same output, except prefixed with the line
== "/home/wanderer/text/src/git/wine-regressiontest/wine": not in executable format: File format not recognized ==
because, of course, that's a symlink to a shell script which runs the actual executable. If I try it with either $SRCDIR/loader/wine or Geneforge.exe as the program name, I get
==
warning: core file may not match specified executable file. [New Thread 28495] [New Thread 28494] Core was generated by `Geneforge.exe '. Program terminated with signal 11, Segmentation fault. #0 0x7efbe4a1 in ?? () (gdb) bt #0 0x7efbe4a1 in ?? () #1 <signal handler called> #2 0x7efbdbb0 in ?? () #3 0x7ec2fbac in ?? () #4 0x7ec323d8 in ?? () #5 0x0044b642 in ?? () #6 0x0044b3a5 in ?? () #7 0x0043fc89 in ?? () #8 0x00443eae in ?? () #9 0x00442ccb in ?? () #10 0x0046725f in ?? () #11 0x7ee09f40 in ?? () #12 0xb7e2fbbd in ?? () (gdb) ==
I'm obviously missing something. Any idea what?
http://bugs.winehq.org/show_bug.cgi?id=19443
--- Comment #8 from Vitaliy Margolen vitaliy@kievinfo.com 2009-07-26 11:35:51 --- Try: gdb /home/wanderer/text/src/git/wine-regressiontest/loader/wine /tmp/core.28477
http://bugs.winehq.org/show_bug.cgi?id=19443
--- Comment #9 from wanderer@fastmail.fm 2009-07-26 11:52:26 --- That gives exactly the same output as the last example I gave. (Probably because it winds up being the same command in the end - I was just using $SRCDIR as shorthand, it wasn't in the command I actually typed.)
http://bugs.winehq.org/show_bug.cgi?id=19443
--- Comment #10 from Austin English austinenglish@gmail.com 2010-09-07 16:48:44 CDT --- This is your friendly reminder that there has been no bug activity for a year. Is this still an issue in current (1.3.2 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=19443
--- Comment #11 from wanderer@fastmail.fm 2010-09-08 08:59:57 CDT --- No, this apparently no longer occurs, using git Wine as of last night. (I say "apparently" because I'm not sure I compiled both versions of Wine the same way - the compile from last night didn't find any OpenGL libraries, but I'm at least 99% certain that OpenGL was included in the version which was crashing before.)
I hadn't tested recently because there are other bugs with this game which severely impact gameplay, to the point that it's not really worth playing; when I filed the original bug report, I had been attempting to test to see whethre these other bugs had been fixed, but apparently they remain unresolved even in the additional year.
http://bugs.winehq.org/show_bug.cgi?id=19443
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED CC| |wylda@volny.cz Resolution| |FIXED
--- Comment #12 from Wylda wylda@volny.cz 2010-09-08 09:25:20 CDT ---
No, this apparently no longer occurs...
Thank you, marking FIXED. Reopen if you find the way to reproduce in wine-1.3.2 or newer.
http://bugs.winehq.org/show_bug.cgi?id=19443
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #13 from Alexandre Julliard julliard@winehq.org 2010-09-18 13:05:47 CDT --- Closing bugs fixed in 1.3.3.
-
wine-bugs＠winehq.org