Hi all, I did my first bug report in a while. Unfortunately the good folks at wineHQ.org didn't like it much because Gentoo by default stripped out much of the backtrace info. I've recompiled Wine with more backtrace capabilities in it and am wondering what's considered good enough. Below are two backtraces. They may or may not be exactly the same failure but they both come from the same program doing similar things. (Testing the system hardware for compatibility.) The first one is the older one. The second is newer. My question is whether the second is considered 'good enough' to be genuinely helpful? Eventually, when I get a 'good' backtrace then I'll capture the 3 or 4 ways the program fails and submit all the data for the developers but currently I'm just trying to get the basics working well enough to be helpful. Thanks, Mark Backtrace: =>1 0x127f:0x9de9 (0x12c7:0x537a) 2 0x129f:0x5265 (0x12c7:0x538a) 3 0x129f:0x538f (0x12c7:0x53a0) 4 0x129f:0x1c8b (0x12c7:0x53d4) 5 0x129f:0x1833 (0x12c7:0x53ea) 6 0x1287:0x3945 (0x12c7:0x53fe) 7 0x1287:0x3a61 (0x12c7:0x5424) 8 0x1287:0x2e23 (0x12c7:0x5442) 9 0x1287:0x203d (0x12c7:0x5464) 10 0x1287:0x1c57 (0x12c7:0x54b0) 11 0x1287:0x11c7 (0x12c7:0x5504) 12 0x1287:0x1318 (0x12c7:0x551c) 13 0x101f:0x0468 in kernel32 (+0x7e30c) (0x12c7:0x5556) 14 0x7ee8d48e K32WOWCallback16Ex+0xce() in kernel32 (0x7dade858) 15 0x7ed0cdfe WINPROC_wrapper+0x50e() in user32 (0x7dadeb98) 16 0x7ed0f86c in user32 (+0xaf86c) (0x7dadf098) 17 0x7ed10dda in user32 (+0xb0dda) (0x7dadf0c8) 18 0x7ed10f61 in user32 (+0xb0f61) (0x7dadf768) 19 0x7ed1326f in user32 (+0xb326f) (0x7dadf7a8) 20 0x7ecd8232 in user32 (+0x78232) (0x7dadf818) 21 0x7ecdbfb9 in user32 (+0x7bfb9) (0x7dadf878) Backtrace: =>1 0x128f:0x462d (0x12c7:0x4f54) 2 0x128f:0x44f5 (0x12c7:0x5094) 3 0x128f:0x3a73 (0x12c7:0x5206) 4 0x1287:0x1e92 (0x12c7:0x5252) 5 0x1287:0x11c7 (0x12c7:0x52a6) 6 0x1287:0x1318 (0x12c7:0x52be) 7 0x101f:0x0468 __wine_call_to_16_ret() in kernel32 (0x12c7:0x52f8) 8 0x7ee8d48e K32WOWCallback16Ex+0xce() in kernel32 (0x7dad83d8) 9 0x7ed00dfe call_window_proc16+0x16e() in user32 (0x7dad8718) 10 0x7ed0386c WINPROC_CallProc32ATo16+0x101c() in user32 (0x7dad8c18) 11 0x7ed04dda call_window_proc_Ato16+0x4a() in user32 (0x7dad8c48) 12 0x7ed04f61 WINPROC_CallProcWtoA+0x181() in user32 (0x7dad92e8) 13 0x7ed0726f WINPROC_call_window+0x1df() in user32 (0x7dad9328) 14 0x7ecccbaf DispatchMessageW+0x9f() in user32 (0x7dad9368) 15 0x7ec9987f IsDialogMessageW+0x10f() in user32 (0x7dad94c8) 16 0x7ec9a22f DIALOG_DoDialogBox+0xdf() in user32 (0x7dad9528)
On Fri, Mar 7, 2008 at 3:16 PM, Mark Knecht <markknecht at gmail.com> wrote:> 16 0x7ec9a22f DIALOG_DoDialogBox+0xdf() in user32 (0x7dad9528)Hi Mark, thanks for asking! Sadly, that trace doesn't have line numbers. Perhaps that info was stripped out during install; try running the wine that's in the build directory (if you can).
If you install binaries and then "strip" then (or the installer strips them) then they are no good. You have to either: 1. Tell the installer not to strip Wine binaries when it installs them 2. Install debug package (dunno if it's available with gentoo) 3. Compile Wine yourself and do not install it - run it from the compile dir (as noted above)
According to Gentoo... Note: Some packages unfortunately handle stripping by themselves, inside the upstream provided makefiles. This is an error and should be reported. All packages should leave Portage the task of the stripping or simply restrict stripping entirely. The main exception to this are binary packages. They are usually stripped by upstream, outside of Portage control. Wine seems to be one of these packages. I tried it myself. However, they provide winedbg and it is included in the Gentoo package. Did you try running that?
Charity Abbott wrote:> Wine seems to be one of these packages. I tried it myself.Whatever you are smoking you have to really stop! Wine's install rules do NOT strip binaries. You are welcome to verify Code: ./configure && make all install Charity Abbott wrote:> However, they provide winedbg and it is included in the Gentoo package. Did you > try running that?What winedbg has anything to do with that?! Do you even have a clue what it is?
Mark Knecht wrote:> This morning I > took some time and tried to get better backtrace data. It looks better > to me. A small bit is attached below. Can someone now tell me if this > sort of data is good enough to help before I send the data to > Bugzilla?Yes that looks much better.
On Sat, Mar 8, 2008 at 10:14 AM, vitamin <wineforum-user at winehq.org> wrote:> > Can someone now tell me if this > > sort of data is good enough to help before I send the data to > > Bugzilla? > > Yes that looks much better.Yep, the 32 bit stuff has line numbers. Be sure to attach the log as a file, not inline. And you should probably also attach a +relay log. - Dan
On Sat, Mar 8, 2008 at 10:40 AM, Dan Kegel <dank at kegel.com> wrote:> > And you should probably also attach a +relay log. > - DanDoes this mean run it again but use +relay in the command line? If so could you give the correct format? I just tried this I found in Google: WINEDEBUG=+relay ./Wine-0.9.57/wine-0.9.57/wine "D:\setup.exe" &>~mark/Desktop/wine-LH_log2.txt but the output file is large, 45K lines. Maybe you want me to use some -OPTION things to make that smaller? When I get down around the failure this is what I see: 0015:Call winedos.inport(00000061,00000001) ret=7ee3f94e 0015:Ret winedos.inport() retval=00000020 ret=7ee3f94e 0015:Call winedos.outport(00000061,00000001,00000021) ret=7ee3f7c8 0015:Ret winedos.outport() retval=00000001 ret=7ee3f7c8 0015:Call winedos.outport(00000061,00000001,00000020) ret=7ee3f7c8 0015:Ret winedos.outport() retval=00000000 ret=7ee3f7c8 0015:Call winedos.inport(00000042,00000001) ret=7ee3f94e 0015:Ret winedos.inport() retval=00000091 ret=7ee3f94e 0015:Call winedos.inport(00000042,00000001) ret=7ee3f94e 0015:Ret winedos.inport() retval=000000ff ret=7ee3f94e 0015:Call KERNEL32.UnhandledExceptionFilter(7e470f10) ret=7ef96573 wine: Unhandled division by zero at address 0x127f:0x00009de9 (thread 0015), starting debugger... 0015:Ret KERNEL32.UnhandledExceptionFilter() retval=00000000 ret=7ef96573 Unhandled exception: divide by zero in 16-bit code (127f:9de9). In 16 bit mode. Register dump: CS:127f SS:12c7 DS:12c7 ES:12c7 FS:0063 GS:006b IP:9de9 SP:5254 BP:537a FLAGS:0a47( - 00 ROIZP1C) AX:0a00 BX:000e CX:04a9 DX:048d SI:001a DI:001a Stack dump: 0x12c7:0x5254: 129f 12c7 6c53 129f 5da2 0001 35f6 128f 0x12c7:0x5264: 35f6 128f 0000 0000 0000 0030 1914 0000 0x12c7:0x5274: 0000 0000 01e8 014d fec8 4ef8 1e24 1587 0258: sel=12c7 base=0040e370 limit=000067bf 16-bit rw- Backtrace: =>1 0x127f:0x9de9 (0x12c7:0x537a) 2 0x129f:0x5265 (0x12c7:0x538a) 3 0x129f:0x538f (0x12c7:0x53a0) 4 0x129f:0x1c8b (0x12c7:0x53d4) 5 0x129f:0x1833 (0x12c7:0x53ea) 6 0x1287:0x3945 (0x12c7:0x53fe) 7 0x1287:0x3a61 (0x12c7:0x5424) 8 0x1287:0x2e23 (0x12c7:0x5442) 9 0x1287:0x203d (0x12c7:0x5464) 10 0x1287:0x1c57 (0x12c7:0x54b0) 11 0x1287:0x11c7 (0x12c7:0x5504) Thanks, Mark
Dan Kegel wrote:> Why is it that people run 64 bit operating systems on their desktops? 99% of them would be happier with 32 bit OS's. > Shrug. > - Dan64-bit processors? Refusal to live in the past? 100% of other Linux apps working fine in 64-bit? Ability to address all of memory in one segment? Find myself in the 1%? I can't exactly settle on one answer. :p Sure, I *know* you can come up with a lot of reasons running 32-bit is "better" (or at least, easier for developers and average users), and even show that performance improvements for straight-64-bit are minimal in 'normal' use. But, the people running 64-bit desktops are helping the developers find problems, and make the apps "bit-agnostic". That in itself has to be worth something.
Mark Knecht wrote:> The app is an old, old game called Lighthouse:The Dark Being which I > never finished in the old days or running Win 95 or Win ME. It came > out in about 1998 and isn't sold anymore. The item that fails is a > small section of the app that tests the system for compatibility. In > the thread called "CDROM detect failed" a couple of days ago I posted > a small PNG file that showed the part of the app that fails. There are > a number of button you push to check things - OS, graphics, processor, > CDROM, etc. Two fail consistently - the CDROM and the processor.Does it even work on win2k/winxp? Have you tried first? There are more and more things that Wine does the winNT way and not win9x way. So if you have an app that worked on win9x only - most likely it won't work on Wine.