On Tue, 9 Dec 2003, Duncan Sands wrote:
> > > EIP is at hcd_pci_release+0x19/0x20 [usbcore]
>
> > I don't understand this stack dump. The EIP address is _after the end_ of
> > hcd_pci_release, as you can see from the fact that the following code is
> > nothing but a long string of NOPs.
>
> Hi Alan, I'm not sure what you mean. 0x19/0x20 seems to be inside the code
> to me :) On my machine, this is what it corresponds to:
>
> static void hcd_pci_release(struct usb_bus *bus)
> {
> 0: 55 push %ebp
> 1: 89 e5 mov %esp,%ebp
> 3: 83 ec 04 sub $0x4,%esp
> struct usb_hcd *hcd = bus->hcpriv;
> 6: 8b 45 08 mov 0x8(%ebp),%eax
> 9: 8b 50 30 mov 0x30(%eax),%edx
>
> if (hcd)
> c: 85 d2 test %edx,%edx
> e: 74 0c je 1c <hcd_pci_release+0x1c>
> hcd->driver->hcd_free(hcd);
> 10: 8b 82 38 01 00 00 mov 0x138(%edx),%eax
> 16: 89 14 24 mov %edx,(%esp,1)
> 19: ff 50 28 call *0x28(%eax) <= HERE
> }
> 1c: c9 leave
> 1d: c3 ret
> 1e: 89 f6 mov %esi,%esi
>
> So if Vince's disassembly is the same, the problem is that
> hcd->driver or hcd->driver->hcd_free is stuffed.
Clearly that compiler is different from mine. On my machine the "ret"
opcode is at offset 0x16, not 0x1d. Also, I guess the display of the code
bytes in stack dumps got changed at some point; now it shows values both
before and after the EIP location (it used to show just the values after
EIP). Okay, that clears that up.
The oops occurring where it did means that hcd->driver->hcd_free is not a
valid function pointer, even though hcd->driver appears to point to actual
data. So it's not a data access through a null pointer; it's a call to an
unmapped (possibly null) location.
It's not at all clear how that could happen. Those pointers are located
in static data in the HCD modules. It doesn't seem likely that the
pointer was overwritten. The only other possibility I can think of is
that the module was already unloaded. But that's not possible since you
were holding a reference to a device on that bus.
Maybe the answer is that hcd->driver is messed up but for some reason
still points to actual data. I can't imagine why that would happen
either.
Alan Stern
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
