Hi,
Sometimes while browsing the unixfs namespace in the file dialog wine crashes with the following console output:
============================================================================= wine: Unhandled exception (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x00004005 in 32-bit code (0x7b24fbf2). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:7b24fbf2 ESP:7b8af188 EBP:7b8af1ac EFLAGS:00210202( - 00 - -RI1) EAX:00000000 EBX:7b2e8b70 ECX:78560110 EDX:7b8af258 ESI:7b2e88f6 EDI:00004001 Stack dump: 0x7b8af188: 00000000 000007d0 7b8af298 00000000 0x7b8af198: 00000008 00000001 7b2e8b70 00000000 0x7b8af1a8: 7b8af1f8 7b8af244 7b2696a2 00004001 0x7b8af1b8: 00000015 00000040 00000000 78561a78 0x7b8af1c8: 78561a78 7b4e8448 7b8af298 00000000 0x7b8af1d8: 7b8af204 7b47bfd1 0036003e 0000004e Backtrace: =>1 0x7b24fbf2 DPA_GetPtr+0x32(hdpa=0x4001, nIndex=0x15) [dpa.c:479] in comctl32 (0x7b8af1ac) 2 0x7b2696a2 LISTVIEW_GetItemT(infoPtr=0x78560110, lpLVItem=0x7b8af258, isW=0x1) [/home/mjung/compile/wine/dlls/comctl32/listview.c:5225] in comctl32 (0x7b8af244) 3 0x7b273e7a notify_itemactivate+0x6a(infoPtr=0x78560110, htInfo=0x7b8af308) [/home/mjung/compile/wine/dlls/comctl32/listview.c:791] in comctl32 (0x7b8af2d4) 4 0x7b26fd5f LISTVIEW_LButtonDblClk+0x8f(infoPtr=0x78560110, wKey=0x1, x=0xad, y=0x39) [/home/mjung/compile/wine/dlls/comctl32/listview.c:8103] in comctl32 (0x7b8af334)
...
===============================================================================
As you see, the hdpa parameter to DPA_GetPtr is invalid. The relevant code in LISTVIEW_GetItemT is (dlls/comctl32/listview.c, line 5126):
/* find the item and subitem structures before we proceed */ hdpaSubItems = (HDPA)DPA_GetPtr(infoPtr->hdpaItems, lpLVItem->iItem); lpItem = (ITEM_INFO *)DPA_GetPtr(hdpaSubItems, 0); assert (lpItem);
It's the first call to DPA_GetPtr that crashes. So the structure pointed to by infoPtr seems to be corrupted (infoPtr is a LISTVIEW_INFO *, which represents the listview item and which given as the first parameter to LISTVIEW_GetItemT).
As I never saw this with the original shfldr_fs.c code, I assume that shfldr_unixfs.c has a memory corruption bug somewhere. I've tried to figure the problem for some time now, but to now avail.
So my questions are:
1) Can someone give me some advice on how to debug such a problem? 2) Did other people see this bug already? 3) Would valgrind be of help to debug this?
Thanks,
Hi,
On Fri, Aug 26, 2005 at 10:10:16PM +0200, Michael Jung wrote:
- Can someone give me some advice on how to debug such a problem?
Why not use a watchpoint on that location? Choose some significant function call a while before the crash, have a breakpoint on that function (a DPA related function probably is best), check out which infoPtr is the relevant one, then watch on the hdpaItems location, i.e. watch *0xsomewhere then continue execution until it triggers and you know where the value got overwritten.
- Did other people see this bug already?
Not me.
- Would valgrind be of help to debug this?
In theory it's possible, but valgrind currently doesn't work with Wine any more (or rather the other way around), AFAIK.
Andreas
Hi Andy,
On Friday 26 August 2005 22:26, Andreas Mohr wrote:
Why not use a watchpoint on that location? Choose some significant function call a while before the crash, have a breakpoint on that function (a DPA related function probably is best), check out which infoPtr is the relevant one, then watch on the hdpaItems location, i.e. watch *0xsomewhere then continue execution until it triggers and you know where the value got overwritten.
Thanks for your comments. The problem is that things are really dynamic here. Every time you double click a folder, the current ShellView object is destroyed and a new one is created. Given that I have to browse into like 30 different folders before it crashes on me, I can't pin down the relevant infoPtr.
Thanks,
Hi,
On Fri, Aug 26, 2005 at 11:03:33PM +0200, Michael Jung wrote:
Thanks for your comments. The problem is that things are really dynamic here. Every time you double click a folder, the current ShellView object is destroyed and a new one is created. Given that I have to browse into like 30 different folders before it crashes on me, I can't pin down the relevant infoPtr.
Then you will perhaps have to make sense of the in-memory structure right before the corruption address. Or perhaps add full logging for all related memory allocations (and check whether they're relevant by comparing the address in the log with the corruption address, i.e. whether you managed to log relevant allocations).
Andreas
On Fri, 26 Aug 2005 23:03:33 +0200 Michael Jung mjung@iss.tu-darmstadt.de wrote:
Every time you double click a folder, the current ShellView object is destroyed and a new one is created. Given that I have to browse into like 30 different folders before it crashes on me, I can't pin down the relevant infoPtr.
In hunt for this bug, I discovered the following:
* It appears both with unixfs and normal Wine fs.
* Every double click on a folder in the listview destroys this listview object (effectively destroying all underlying structures), creates a new one, and returns control to the place where double click notification was sent by the old listview (notify_hdr() function in listview.c). This time the old listview and its structures are already destroyed, but we continue to access them, exception!
Here is a patch which adds checking if the window has been destroyed at that point. I don't know if it is acceptable but it fixes the problem.
ChangeLog:
Protect against wrong memory access if a listview is destroyed in a handler for its NM_DBLCLK notification.
-- Ph.
Hi Phil,
On Thursday 08 September 2005 19:23, Phil Krylov wrote:
- Every double click on a folder in the listview destroys this listview object (effectively destroying all underlying structures), creates a new one, and returns control to the place where double click notification was sent by the old listview (notify_hdr() function in listview.c). This time the old listview and its structures are already destroyed, but we continue to access them, exception!
Thanks a lot, that really saved my day. I've spend some hours chasing this bug already, but to no avail.
Here is a patch which adds checking if the window has been destroyed at that point. I don't know if it is acceptable but it fixes the problem.
Wouldn't it be enough to call notify_click after notify_itemactivate? I've attached a modification of your patch, which does just this. Seems to work fine for me.
Bye,
Hi Michael,
On Thu, 8 Sep 2005 23:10:18 +0200 Michael Jung mjung@iss.tu-darmstadt.de wrote:
Wouldn't it be enough to call notify_click after notify_itemactivate? I've attached a modification of your patch, which does just this. Seems to work fine for me.
Probably, but what if some apps depend on order in which these notifications are sent? (assuming we already send them in the right order)
-- Ph.
Hello Dimi,
On Thursday 08 September 2005 23:37, Phil Krylov wrote:
Michael Jung mjung@iss.tu-darmstadt.de wrote:
Wouldn't it be enough to call notify_click after notify_itemactivate? I've attached a modification of your patch, which does just this. Seems to work fine for me.
Probably, but what if some apps depend on order in which these notifications are sent? (assuming we already send them in the right order)
It seems that the code in it's current form was written by you:
http://cvs.winehq.org/cvsweb/wine/dlls/comctl32/listview.c.diff?r1=1.204&...
Do you see a problem to move the notify_click below the notify_itemactivate?
Bye,
Phil Krylov wrote:
Hi Michael,
On Thu, 8 Sep 2005 23:10:18 +0200 Michael Jung mjung@iss.tu-darmstadt.de wrote:
Wouldn't it be enough to call notify_click after notify_itemactivate? I've attached a modification of your patch, which does just this. Seems to work fine for me.
Probably, but what if some apps depend on order in which these notifications are sent? (assuming we already send them in the right order)
Comparing the Listview control spy on Wine and Win2k, the notifications appear to be in the correct order in Wine: NM_RELEASEDCAPTURE NM_DBLCLK LVN_ITEMACTIVE
From: "Phil Krylov" phil@newstar.rinet.ru
Here is a patch which adds checking if the window has been destroyed at that point. I don't know if it is acceptable but it fixes the problem.
But this could potentially happen on any notification, what makes this particular one special (sorry, I was away on vacation and I missed this thread).
On Fri, 9 Sep 2005 13:59:05 -0400 "Dimi Paun" dimi@lattica.com wrote:
From: "Phil Krylov" phil@newstar.rinet.ru
Here is a patch which adds checking if the window has been destroyed at that point. I don't know if it is acceptable but it fixes the problem.
But this could potentially happen on any notification, what makes this particular one special (sorry, I was away on vacation and I missed this thread).
OK, should we then make a patch which adds an IsWindow() check after every notification in every control? This one fixes a really annoying bug, while the other places are not proved to crash.
-- Ph.
From: "Phil Krylov" phil@newstar.rinet.ru
OK, should we then make a patch which adds an IsWindow() check after every notification in every control? This one fixes a really annoying bug, while the other places are not proved to crash.
Well, if it's a entire class of bugs, we should fix them all. I guess we need a bit of experimentation on windows to see if we need to protect all notifications or only a few ones.
I guess we can protect all of them, in which case we have to look to see how we can do it centrally, in the notification function itself.
On Fri, 9 Sep 2005 15:09:24 -0400 "Dimi Paun" dimi@lattica.com wrote:
From: "Phil Krylov" phil@newstar.rinet.ru
OK, should we then make a patch which adds an IsWindow() check after every notification in every control? This one fixes a really annoying bug, while the other places are not proved to crash.
Well, if it's a entire class of bugs, we should fix them all.
I think that we should check if it's a class of bugs or a single bug first.
I guess we need a bit of experimentation on windows to see if we need to protect all notifications or only a few ones.
I guess we can protect all of them, in which case we have to look to see how we can do it centrally, in the notification function itself.
I don't see a way to do it clean enough.
So, here's a new version of the patch (enhanced comment, WARN changed to a TRACE).
ChangeLog:
Protect against wrong memory access if a listview is destroyed during processing of its NM_DBLCLK notification (a.k.a. file dialog GPF).
-- Ph.
Andreas Mohr wrote:
Hi,
On Fri, Aug 26, 2005 at 10:10:16PM +0200, Michael Jung wrote:
- Would valgrind be of help to debug this?
In theory it's possible, but valgrind currently doesn't work with Wine any more (or rather the other way around), AFAIK.
It used to as of a few months ago. Have you tried it recently and found it not to work then?
Hi,
On Fri, Aug 26, 2005 at 07:30:55PM -0700, Robert Shearman wrote:
Andreas Mohr wrote:
In theory it's possible, but valgrind currently doesn't work with Wine any more (or rather the other way around), AFAIK.
It used to as of a few months ago. Have you tried it recently and found it not to work then?
Hmm, then I'm afraid I have to take all of the blame of the world on me and crawl back into my dark cave.
I haven't tried it too much, only one attempt recently and I could have easily done something wrong.
For reference, maybe you could show the command line to use (which wine binary etc., which parameters are useful)? Do we have this in the Developers Guide already? (err, no, we don't, it seems... we should!)
Andreas
On Fri, 26 Aug 2005 22:10:16 +0200 Michael Jung mjung@iss.tu-darmstadt.de wrote:
- Did other people see this bug already?
Yes, I confirm it.
-- Ph.
Phil Krylov wrote:
On Fri, 26 Aug 2005 22:10:16 +0200 Michael Jung mjung@iss.tu-darmstadt.de wrote:
- Did other people see this bug already?
Yes, I confirm it.
I am seeing it now, using winecfg and browsing to "Add application..." in the Applications tab. And this entirely within wine drives. The exact same crash though, always immediately after a double click on a folder. If I click once on a folder and click open, it works fine. So I suspect something being triggered by the double click.
Backtrace: =>1 0xffffe002 (0x4076ee80) 2 0x42028c55 abort+0x1d5 in libc.so.6 (0x4076efb0) 3 0x42021043 in libc.so.6 (+0x21043) (0x4076eff0) 4 0x40bf13be in comctl32 (+0x313be) (0x4076f074) 5 0x40bf906f notify_itemactivate+0x5f(infoPtr=0x40257e18, htInfo=0x4076f124) [/home/wine/dlls/comctl32/listview.c:791] in comctl32 (0x4076f104) 6 0x40bf614c LISTVIEW_LButtonDblClk+0x6c(infoPtr=0x40257e18, wKey=0x1, x=0x5, y=0x4d) [/home/wine/dlls/comctl32/listview.c:8100] in comctl32 (0x4076f150) 7 0x40bf7fa8 LISTVIEW_WindowProc+0x534(hwnd=0x10068, uMsg=0x203, wParam=0x1, lParam=0x4d0005) [/home/wine/dlls/comctl32/listview.c:9372] in comctl32 (0x4076f1b4) 8 0x40a5f6d3 WINPROC_wrapper+0x17 in user32 (0x4076f1d8) ...
On Monday 29 August 2005 18:09, Duane Clark wrote:
I am seeing it now, using winecfg and browsing to "Add application..." in the Applications tab. And this entirely within wine drives.
Are you saying you are not using the unix filesystem namespace and you are seeing the crash anyway?
Bye,
Michael Jung wrote:
On Monday 29 August 2005 18:09, Duane Clark wrote:
I am seeing it now, using winecfg and browsing to "Add application..." in the Applications tab. And this entirely within wine drives.
Are you saying you are not using the unix filesystem namespace and you are seeing the crash anyway?
It is a unix filesystem, but within a mapped wine drive. That is, I started winecfg from the fake drive C:, and navigated within drive C:
Michael Jung wrote:
On Monday 29 August 2005 18:09, Duane Clark wrote:
I am seeing it now, using winecfg and browsing to "Add application..." in the Applications tab. And this entirely within wine drives.
Are you saying you are not using the unix filesystem namespace and you are seeing the crash anyway?
As of the current CVS, the problem seems to have disappeared for me. It is not clear to me what patch fixed it.
Duane Clark wrote:
As of the current CVS, the problem seems to have disappeared for me. It is not clear to me what patch fixed it.
Oops, spoke too soon. Still there.
Hi Michael,
- Did other people see this bug already?
TextPad 4.5 broke just around the time when you checked in the patch. It crashes at startup, the crash location is strange and has already changed a few times when I updated the WINE source tree.
You can get TextPad 4.5 here: ftp://ftp.textpad.com/pub/textpad4.5/txpeng450.exe
I hope that you'll find the bug. Good luck!
Michael
-
Andreas Mohr -
Dimi Paun -
Duane Clark -
Michael Jung -
Michael Kaufmann -
Phil Krylov -
Robert Shearman