[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: Nasty Wine/kernel bug, anyone?
From:       Ulrich Weigand <weigand () immd1 ! informatik ! uni-erlangen ! de>
Date:       2001-03-28 23:23:59
[Download RAW message or body]


> If I were going to make more WAGs (Wild Assed guesses),
> I'd hazard a guess that this was due to my Alsa sound system
> (running on the AC97 codec on my Asus motherboard).
> 
> I tried to walk the stack back, but didn't get very far
> (after the first time of wrongly computing the hex offset
> from a .s file, I gave off, stomped off to look
> for a better disassembler and gave up).

If you have the 'vmlinux' file, try 
    objdump --disassemble vmlinux
 
> My best guess is that we're coming through dentry_open
> (xc012e7fe)/ chrdev_open (0xc012f66c)
> /soundcore_open (0xc01bbf71).  However, I wasn't
> seeing a familiar EBP/EIP pattern, so I'm possibly just
> pulling random symbols out of the air.

Yes, this appears to the proper trace:
   c0108d7f system_call
   c012ea2c sys_open
   c012e732 filp_open
   c012e7fe dentry_open
   c012f66c chrdev_open
   c01bbf71 soundcore_open
   d0826a42 <module>
   d087ce3e <module>
   c0107aa4 __down_failed
   c010794f __down
   ........ schedule 

[I am assuming that you have 256MB main memory. Correct?]

Now, the question is still, who is sleeping on that
semaphore and why?

From the call trace, it would seem that some sound-related
module is loaded, which does a down() on some semaphore in
its open() routine.  We even know which semaphore: cff267ac.
(This does not help much, as this is would appear to be 
somewhere in kmalloc()ed memory ...)

We can continue to track in two directions.

First, we can try to locate the point within the Wine 
application where the open() syscall is performed.
From the trace we see that the system call instruction
is located at 40303a24, and the stack pointer points
to 405c6638.  The system call itself is an 
    open( 41610240, O_WRONLY|O_NDELAY )

[The stack pointer value is rather weird, I'd say ...]

This particular open mode occurs in the Wine source only in 
dlls/winmm/wineoss/audio.c, which confirms the sound hypothesis.

The next time you reproduce the bug, could you please add
the output of /proc/<pid>/maps for the hanging Wine process?
This way, we could further analyse these pointers to Wine
user space ...

The more promising way to track the problem, however, is to
find out which module those d* addresses above reside in.
If the modules are still loaded, the output of /proc/ksyms 
should at least give a hint.  For a more refined symbol
lookup, it is best to use the 'ksymoops' tool, which correlates
the /proc/ksyms output with the ELF symbols read from the
object modules themselves.  To do so, write this:

Call Trace: [<d0826a42>] [<d087ce3e>]

to a file and pipe the file through ksymoops.

In any case, this would seem to be clearly a bug in that
sound module.  I don't know, however, why only Wine would
trigger that bug ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

[prev in list] [next in list] [prev in thread] [next in thread]