Hallo,
Ludovic LANGE writes:
> Hello,
>
> I'm trying to run WinWord 6.0. (And may be the whole Office 4.2 suite
> one day...)
>
> A few years ago, I had great success with this. I was able to open Word,
> to write letters, etc...
> Then I stopped working with Wine out of time, and now, I'd like to set
> this up again to get rid of a DOS PC that keeps on crashing (I must keep
> Word6.0, upgrading is not an issue)
>
...
> err:shell:SHELL_DllEntryPoint shell.dll instantiated twice!
Normal deficency until we have address separation in place
...
> /usr/local/lib/lib.drv.so: cannot open shared object file: No such file
> or directory
Normal when the application loads some self supplied library
> err:win32:EnterCriticalSection Critical section 0x40290dfc wait timed
> out, retrying (60 sec)
Probably the result of the crash later
> err:win32:EnterCriticalSection Critical section 0x40290dfc wait timed
> out, retrying (60 sec)
> err:seh:EXC_DefaultHandling Unhandled exception code c0000005 flags 0
> addr 0x65434596
The crash
> err:seh:EXC_DefaultHandling Unhandled exception code c0000194 flags 0
> addr 0x400c7974
A crash inside the crash
Recent CVS should behave better in this situation
>
...
> I do not understand why does it call 32bits code ? I only have an
> 'out-of-the-box' windows 3.11 (workgroup) installation, without WIN32S
> (only 2 directories : windows and windows/system) and I may be wrong but
> I always thought win311 was 32bits-free.
Wine code itself uses CriticalSection as 32 bit code
>
> So, obviously, there is a misconfiguration of mine here.
Perhaps some misconfiguration may be present, but not nescessary
>
> Can someone point me to the problem, or give me the instruction on how
> to debug this ?
>
>
With recent CVS and some registry values the debugger should caom
up. But you can breakpoint 16-bit code at the present time.
Maybe related, I also found that Wordview 6 broke, probably using a
lot of similar things like Word6. I don't remember
exact, but think that it worked sometimes before. But recompiling some
old wine version from summer 1999 ate my registry and wordview didn't
work neither...
Anyway, the crash seems like the stack gets overwritte. The crash
happened in some wordview function not deep down in the call
tree, but after the application has gone deep down into the call
tree.
The function in which the crash happenes seems to have the
values of InitTask as parameters. I manipulated my relay debugging to
print out some stack values (lower values first).
The second value (0267) is the value at the position of
the stack that when poped from the stack later results in the crash.
SetMessageQueue is at the beginning of the function block in question.
0x40d2b046 is the location of that stack value in memory.
0080 0267 0000 072e 072f 0001 at 0x40d2b046 Ret USER.266: SETMESSAGEQUEUE()
retval=0x0001 ret=071f:a703 ds=072f ss:sp=072f:8118 bp=00008158
GLOBALREALLOC later moves this memory location to 40f400be
0080 0277 0000 073e 073f 0001 at 0x40d7a372 Call KERNEL.16:
GLOBALREALLOC(0x073e,0x0000fff0,0x0002) ret=06ff:7440 ds=073f ss:sp=073f:7d18
bp=00007d56
0080 0277 0000 073e 073f 0001 at 0x40f400be Ret KERNEL.16: GLOBALREALLOC()
retval=0x073e ret=06ff:7440 ds=073f ss:sp=073f:7d18 bp=00007d56
There are calls going deep down into other functions, and at one place
after a call to a dll of wordview the stack is trashed:
0080 0277 0000 073e 073f 0001 at 0x40f400be Ret KERNEL.20: GLOBALSIZE()
retval=0x00010000 ret=06ff:7390 ds=073f ss:sp=073f:7bb0 bp=00007be6
Call WWINTLV.4: SZFROMIDS(0000,0033,7bfe) ret=0527:08a1 ss:sp=073f:7be8
Ret WWINTLV.4: SZFROMIDS() retval = 073f:7bfe ret=0527:08a1 ss:sp=073f:7bf2
0000 8170 8172 81b0 0000 0000 at 0x40f400be Call KERNEL.15:
GLOBALALLOC(0x0002,0x0000056e) ret=06ff:74c6 ds=073f ss:sp=073f:7ba6 bp=00007be0
Values on that section of the stack now get changed on other
locations, but "0000 8170" keeps constant and when "8170" is popped
from the stack the application crashes:
0000 8170 81e6 81f0 0000 0010 at 0x40f400be Ret USER.69: SETCURSOR() retval=0x0000
ret=038f:524d ds=073f ss:sp=073f:7a54 bp=00007a8a
fixme:seh:UnhandledExceptionFilter BON:checking for debugger
..
fixme:seh:EXC_RtlRaiseException BON:res 1
Unhandled exception: priviledged instruction
in 16-bit code (072f:a774).
Loading new modules symbols:
USER32 USER GDI gdi32 x11drv*** Invalid address Symbol h_errno is invalid
0x00000000
WINEPS WPROCS
DISPLAY SYSTEM KERNEL ntdll KERNEL32*** Invalid address Symbol h_errno is invalid
0x00000000
In 16 bit mode.
0x072f:0xa774: mov 0xa(%bp),%es
Wine-dbg>info reg
Register dump:
CS:072f SS:073f DS:073f ES:073f FS:0000 GS:0000
IP:a774 SP:814a BP:8158 FLAGS:0202( - 00 I - - 1 )
AX:0001 BX:0002 CX:0000 DX:0000 SI:0080 DI:073e
Wine-dbg>info stack
Stack dump:
0x073f:0x814a: 068e 8996 fff0 81f0 875c 816e 81f0 0000
0x073f:0x815a: 0000 0000 0000 0000 8170 81e6 81f0 0000
0x073f:0x816a: 0010 739e 0080 82be f7da f91c fafe fbc8
0x073f:0x817a:
Probably this log is totally useless and screwed up, but perhaps
somebody can figure out something.
What or who write to that section of the stack? I didn't see something
0x8150 as return value of some alloc operation. Can anybody confirm
this wordview crash at all?
Thanks
Uwe Bonnes [EMAIL PROTECTED]
Free Software: If you contribute nothing, expect nothing
--
