help! latest cvs build of wine crashes every time

[Graham Stoney]

Hi winers,

I've built the latest cvs version of wine on my Debian stable system, and it
crashes every time I run it. Here's an example:

greyham@fred:/tmp$ wine notepad
wine: Unhandled exception, starting debugger...
wine: Unhandled exception, starting debugger...
wine: Unhandled exception, starting debugger...
(messages continue indefinitely; the debugger never gets started)

It appears to be dying in X11DRV_CreateDC at the call to wine_tsx11_lock; but
I suspect this is due to a stack frame corruption. Here's a gdb backtrace at
the point of failure:

121         wine_tsx11_lock();
(gdb) where
#0  X11DRV_CreateDC (dc=0x40393e48, pdev=0x40393e5c, 
    driver=0x406c2c20 "DISPLAY", device=0x0, output=0x0, initData=0x0)
    at ../../graphics/x11drv/init.c:121
#1  0x40a72ff9 in CreateDCA (driver=0x409e19a0 "DISPLAY", device=0x0, 
    output=0x0, initData=0x0) at ../../objects/dc.c:586
#2  0x409a622b in SYSMETRICS_Init () at ../../windows/sysmetrics.c:119
#3  0x409cf5aa in process_attach () at user_main.c:229
#4  0x409cf725 in UserClientDllInitialize (inst=1083441152, reason=1, 
    reserved=0x1) at user_main.c:327
#5  0x40088e9f in PE_InitDLL (module=1083441152, type=1, lpReserved=0x1)
    at ../../loader/pe_image.c:628
#6  0x40085a6b in MODULE_InitDLL (wm=0x403718e8, type=1, lpReserved=0x1)
    at ../../loader/module.c:157
#7  0x40085b89 in MODULE_DllProcessAttach (wm=0x403718e8, lpReserved=0x1)
    at ../../loader/module.c:228
#8  0x40085b65 in MODULE_DllProcessAttach (wm=0x40371518, lpReserved=0x1)
    at ../../loader/module.c:223
#9  0x40085b65 in MODULE_DllProcessAttach (wm=0x40371288, lpReserved=0x1)
    at ../../loader/module.c:223
#10 0x40085b65 in MODULE_DllProcessAttach (wm=0x40370ff8, lpReserved=0x1)
    at ../../loader/module.c:223
#11 0x40085b65 in MODULE_DllProcessAttach (wm=0x0, lpReserved=0x1)
    at ../../loader/module.c:223
#12 0x400bd088 in start_process () at ../../scheduler/process.c:540
#13 0x400c128d in call_on_thread_stack (func=0x400bcef4)
    at ../../scheduler/sysdeps.c:112
(gdb) s

Program received signal SIGSEGV, Segmentation fault.
0x53e58955 in ?? ()

Other apps fair as badly; always crashing on startup. I'm running XF86 version
4.2; there must be something about my system that is triggering the failure;
otherwise you guys would be hitting it all the time. Any hints where I should
start looking?

Thanks,
Graham

[Uwe Bonnes]

> > > > > "Graham" == Graham Stoney  writes:

Graham> Hi winers, I've built the latest cvs version of wine on my
    Graham> Debian stable system, and it crashes every time I run it. Here's
    Graham> an example:

Graham> greyham@fred:/tmp$ wine notepad wine: Unhandled exception,
    Graham> starting debugger...  wine: Unhandled exception, starting
    Graham> debugger...  wine: Unhandled exception, starting debugger...
    Graham> (messages continue indefinitely; the debugger never gets
    Graham> started)

Did you set synchronous mode in the ~/.wine/config [x11drv] section:
"Synchronous" = "y"

It normally helps with X related problems.

Bye

[Graham Stoney]

On Sun, Oct 13, 2002 at 01:58:03PM +0200, Uwe Bonnes wrote:
> Did you set synchronous mode in the ~/.wine/config [x11drv] section:
> "Synchronous" = "y"

I have now; doesn't seem to help though. Any other suggestions?

Thanks,
Graham

[Michael Stefaniuc]

On Sun, Oct 13, 2002 at 10:09:48PM +1000, Graham Stoney wrote:
> On Sun, Oct 13, 2002 at 01:58:03PM +0200, Uwe Bonnes wrote:
> > Did you set synchronous mode in the ~/.wine/config [x11drv] section:
> > "Synchronous" = "y"
>
> I have now; doesn't seem to help though. Any other suggestions?

I had this problems too, and a 'make clean' fixed it for me.

bye
    michael

[Graham Stoney]

On Sun, Oct 13, 2002 at 03:12:50PM +0200, Michael Stefaniuc wrote:
> I had this problems too, and a 'make clean' fixed it for me.

Thanks; re-installing XFree86 & 'make clean'ing appeared to solve the problem.

Unfortunately the app doesn't work right; it's calling the unimplemented
WNetOpenEnumA stub -- which is odd because it's a database engine frontend app
which I wouldn't have thought was network-aware. Sadly, the searches fail...

Thanks,
Graham