Need advice on which native dlls to try

[Duane Clark]

Andreas Mohr wrote:
> 
> Olaf Delgado Friedrichs <delgado at okeeffe-pc3.la.asu.edu> wrote:
> > On 4 Feb 2001 22:11:51 GMT, Andreas Mohr <aqi46g09cu001 at sneakemail.com> wrote:
> >>Olaf Delgado Friedrichs <delgado at okeeffe-pc3.la.asu.edu> wrote:
> >>> On 4 Feb 2001 01:02:05 GMT, Andreas Mohr <aqi46g09cu001 at sneakemail.com> wrote:
> >>>>> Would that give any hint on what to try next?
> >>>>Load up winedbg and do a disas 0x40ad2dfc to find out which crst
> >>>>is the problem.
> >>
> >>> I was afraid you would say that. That means reading assembler code,
> >>> right? Well, at least that way I can pretend I am 20 again. :)
> >>Nope, not assembler.
> >>Just the crst name at that address.
> 
> > I see! Okay, here's what I get (this is wine-20010112 now, built from
> > sources):
> 
> > 0x400f5aac (X11DRV_CritSection [sysdeps.c]): addb     %al,0x0(%eax)
> 
> Hmm, so it's X11DRV_CritSection which timeouts.
> Not that this helps us too much :-\
> 
> You could maybe try to identify which wine process hangs.
> Debugging this is not too easy, at least not via email/news.
> 
> Andreas Mohr

Would it be okay if I butt in and throw in some additional data, which
may only serve to obfuscate things? I would be willing to help debug
this also, if I had a few pointers. I don't mind poking around in
winedbg.

I run a couple of applications regularly. A couple applications runs
flawlessly under wine, never generating these ntdll timeouts. In my
case, the problem program is the 32 bit version of WordViewer 97. I have
the latest CVS and am running on pretty much standard RH 6.1 and 6.2
systems. I get similar symptoms to above, with the ubiquitous ntdll
timeouts. My result of disassembling shows one of the critical timouts
in x11drv_main.c, though this one does not completely stop the program
but only causes it to freeze for a short time.

Unfortunately, the symptoms slowly shift. For awhile it will do one
thing somewhat consistently, but after awhile it starts doing something
else. That and other symptoms lead me to suspect memory corruption, but
I have no real good evidence of that. However, while Wordview will
sometimes work for awhile just fine, if I continue to play with it,
opening and closing files, changing zoom, etc, it will invariably within
a few minutes either hang permanently with ntdll timeouts or crash
completely. Almost always, either event will occur when attempting to
open a dialog. This leads me to believe that the two events have a
related underlying cause.

Let me add a few more symptoms in my case, many of which may not be
relevant though I suspect a connection. One thing that is very
consistent is that when first starting the program, and after selecting
a file to open, if the mouse focus remains in the Wordviewer window, the
top and left side rulers are not drawn. Similarly, pulling down a menu
works and selecting items work, but if for example zoom is selected, the
zoom dialog does not appear until Wordview loses and then regains mouse
focus. Once the focus has been lost and regained once, this particular
symptom disappears until the program is exited (or crashes) and
restarted.

That was one case where for awhile I was consistently getting the ntdll
timeout in x11drv_main.c. I would run wordview, open a file, let it come
up (everything except the rulers would be drawn), then move the mouse
out of and back into the window. The rulers would be immediately drawn,
then it would freeze for a moment, then generate the timeout, and
finally come back to life. These particular symptoms do not show up when
running under winedbg.

Another random thing I see, though I doubt it is related, is that it
complains that SLANGUAGE is not defined for my language (043E). However,
I do have a LANG environment variable set to en_US.

And here is a crash, after playing with wordview for a couple minutes,
and on about the fifth or sixth time opening the zoom dialog.

First chance exception: page fault on read access to 0x414f700c
 in 32-bit code (0x407816fd).
Register dump:
 CS:0023 SS:002b DS:002b ES:002b FS:008f GS:0000
 EIP:407816fd ESP:40586048 EBP:40586050 EFLAGS:00210206(  R- 00  I   -
-P1 )
 EAX:414f7000 EBX:407c26dc ECX:00000000 EDX:403b2e78
 ESI:00000000 EDI:403bea9c
Stack dump:
Symbol h_errno is invalid
Symbol hack_digit is invalid
0x40586048 (_end+0x23e588):  407c26dc 00000001 40586074 4078cd62
0x40586058 (_end+0x23e598):  00000467 407c26dc 00000138 307859c0
0x40586068 (_end+0x23e5a8):  00000001 403bea94 01bf9020 40586098
0x40586078 (_end+0x23e5b8):  4078cde8 000001bf 307859c0 00000138
0x40586088 (_end+0x23e5c8):  08777348 4078c730 4078c268 00000138
0x40586098 (_end+0x23e5d8):  00000138 307859a3 08777348 307859c0
0x405860a8 (_end+0x23e5e8): 

0011: sel=008f base=40110e00 limit=00000fff 32-bit rw-
Backtrace:
=>0 0x407816fd (QUEUE_GetQueueTask+0x29(hQueue=0x467) [queue.c:1299])
(ebp=40586050)
  1 0x4078cd62 (EnumTaskWindows16+0x66(hTask=0x1bf, func=0x307859c0,
lParam=0x138) [win.c:2913]) (ebp=40586074)
  2 0x4078cde8 (EnumThreadWindows+0x2c(id=0x8777348, func=0x307859c0,
lParam=0x138) [win.c:2937]) (ebp=40586098)
  3 0x307859a3 (MSO97V.DLL.WindowFromDlg+0x791) (ebp=00000138)

0x407816fd (QUEUE_GetQueueTask+0x29 [queue.c:1299]): movw      
0xc(%eax),%si
1300            QUEUE_Unlock( queue );
Wine-dbg>

Duane