http://bugs.winehq.org/show_bug.cgi?id=28857
Bug #: 28857 Summary: Final Fantasy XI crashes at login Product: Wine Version: 1.3.31 Platform: x86-64 OS/Version: FreeBSD Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: llwang@infor.org Classification: Unclassified
Created attachment 37067 --> http://bugs.winehq.org/attachment.cgi?id=37067 WINEDEBUG=warn+all logs for running pol.exe with wine-1.3.29 and wine-1.3.31
Final Fantasy XI hasn't been working for me for a while. The last working version that I could find was 1.3.17. I wasn't able to find FreeBSD packages for 1.3.18 and 1.3.19, so I didn't test these.
From versions 1.3.20 to 1.3.29, it hangs after character selection and setting
up active characters on the server. A log with WINEDEBUG=warn+all for 1.3.29 is attached (first half of the attached file).
With versions 1.3.30 and 1.3.31, it crashes right after entering login information. A log with WINEDEBUG=warn+all for 1.3.31 is attached (second half of the attached file, look for "wine-1.3.31" in the file).
http://bugs.winehq.org/show_bug.cgi?id=28857
Li-Lun Wang (Leland) llwang@infor.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cdavis@mymail.mines.edu
--- Comment #1 from Li-Lun Wang (Leland) llwang@infor.org 2011-10-22 19:44:58 CDT --- After running a regression test, I found the commit that makes it crash upon login (after entering password, when it starts to check version update):
0cae7c5087f7bfa1bb48d440ebfd06588c3b9dd5 is the first bad commit commit 0cae7c5087f7bfa1bb48d440ebfd06588c3b9dd5 Author: Charles Davis cdavis@mymail.mines.edu Date: Fri Oct 7 19:56:54 2011 -0600
iphlpapi: Implement GetUdpTable() on Mac OS and the BSDs.
:040000 040000 f6e119a0e143869851621dfc2c020fce61b10b52 41f8764ce5a743bf876397832b36389ca1bdf123 M dlls
I will try another regression test to find out the commit that makes it hang after character selection.
http://bugs.winehq.org/show_bug.cgi?id=28857
--- Comment #2 from Charles Davis cdavis@mymail.mines.edu 2011-10-22 19:49:20 CDT --- What happens when FFXI crashes? Can you provide a log for that?
http://bugs.winehq.org/show_bug.cgi?id=28857
Li-Lun Wang (Leland) llwang@infor.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #37067|0 |1 is obsolete| |
--- Comment #3 from Li-Lun Wang (Leland) llwang@infor.org 2011-10-22 20:37:19 CDT --- Created attachment 37069 --> http://bugs.winehq.org/attachment.cgi?id=37069 WINEDEBUG=warn+all log for running pol.exe with wine-1.3.31
http://bugs.winehq.org/show_bug.cgi?id=28857
--- Comment #4 from Li-Lun Wang (Leland) llwang@infor.org 2011-10-22 20:37:59 CDT --- Please see the attached log. Let me know if you need more information.
http://bugs.winehq.org/show_bug.cgi?id=28857
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression Regression SHA1| |0cae7c5087f7bfa1bb48d440ebf | |d06588c3b9dd5
http://bugs.winehq.org/show_bug.cgi?id=28857
--- Comment #5 from Charles Davis cdavis@mymail.mines.edu 2011-10-22 23:22:46 CDT --- (In reply to comment #4)
Please see the attached log. Let me know if you need more information.
I'm afraid I'm going to need a bit more info than that.
Your backtrace does not have debug symbols in it. Can you build Wine with debug symbols, and try again? I'd like to know exactly where it's crashing inside the iphlpapi DLL, and that would be easier with debug symbols.
http://bugs.winehq.org/show_bug.cgi?id=28857
--- Comment #6 from Li-Lun Wang (Leland) llwang@infor.org 2011-10-22 23:29:39 CDT --- Would compiling with -g in CFLAGS be enough?
http://bugs.winehq.org/show_bug.cgi?id=28857
--- Comment #7 from Charles Davis cdavis@mymail.mines.edu 2011-10-22 23:37:48 CDT --- (In reply to comment #6)
Would compiling with -g in CFLAGS be enough?
Yes.
http://bugs.winehq.org/show_bug.cgi?id=28857
--- Comment #8 from Li-Lun Wang (Leland) llwang@infor.org 2011-10-22 23:57:41 CDT --- Created attachment 37072 --> http://bugs.winehq.org/attachment.cgi?id=37072 WINEDEBUG=+iphlpapi and backtrace with symbol
Here is the backtrace with debug symbols compiled in, along with the log with WINEDEBUG=+iphlpapi
http://bugs.winehq.org/show_bug.cgi?id=28857
--- Comment #9 from Juan Lang juan.lang@gmail.com 2011-10-23 12:12:42 CDT --- Created attachment 37082 --> http://bugs.winehq.org/attachment.cgi?id=37082 Make sure not to read past buffer returned by sysctlbyname
Does this patch help?
http://bugs.winehq.org/show_bug.cgi?id=28857
--- Comment #10 from Li-Lun Wang (Leland) llwang@infor.org 2011-10-23 14:54:34 CDT --- Created attachment 37087 --> http://bugs.winehq.org/attachment.cgi?id=37087 Crash log after applying attachment 37082
It doesn't crash right after entering the password anymore, but crashes a little later after login at a similar place.
http://bugs.winehq.org/show_bug.cgi?id=28857
--- Comment #11 from Juan Lang juan.lang@gmail.com 2011-10-23 15:02:18 CDT --- What happens if you run with +heap? This seems like some sort of memory corruption, so the commit might just happen to trigger corruption that happened earlier.
http://bugs.winehq.org/show_bug.cgi?id=28857
--- Comment #12 from Li-Lun Wang (Leland) llwang@infor.org 2011-10-23 15:41:16 CDT --- +heap slowed wine down too much, that the program thinks the network timed out before being able to trigger the crash. I don't think we'll be able to find anything in the huge log generated by +heap (25M, all trace, no err or warn). Is there another way? How about printing some debug info from within iphlpapi that can be logged with +iphlpapi?
http://bugs.winehq.org/show_bug.cgi?id=28857
--- Comment #13 from Juan Lang juan.lang@gmail.com 2011-10-23 15:44:00 CDT --- The thing is, it doesn't look like there's anything wrong with the code in iphlpapi. A buffer is allocated; it isn't null; when reading it an access violation happens. So that's why I wonder whether something else has corrupted the heap beforehand, and iphlpapi isn't the source of the problem.
http://bugs.winehq.org/show_bug.cgi?id=28857
--- Comment #14 from Charles Davis cdavis@mymail.mines.edu 2011-10-23 15:44:27 CDT --- Created attachment 37088 --> http://bugs.winehq.org/attachment.cgi?id=37088 Patch to produce additional debug info
Sure, try this patch.
http://bugs.winehq.org/show_bug.cgi?id=28857
--- Comment #15 from Li-Lun Wang (Leland) llwang@infor.org 2011-10-23 16:17:58 CDT --- Created attachment 37089 --> http://bugs.winehq.org/attachment.cgi?id=37089 additional debug log
The last lengths seem interesting.
http://bugs.winehq.org/show_bug.cgi?id=28857
--- Comment #16 from Charles Davis cdavis@mymail.mines.edu 2011-10-23 16:33:03 CDT --- (In reply to comment #15)
Created attachment 37089 [details] additional debug log
The last lengths seem interesting.
According to the log you posted, it is indeed stepping past the end of the buffer as I suspected.
What compiler are you using to compile Wine? A small test program I made based on this code runs just fine with GCC 4.2 in my FreeBSD VM.
http://bugs.winehq.org/show_bug.cgi?id=28857
Juan Lang juan.lang@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #37082|0 |1 is obsolete| |
--- Comment #17 from Juan Lang juan.lang@gmail.com 2011-10-23 16:35:57 CDT --- Created attachment 37090 --> http://bugs.winehq.org/attachment.cgi?id=37090 Make sure not to read past buffer returned by sysctlbyname
I stand corrected. In addition to Chip's question, does this patch help?
http://bugs.winehq.org/show_bug.cgi?id=28857
--- Comment #18 from Li-Lun Wang (Leland) llwang@infor.org 2011-10-23 16:41:36 CDT --- I'm using gcc (GCC) 4.2.2 20070831 prerelease [FreeBSD] on FreeBSD 8.2-STABLE. However, wine is compiled into 32-bit binary run on the 64-bit OS.
http://bugs.winehq.org/show_bug.cgi?id=28857
--- Comment #19 from Charles Davis cdavis@mymail.mines.edu 2011-10-23 16:52:00 CDT --- That's useful to know. When I compiled my test program as 32-bit, it stepped beyond the end in the same way Wine does now. And I think I know why.
On 64-bit FreeBSD, a struct xinpgen is 32 bytes long. But in 32-bit FreeBSD, a struct xinpgen is only 16 bytes long. Because the kernel is LP64, it is returning 32-byte xinpgen structures, which is bigger than the 16 bytes the loop was expecting. Because of this, the loop does not terminate like it should.
Unfortunately, I don't know how to fix this yet. Juan, any ideas?
http://bugs.winehq.org/show_bug.cgi?id=28857
--- Comment #20 from Li-Lun Wang (Leland) llwang@infor.org 2011-10-23 16:52:04 CDT --- Created attachment 37091 --> http://bugs.winehq.org/attachment.cgi?id=37091 crash log after applying attachment 37090
attachment 37090 delays the crash, but still crashes eventually at the same place.
http://bugs.winehq.org/show_bug.cgi?id=28857
--- Comment #21 from Charles Davis cdavis@mymail.mines.edu 2011-10-23 17:14:46 CDT --- (In reply to comment #19)
That's useful to know. When I compiled my test program as 32-bit, it stepped beyond the end in the same way Wine does now. And I think I know why.
On 64-bit FreeBSD, a struct xinpgen is 32 bytes long. But in 32-bit FreeBSD, a struct xinpgen is only 16 bytes long. Because the kernel is LP64, it is returning 32-byte xinpgen structures, which is bigger than the 16 bytes the loop was expecting. Because of this, the loop does not terminate like it should.
Unfortunately, I don't know how to fix this yet. Juan, any ideas?
Actually, it just occurred to me that we might not want to fix this on the Wine side. If struct xinpgen is the wrong size, other structures probably are, too.
The kernel should be well aware of when it's dealing with a 32-bit process, and should return 32-bit structures accordingly. (That's what the Mac OS kernel does.) At the very least, the 32-bit libc should be converting 64-bit structures into their 32-bit equivalents. In any case, it's time to file a FreeBSD bug.
(Note: I don't have permission to close the bug upstream, but that's normally what I would do at this point.)
http://bugs.winehq.org/show_bug.cgi?id=28857
--- Comment #22 from Juan Lang juan.lang@gmail.com 2011-10-23 17:35:38 CDT --- (In reply to comment #21)
Actually, it just occurred to me that we might not want to fix this on the Wine side. If struct xinpgen is the wrong size, other structures probably are, too.
The kernel should be well aware of when it's dealing with a 32-bit process, and should return 32-bit structures accordingly. (That's what the Mac OS kernel does.) At the very least, the 32-bit libc should be converting 64-bit structures into their 32-bit equivalents. In any case, it's time to file a FreeBSD bug.
(Note: I don't have permission to close the bug upstream, but that's normally what I would do at this point.)
Agreed, this seems very much like a FreeBSD bug.
http://bugs.winehq.org/show_bug.cgi?id=28857
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nerv@dawncrow.de
--- Comment #23 from André H. nerv@dawncrow.de 2012-01-19 13:22:15 CST --- http://lists.freebsd.org/pipermail/freebsd-emulation/2011-October/009202.htm... or the full thread at once: http://freebsd.1045724.n5.nabble.com/32-bit-binaries-e-g-wine-and-64-bit-ker...
seems problematic.
Is it possible to catch it in wine with some easy "if (sizeof(badstruct) == bad64_size)" or would it involve much more?
http://bugs.winehq.org/show_bug.cgi?id=28857
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID
--- Comment #24 from Alexandre Julliard julliard@winehq.org 2012-01-31 16:45:33 CST --- Definitely a FreeBSD bug.
http://bugs.winehq.org/show_bug.cgi?id=28857
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED CC| |adys.wh@gmail.com
--- Comment #25 from Jerome Leclanche adys.wh@gmail.com 2012-02-01 09:52:07 CST --- Closing
-
wine-bugs＠winehq.org