#3011 wm.test segfaults

obsolete: 8.6b3
Don Porter

An --enable-aqua build on Snow Leopard
produces segfaults in the tests
wm-manage-* and wm-forget-* in wm.test.


  • Don Porter

    Don Porter - 2012-09-15

    first segfault recipe:

    make test TESTFLAGS='-file wm.test -match wm-manage-1.[678]'

  • Kevin Walzer

    Kevin Walzer - 2012-09-16

    Running the wm.test suite itself does cause the segfault, but stepping through the command line by line does not produce any crash.

    % toplevel .t
    % toplevel .t.t
    % button .t.t.b -text "Manage This"
    % pack .t.t.b
    % update
    % lappend result [winfo manage .t.t]
    % lappend result [winfo toplevel .t.t.b]
    wm .t.t
    % wm forget .t.t
    % wm forget .t.t
    % pack .t.t
    % update
    % lappend result [winfo manage .t.t]
    wm .t.t pack
    % lappend result [winfo toplevel .t.t.b]
    wm .t.t pack .t
    % wm manage .t.t
    % wm deiconify .t.t
    % update
    % lappend result [winfo manage .t.t]
    wm .t.t pack .t pack
    % lappend result [winfo toplevel .t.t.b]
    wm .t.t pack .t pack .t.t

    I suspect it's the repeated rapid-fire calls to "update" that may be causing the crash. Tk-Cocoa has deep-set issues with notifications and the event loop that are insoluable at this point.

  • Alexandre Ferrieux

    Sometimes leaks between tests are the issue. What happens if you run wm-manage-16, 17, and 18 individually (instead of the three in a row) ?

    Re 'repeated rapid-fire calls to "update" causing the crash': update does no more than pointwise journeys into the event loop. So instead of causing the crash, I'd say they mereley reveal an underlying race condition.

    Re 'Tk-Cocoa has deep-set issues with notifications and the event loop that are insoluable at this point' : what do you mean by 'at this point' ? Short of an overhaul ? Scary...

  • Don Porter

    Don Porter - 2012-09-16

    No segfault with individual test runs. The recipe is the smallest I could find.

    Stack trace:

    Program received signal EXC_BAD_ACCESS, Could not access memory.
    Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000117
    0x000000010011d20b in TkWmDeadWindow (winPtr=0x101133290) at /Users/dgp/fossil/tk8.6/unix/../macosx/tkMacOSXWm.c:729
    729 if (wmPtr->hints.flags & IconPixmapHint) {
    (gdb) bt
    #0 0x000000010011d20b in TkWmDeadWindow (winPtr=0x101133290) at /Users/dgp/fossil/tk8.6/unix/../macosx/tkMacOSXWm.c:729
    #1 0x000000010011efe8 in WmForgetCmd (tkwin=0x103027610, winPtr=0x1033e3010, interp=0x10107e610, objc=3, objv=0x101083958) at /Users/dgp/fossil/tk8.6/unix/../macosx/tkMacOSXWm.c:1653
    #2 0x000000010011d8b0 in Tk_WmObjCmd (clientData=0x103027610, interp=0x10107e610, objc=3, objv=0x101083958) at /Users/dgp/fossil/tk8.6/unix/../macosx/tkMacOSXWm.c:926

    This is in the first [wm forget .t.t] command in test wm-manage-1.8.

    As explored over on the branch bug-3567779, it sure looks like there is
    a disagreement about what should be passed to TkWmDeadWindow().
    Comparing with TkWmNewWindow, it looks like it makes more sense to
    pass in "winPtr" instead of "macWin". But that leads to other problems.

    That aside, the undeniable problem is that the value macWin passed in,
    when treated as a (TkWIndow *) has a value in it wmInfoPtr field that
    is not NULL and is not a valid pointer. It doesn't look like anything so
    exotic as a race condition, or a mismatch to system update capabilities.
    Rather it's a simple programming failure to keep the data structures in
    a state consistent with the assumptions of the program. Unfortunately,
    it really need someone familiar with those assumptions to tackle the
    matter with any efficiency. All I can do is fumble and rage.

  • Don Porter

    Don Porter - 2012-09-16

    The casting between a (MacDrawable *) and a (TkWindow *) I
    find very puzzling as well.

  • Don Porter

    Don Porter - 2012-09-16

    Branch bug-3567786 has some fixup attempts. Solves the immediate
    problem, but like a bulge in a balloon, they pop up somewher else.

    On the branch the test suite looks fine with the exception of the test
    wm-manage-1.8. When I do:

    make test TESTFLAGS="-file wm.test -match wm-manage-1.8"

    I get a panic. Stack trace:

    #3 0x000000010022efb5 in Tcl_Panic (format=0x1002b7f90 "TkMacOSXSetupDrawingContext(): no context to draw into !") at /Users/dgp/fossil/tcl/generic/tclPanic.c:149
    #4 0x00000001001041c8 in TkMacOSXSetupDrawingContext (d=4316589072, gc=0x101142510, useCG=1, dcPtr=0x7fff5fbfe4b0) at /Users/dgp/fossil/tk8.6/unix/../macosx/tkMacOSXDraw.c:1579
    #5 0x0000000100102a3e in XFillRectangles (display=0x1010f9a10, d=4316589072, gc=0x101142510, rectangles=0x7fff5fbfe570, n_rectangles=1) at /Users/dgp/fossil/tk8.6/unix/../macosx/tkMacOSXDraw.c:1064
    #6 0x000000010012d8c4 in XFillRectangle (display=0x1010f9a10, d=4316589072, gc=0x101142510, x=0, y=0, width=108, height=28) at /Users/dgp/fossil/tk8.6/unix/../xlib/xdraw.c:79
    #7 0x0000000100005cc4 in Tk_Fill3DRectangle (tkwin=0x101497010, drawable=4316589072, border=0x101146710, x=0, y=0, width=108, height=28, borderWidth=0, relief=0) at /Users/dgp/fossil/tk8.6/unix/../generic/tk3d.c:986
    #8 0x0000000100104d71 in TkpDrawFrame (tkwin=0x101497010, border=0x101146710, highlightWidth=0, borderWidth=0, relief=0) at /Users/dgp/fossil/tk8.6/unix/../macosx/tkMacOSXDraw.c:1991
    #9 0x000000010004fed9 in DisplayFrame (clientData=0x10148fa10) at /Users/dgp/fossil/tk8.6/unix/../generic/tkFrame.c:1440
    #10 0x0000000100256691 in TclServiceIdle () at /Users/dgp/fossil/tcl/generic/tclTimer.c:751
    #11 0x000000010022add2 in Tcl_DoOneEvent (flags=34) at /Users/dgp/fossil/tcl/generic/tclNotify.c:984
    #12 0x000000010005067b in MapFrame (clientData=0x10148fa10) at /Users/dgp/fossil/tk8.6/unix/../generic/tkFrame.c:1771
    #13 0x0000000100256691 in TclServiceIdle () at /Users/dgp/fossil/tcl/generic/tclTimer.c:751
    #14 0x000000010022add2 in Tcl_DoOneEvent (flags=-1) at /Users/dgp/fossil/tcl/generic/tclNotify.c:984
    #15 0x0000000100012b29 in Tk_UpdateObjCmd (clientData=0x1010d0410, interp=0x10107e610, objc=1, objv=0x101083958) at /Users/dgp/fossil/tk8.6/unix/../generic/tkCmds.c:1214

  • Don Porter

    Don Porter - 2012-09-16

    That panic is in the last [update] in the body
    of test wm-manage-1.8

  • Don Porter

    Don Porter - 2012-09-16

    On that branch, the simplified script to cause a panic is:

    toplevel .t
    wm forget .t
    wm manage .t
    wm deiconify .t

    Panics in the last [update].

  • Don Porter

    Don Porter - 2012-09-16

    More progress committed to bug-3567786 branch.

  • Don Porter

    Don Porter - 2012-09-16

    Another update. branch now stops all the segfaults and panics
    in wm.test. Whether it introduces any new problems worse than
    the ones it solves is something more eyeballs would help to determine.

  • Don Porter

    Don Porter - 2012-09-16
    • priority: 8 --> 9
  • Kevin Walzer

    Kevin Walzer - 2012-09-17

    @ferrieux: The event loop stuff is the source of several subtle and not-so-subtle bugs. (I don't have the bug numbers here, but if you look at ones assigned to me and/or das, you'll find them.) The basic issue is that when Tk-Aqua was based on the Carbon API, the event loop was easy to integrate because Carbon and Tk have similar models. When das was rewriting this for Cocoa, it turned out to be much more complex because Cocoa has a very different event loop than Tk; it's not just more complex, but, as practice has shown, fragile. I say the problem is insoluable because I am not qualified to dive into those issues, except to hack on workarounds; I'm not sure that a re-write is even feasible given the mismatch between Cocoa and Tk at that low level. In any event, das is really the only one qualified to look at this closely.

  • Don Porter

    Don Porter - 2012-10-24
    • assigned_to: hobbs --> dgp
    • status: open --> closed-fixed

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks