Assertion fails in riched20; relay debug segfaults

[Adrian Harvey]

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

[Dustin Navea]

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]

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

[Dustin Navea]

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

[Vincent Béron]

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.
>
> 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..

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.
> 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.

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

[Adrian Harvey]

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

[Dustin Navea]

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

[Mike Hearn]

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

[Adrian Harvey]

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.
>
> 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..

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...
> 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.

I think Vincent answered this one...
> Dustin

Adrian