The wine version of riched20 fails an assertion when starting StreamboxVCR
$ wine .wine/drive_c/Program\ Files/StreamboxVcrSuite2/StreamBoxVCR1Beta31/vcr_31turbo.exe fixme:ole:CoRegisterMessageFilter stub fixme:ole:CoCreateInstance no classfactory created for CLSID {4955dd33- b159-11d0-8fcf-00aa006bcc59}, hres is 0x80040154 err:ole:ITypeInfo_fnInvoke did not find member id fffffdfa, flags 4! err:ole:ITypeInfo_fnInvoke did not find member id fffffdfb, flags 4! fixme:richedit:RichEditANSIWndProc WM_SETFONT: stub wine-pthread: run.c:522: ME_CalcRunExtent: Assertion `size.cx' failed. fixme:ole:ITypeInfo_fnRelease destroy child objects
Along with a popup dialogue box from the visual C++ runtime library indicating abnormal program termination. The file run.c appears to be part of riched20, and indeed overriding the load order to native only for that DLL allows the program work.
All reasonably standard debugging so far, and I went for some more logging to aid tracing the problem (or to log in bugzilla when it all gets too hard for my skill level ;-) )
$ WINEDEBUG="+relay" wine .wine/drive_c/Program\ Files/StreamboxVcrSuite2/StreamBoxVCR1Beta31/vcr_31turbo.exe 0009:Call kernel32.__wine_kernel_init() ret=55727d9e Segmentation fault
Shortest relay trace I've ever had! But I'm not really sure where to go from here... Running GDB on it gives me no useful results. I have an AMD64 box running Fedora Core 3 and wine is the latest from CVS.
I'm going to try some other tracing to look at the riched problem, but +relay crashing seems serious to me.
Adrian
This a known bug. head to http://bugs.winehq.org/show_bug.cgi?id=2924 for more info and a workaround..
We are waiting on the person that made this patch to post a fixed patch..
Alexandre.. This is generating a lot of bug reports, is there a chance we could remove it for now, as it seems to have caused more harm than good?
Dustin
Adrian Harvey wrote:
The wine version of riched20 fails an assertion when starting StreamboxVCR
$ wine .wine/drive_c/Program\ Files/StreamboxVcrSuite2/StreamBoxVCR1Beta31/vcr_31turbo.exe fixme:ole:CoRegisterMessageFilter stub fixme:ole:CoCreateInstance no classfactory created for CLSID {4955dd33- b159-11d0-8fcf-00aa006bcc59}, hres is 0x80040154 err:ole:ITypeInfo_fnInvoke did not find member id fffffdfa, flags 4! err:ole:ITypeInfo_fnInvoke did not find member id fffffdfb, flags 4! fixme:richedit:RichEditANSIWndProc WM_SETFONT: stub wine-pthread: run.c:522: ME_CalcRunExtent: Assertion `size.cx' failed. fixme:ole:ITypeInfo_fnRelease destroy child objects
Along with a popup dialogue box from the visual C++ runtime library indicating abnormal program termination. The file run.c appears to be part of riched20, and indeed overriding the load order to native only for that DLL allows the program work.
All reasonably standard debugging so far, and I went for some more logging to aid tracing the problem (or to log in bugzilla when it all gets too hard for my skill level ;-) )
$ WINEDEBUG="+relay" wine .wine/drive_c/Program\ Files/StreamboxVcrSuite2/StreamBoxVCR1Beta31/vcr_31turbo.exe 0009:Call kernel32.__wine_kernel_init() ret=55727d9e Segmentation fault
Shortest relay trace I've ever had! But I'm not really sure where to go from here... Running GDB on it gives me no useful results. I have an AMD64 box running Fedora Core 3 and wine is the latest from CVS.
I'm going to try some other tracing to look at the riched problem, but +relay crashing seems serious to me.
Adrian
Thanks, Dustin, that sorts the riched problem. Any ideas as to why the relay trace segfaults though? That was the bit I thought was interesting... I have now found it will segfault even if wine is not given an executable, so it's happening very early on.
Adrian
On Sun, 2005-05-08 at 04:58 -0500, Dustin Navea wrote:
This a known bug. head to http://bugs.winehq.org/show_bug.cgi?id=2924 for more info and a workaround..
We are waiting on the person that made this patch to post a fixed patch..
Alexandre.. This is generating a lot of bug reports, is there a chance we could remove it for now, as it seems to have caused more harm than good?
Dustin
Adrian Harvey wrote:
The wine version of riched20 fails an assertion when starting StreamboxVCR
$ wine .wine/drive_c/Program\ Files/StreamboxVcrSuite2/StreamBoxVCR1Beta31/vcr_31turbo.exe fixme:ole:CoRegisterMessageFilter stub fixme:ole:CoCreateInstance no classfactory created for CLSID {4955dd33- b159-11d0-8fcf-00aa006bcc59}, hres is 0x80040154 err:ole:ITypeInfo_fnInvoke did not find member id fffffdfa, flags 4! err:ole:ITypeInfo_fnInvoke did not find member id fffffdfb, flags 4! fixme:richedit:RichEditANSIWndProc WM_SETFONT: stub wine-pthread: run.c:522: ME_CalcRunExtent: Assertion `size.cx' failed. fixme:ole:ITypeInfo_fnRelease destroy child objects
Along with a popup dialogue box from the visual C++ runtime library indicating abnormal program termination. The file run.c appears to be part of riched20, and indeed overriding the load order to native only for that DLL allows the program work.
All reasonably standard debugging so far, and I went for some more logging to aid tracing the problem (or to log in bugzilla when it all gets too hard for my skill level ;-) )
$ WINEDEBUG="+relay" wine .wine/drive_c/Program\ Files/StreamboxVcrSuite2/StreamBoxVCR1Beta31/vcr_31turbo.exe 0009:Call kernel32.__wine_kernel_init() ret=55727d9e Segmentation fault
Shortest relay trace I've ever had! But I'm not really sure where to go from here... Running GDB on it gives me no useful results. I have an AMD64 box running Fedora Core 3 and wine is the latest from CVS.
I'm going to try some other tracing to look at the riched problem, but +relay crashing seems serious to me.
Adrian
Adrian Harvey wrote:
Thanks, Dustin, that sorts the riched problem. Any ideas as to why the relay trace segfaults though? That was the bit I thought was interesting... I have now found it will segfault even if wine is not given an executable, so it's happening very early on.
There are a couple of possible causes.
1) Are you using a 64-bit Linux, or 32, and if 64, are you compiling wine to 64-bit? It defaults (AFAIK) to 32, until you tell it otherwise..
2) Im not sure (anyone else want to comment?), but I think relay was deprecated by +trace, but then again I could be wrong. If I am right about 2 though, then we should probably either at least fix relay so it doesnt segfault, or just remove it altogether.
Dustin
Le dim 08/05/2005 à 16:53, Dustin Navea a écrit :
Adrian Harvey wrote:
Thanks, Dustin, that sorts the riched problem. Any ideas as to why the relay trace segfaults though? That was the bit I thought was interesting... I have now found it will segfault even if wine is not given an executable, so it's happening very early on.
There are a couple of possible causes.
- Are you using a 64-bit Linux, or 32, and if 64, are you compiling
wine to 64-bit? It defaults (AFAIK) to 32, until you tell it otherwise..
IIRC, Wine doesn't compile yet if x86-64 is the target processor (Win64), it'll compile as x86 (32 bit) instead. Culprits are some assembly routines (InterlockedIncrement et al.), plus 32 bit <-> 64 bit translations (unless we want a "pure" Win64, but I'm sure some apps will need both at the same time).
So my guess is he's running a 32 bit version.
- Im not sure (anyone else want to comment?), but I think relay was
deprecated by +trace, but then again I could be wrong. If I am right about 2 though, then we should probably either at least fix relay so it doesnt segfault, or just remove it altogether.
relay and trace are two different things: relay is a debug channel dumping info at each (or almost) function call, while trace is a class of debug statements shown only when asked. relay is in the same league as dll, file, opengl, while trace is in the same league as fixme, err and message.
Relay shouldn't segfault, and it's still supported. I guess Adrian (if nobody else can reproduce) will need to add further traces or go through it with a debugger.
Vincent
On Sun, 2005-05-08 at 17:41 -0400, Vincent Béron wrote: [snip]
Relay shouldn't segfault, and it's still supported. I guess Adrian (if nobody else can reproduce) will need to add further traces or go through it with a debugger.
Vincent
If I try to GDB wine I get all sorts of ugly errors eg: $ gdb wine GNU gdb Red Hat Linux (6.1post-1.20040607.43rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu"...Using host libthread_db library "/lib64/tls/libthread_db.so.1".
(gdb) run Starting program: /usr/local/bin/wine [Thread debugging using libthread_db enabled] [New Thread 1431890144 (LWP 4695)] [New Thread 1442380720 (LWP 4698)] [Thread 1442380720 (LWP 4698) exited] Cannot find user-level thread for LWP 4695: generic error
and starting winedbg in gdb mode gets me nowhere $ WINEDEBUG=+relay winedbg --gdb 0009:Call kernel32.__wine_kernel_init() ret=55727d9e Segmentation fault
I then tried re-enabling core dumps (Redhat turns them off by default) I don't get much useful from where, but GDB does tell me that Core was generated by `/usr/local/bin/wine- preloader /usr/local/bin/wine-pthread'.
so I gdb the preloader with the core, and get Core was generated by `/usr/local/bin/wine- preloader /usr/local/bin/wine-pthread'. Program terminated with signal 11, Segmentation fault. #0 0x5575b624 in ?? () (gdb) where #0 0x5575b624 in ?? () #1 0x55a4c852 in ?? () #2 0x00000000 in ?? ()
not very helpful - a function name would have been a start! so, any hints on how I can go on?
Adrian
Adrian Harvey wrote:
This GDB was configured as "x86_64-redhat-linux-gnu"...Using host libthread_db library "/lib64/tls/libthread_db.so.1".
I may be getting hung up on 64-bits for nothing, but is it possible for a 64-bit debugger (using 64-bit libs) to properly debug a 32-bit binary?
Dustin
On Mon, 09 May 2005 21:44:58 +1200, Adrian Harvey wrote:
If I try to GDB wine I get all sorts of ugly errors
Try an strace in "follow forks mode". Does that help?
thanks -mike
On Sun, 2005-05-08 at 15:53 -0500, Dustin Navea wrote:
Adrian Harvey wrote:
Thanks, Dustin, that sorts the riched problem. Any ideas as to why the relay trace segfaults though? That was the bit I thought was interesting... I have now found it will segfault even if wine is not given an executable, so it's happening very early on.
There are a couple of possible causes.
- Are you using a 64-bit Linux, or 32, and if 64, are you compiling
wine to 64-bit? It defaults (AFAIK) to 32, until you tell it otherwise..
I'm running the 64-bit version of Fedora core 3. Configure sets wine to be compiled 32 bit on x86_64 systems, as Windows programs are all 32-bit binaries and need a 32-bit ABI. It sets CC to gcc -m32 in the Makefile. I guess when Windows64 bit has been out for a while, and stabilises, we could look at how that handles 32->64 bit translation and work on a similar method, but as no current apps depend on it it's a bit academic at this stage.
configure is run as ./configure --x-libraries=/usr/X11R6/lib because xmkmf, which configure uses to detect the x library location always seems to return the lib64 directory, no matter how you try to force it otherwise...
- Im not sure (anyone else want to comment?), but I think relay was
deprecated by +trace, but then again I could be wrong. If I am right about 2 though, then we should probably either at least fix relay so it doesnt segfault, or just remove it altogether.
I think Vincent answered this one...
Dustin
Adrian
-
Adrian Harvey -
Dustin Navea -
Mike Hearn -
Vincent Béron