Very odd docking bug

[abligh]

I've finally managed to get this easily repeatable. It's worth fixing because occasionally it SEGV's under similar circumstances. While dragging a docked bar, it can occasionally dock a floating pane. There is no reason for this I can see!

To duplicate (under GTK), build the sample application with vanilla 0.9.2. Run it.
Open a new grid control (as a floating pane), and put it in the middle of the work area.

Now carefully click on the gripper of the lower toolbar (with "Items" in it), and drag it downward, just sufficient to it make a frame appear round it. Without releasing the mouse button, drag a few pixels to the right (an amount just wider than the gripper normally works), and then slowly move the mouse back up. You will see a very wide and deep dock rectangle appearing. Drop the mouse. You will see it's docked the grid control (for no discernable reason).

This one has me stumped.

Alex

[Ben]

Hi Alex,

I just duplicated the bug. Very strange indeed. I'll have to take a closer look before I can draw any solid conclutions. I may be that the action pane somehow ends up pointing to the wrong pane (by some illegal vector operation). I'll take a closer look.

Thanks,
Ben

[abligh]

Hi Alex,

I just duplicated the bug. Very strange indeed. I'll have to take a closer look before I can draw any solid conclutions. I may be that the action pane somehow ends up pointing to the wrong pane (by some illegal vector operation). I'll take a closer look.

Thanks,
Ben

That's what I figure is happening. The SEGV occurs when the action_pane points to wxFloatingPane which has since been deleted (the Move call bombs out in DoMoveWindow). That one is almost impossible to duplicate (repeatedly try to dock and undock floating panes, waggling them about, and you eventually see it) but was why I started hunting this one down.

Alex

[Peek]

This sounds like a problem I was wrestling with today. I managed to track the problem down to m_action_window pointing to deleted memory. This can happen during the window manager's idle processing if OnIdle() is called after the user has released the left mouse button but before OnLeftUp() is called. In that case, the frame that m_action_window is pointing to is Destroy()'d, but m_action_window isn't set to NULL. My fix was to add this code wherever frames get destroyed (namely, in DetachPane() and Update()) :

Code: Select all

            p.frame->SetSizer(NULL);
            // Set m_action_window to NULL if its pointing to this frame
            if ( m_action_window == p.frame )
                m_action_window = NULL;
            p.frame->Destroy();


and this code in OnMotion():

Code: Select all

     else if (m_action == actionDragFloatingPane)
    {
        // m_action_window might have gone away already
        if ( m_action_window )
        {
            wxPoint pt = m_frame->ClientToScreen(event.GetPosition());
            m_action_window->Move(pt.x - m_action_offset.x,
                                 pt.y - m_action_offset.y);
        }
    }


Without this change, wxAUI was unusable for me under GTK because I could reliably segfault my app by simply docking and undocking panes. I haven't tested this change extensively, but it seems to work and the code is pretty straightforward, so it may merit being added to the next official release. Enjoy!


Paul Kerchen

[Ben]

Hi Paul,

Thanks so much for this patch. We've been looking for a solution to this bug for some time now.

Kind Regards,
Ben

[Ben]

This bug has been fixed in CVS.

Thanks,
Ben

[Peek]

Today I switched over from 0.9.2 to wxWidget 2.7.0's wxFrameManager and I see that my changes that I posted here in July didn't make it into wxWidgets. Was this an oversight or intentional (because the crash my changes fixed is definitely there for me under 2.7.0)?

[Peek]

Actually, I see that this problem has been raised on wxWidget's SourceForge page (http://sourceforge.net/tracker/index.php?func=detail&aid=1575571&group_id=9863&atid=109863) and someone has a submitted a patch, so presumably this will be in the next release.

[Ben]

Hi Peek,

I will take a look at this in wxWidgets CVS and find out why its still happening. The reason that your exact patch wasn't applied is that we thought that another (fixed) bug had been the cause of the problem.

Thanks,
Ben

[Ben]

Hi Peek,

Well, you're right. The bug still existed. However, I just applied a fix. The fix is similar to your patch.

The reason I didn't just apply your patch outright is that I really need to understand exactly what the underlying cause of the problem is. Your patch certainly fixed the symptom of the problem, but the problem itself was/is caused by a deeper wxGTK bug.

For your reading pleasure, check out sourceforge bug 1531361. You can also read about it here: http://lists.wxwidgets.org/cgi-bin/ezmlm-cgi?5:mss:76225:200607:dommoajiblolijmmooed

The summary is basically this: in wxGTK, when a window is shown or hidden, an extra move event it sent. This is a bug. The manifestation is, when you redock a frame inside wxAUI (with gtk), a move event gets fired when the frame is hidden. Sometimes this move event gets processed slowly, and gets handled after the miniframe is destroyed. Thus your crash.

Bottom line is that I believe the bug is permanently fixed in wxWidgets CVS. Thanks for your report, I'm very grateful. Let me know if anything bad is still happening.

Thanks,
Ben

[Peek]

Hi Ben,
I freely admit that my fix wasn't based on a deep understanding of the problem, so I'm glad you took the time to get to the heart of the matter. Thanks for your diligence and hard work.

[gnschmidt]

Just to say that I think something similar happened on Windows using a recent CVS version (though I have not yet applied the recent patch).

I will check that this problem is now fixed on Windows as well. If not, I will try to investigate a little further.

On my first attempt at debugging this, the traceback led to OnMotion and then to an unknown function call in wxW that led to a crash (I don't have a debug release on Win32, so I haven't been able to trace it further).

When I started to look into this problem, I was struck that OnMotion dereferences a number of changeable pointers. Would it be worth checking each of these against zero before use, or would this slow the library down too much?

[Ben]

Hi,

There's no problem adding checks-- it doesn't add any slowness. Mainly what I want to avoid is fixing the symptom and not the problem itself. That's why I've been so cautious in adding code like that.

That said, I feel that this problem is solved. If it happens again, I'll be happy to investigate.

Thanks,
Ben

[gnschmidt]

No problem, thanks! I agree with you re symptoms/problems. I'll fold in the latest version and let you know if I have any problems.