From: SourceForge.net <no...@so...> - 2012-09-14 17:55:28
|
Bugs item #3567786, was opened at 2012-09-14 10:55 Message generated for change (Tracker Item Submitted) made by dgp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=3567786&group_id=12997 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 65. Generic Window Operations Group: development: 8.6b3 Status: Open Resolution: None Priority: 8 Private: No Submitted By: Don Porter (dgp) Assigned to: Jeffrey Hobbs (hobbs) Summary: wm.test segfaults Initial Comment: An --enable-aqua build on Snow Leopard produces segfaults in the tests wm-manage-* and wm-forget-* in wm.test. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=3567786&group_id=12997 |
From: SourceForge.net <no...@so...> - 2012-09-15 15:34:18
|
Bugs item #3567786, was opened at 2012-09-14 10:55 Message generated for change (Comment added) made by dgp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=3567786&group_id=12997 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 65. Generic Window Operations Group: development: 8.6b3 Status: Open Resolution: None Priority: 8 Private: No Submitted By: Don Porter (dgp) Assigned to: Jeffrey Hobbs (hobbs) Summary: wm.test segfaults Initial Comment: An --enable-aqua build on Snow Leopard produces segfaults in the tests wm-manage-* and wm-forget-* in wm.test. ---------------------------------------------------------------------- >Comment By: Don Porter (dgp) Date: 2012-09-15 08:34 Message: first segfault recipe: make test TESTFLAGS='-file wm.test -match wm-manage-1.[678]' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=3567786&group_id=12997 |
From: SourceForge.net <no...@so...> - 2012-09-16 01:02:19
|
Bugs item #3567786, was opened at 2012-09-14 10:55 Message generated for change (Comment added) made by wordtech You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=3567786&group_id=12997 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 65. Generic Window Operations Group: development: 8.6b3 Status: Open Resolution: None Priority: 8 Private: No Submitted By: Don Porter (dgp) Assigned to: Jeffrey Hobbs (hobbs) Summary: wm.test segfaults Initial Comment: An --enable-aqua build on Snow Leopard produces segfaults in the tests wm-manage-* and wm-forget-* in wm.test. ---------------------------------------------------------------------- >Comment By: Kevin Walzer (wordtech) Date: 2012-09-15 18:02 Message: 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 .t % toplevel .t.t .t.t % button .t.t.b -text "Manage This" .t.t.b % pack .t.t.b % update % lappend result [winfo manage .t.t] wm % 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. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-15 08:34 Message: first segfault recipe: make test TESTFLAGS='-file wm.test -match wm-manage-1.[678]' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=3567786&group_id=12997 |
From: SourceForge.net <no...@so...> - 2012-09-16 09:37:43
|
Bugs item #3567786, was opened at 2012-09-14 10:55 Message generated for change (Comment added) made by ferrieux You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=3567786&group_id=12997 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 65. Generic Window Operations Group: development: 8.6b3 Status: Open Resolution: None Priority: 8 Private: No Submitted By: Don Porter (dgp) Assigned to: Jeffrey Hobbs (hobbs) Summary: wm.test segfaults Initial Comment: An --enable-aqua build on Snow Leopard produces segfaults in the tests wm-manage-* and wm-forget-* in wm.test. ---------------------------------------------------------------------- >Comment By: Alexandre Ferrieux (ferrieux) Date: 2012-09-16 02:37 Message: 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... ---------------------------------------------------------------------- Comment By: Kevin Walzer (wordtech) Date: 2012-09-15 18:02 Message: 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 .t % toplevel .t.t .t.t % button .t.t.b -text "Manage This" .t.t.b % pack .t.t.b % update % lappend result [winfo manage .t.t] wm % 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. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-15 08:34 Message: first segfault recipe: make test TESTFLAGS='-file wm.test -match wm-manage-1.[678]' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=3567786&group_id=12997 |
From: SourceForge.net <no...@so...> - 2012-09-16 13:01:14
|
Bugs item #3567786, was opened at 2012-09-14 10:55 Message generated for change (Comment added) made by dgp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=3567786&group_id=12997 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 65. Generic Window Operations Group: development: 8.6b3 Status: Open Resolution: None Priority: 8 Private: No Submitted By: Don Porter (dgp) Assigned to: Jeffrey Hobbs (hobbs) Summary: wm.test segfaults Initial Comment: An --enable-aqua build on Snow Leopard produces segfaults in the tests wm-manage-* and wm-forget-* in wm.test. ---------------------------------------------------------------------- >Comment By: Don Porter (dgp) Date: 2012-09-16 06:01 Message: 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. ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2012-09-16 02:37 Message: 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... ---------------------------------------------------------------------- Comment By: Kevin Walzer (wordtech) Date: 2012-09-15 18:02 Message: 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 .t % toplevel .t.t .t.t % button .t.t.b -text "Manage This" .t.t.b % pack .t.t.b % update % lappend result [winfo manage .t.t] wm % 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. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-15 08:34 Message: first segfault recipe: make test TESTFLAGS='-file wm.test -match wm-manage-1.[678]' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=3567786&group_id=12997 |
From: SourceForge.net <no...@so...> - 2012-09-16 13:32:47
|
Bugs item #3567786, was opened at 2012-09-14 10:55 Message generated for change (Comment added) made by dgp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=3567786&group_id=12997 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 65. Generic Window Operations Group: development: 8.6b3 Status: Open Resolution: None Priority: 8 Private: No Submitted By: Don Porter (dgp) Assigned to: Jeffrey Hobbs (hobbs) Summary: wm.test segfaults Initial Comment: An --enable-aqua build on Snow Leopard produces segfaults in the tests wm-manage-* and wm-forget-* in wm.test. ---------------------------------------------------------------------- >Comment By: Don Porter (dgp) Date: 2012-09-16 06:32 Message: The casting between a (MacDrawable *) and a (TkWindow *) I find very puzzling as well. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-16 06:01 Message: 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. ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2012-09-16 02:37 Message: 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... ---------------------------------------------------------------------- Comment By: Kevin Walzer (wordtech) Date: 2012-09-15 18:02 Message: 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 .t % toplevel .t.t .t.t % button .t.t.b -text "Manage This" .t.t.b % pack .t.t.b % update % lappend result [winfo manage .t.t] wm % 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. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-15 08:34 Message: first segfault recipe: make test TESTFLAGS='-file wm.test -match wm-manage-1.[678]' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=3567786&group_id=12997 |
From: SourceForge.net <no...@so...> - 2012-09-16 15:03:35
|
Bugs item #3567786, was opened at 2012-09-14 10:55 Message generated for change (Comment added) made by dgp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=3567786&group_id=12997 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 65. Generic Window Operations Group: development: 8.6b3 Status: Open Resolution: None Priority: 8 Private: No Submitted By: Don Porter (dgp) Assigned to: Jeffrey Hobbs (hobbs) Summary: wm.test segfaults Initial Comment: An --enable-aqua build on Snow Leopard produces segfaults in the tests wm-manage-* and wm-forget-* in wm.test. ---------------------------------------------------------------------- >Comment By: Don Porter (dgp) Date: 2012-09-16 08:03 Message: 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 ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-16 06:32 Message: The casting between a (MacDrawable *) and a (TkWindow *) I find very puzzling as well. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-16 06:01 Message: 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. ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2012-09-16 02:37 Message: 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... ---------------------------------------------------------------------- Comment By: Kevin Walzer (wordtech) Date: 2012-09-15 18:02 Message: 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 .t % toplevel .t.t .t.t % button .t.t.b -text "Manage This" .t.t.b % pack .t.t.b % update % lappend result [winfo manage .t.t] wm % 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. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-15 08:34 Message: first segfault recipe: make test TESTFLAGS='-file wm.test -match wm-manage-1.[678]' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=3567786&group_id=12997 |
From: SourceForge.net <no...@so...> - 2012-09-16 15:06:34
|
Bugs item #3567786, was opened at 2012-09-14 10:55 Message generated for change (Comment added) made by dgp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=3567786&group_id=12997 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 65. Generic Window Operations Group: development: 8.6b3 Status: Open Resolution: None Priority: 8 Private: No Submitted By: Don Porter (dgp) Assigned to: Jeffrey Hobbs (hobbs) Summary: wm.test segfaults Initial Comment: An --enable-aqua build on Snow Leopard produces segfaults in the tests wm-manage-* and wm-forget-* in wm.test. ---------------------------------------------------------------------- >Comment By: Don Porter (dgp) Date: 2012-09-16 08:06 Message: That panic is in the last [update] in the body of test wm-manage-1.8 ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-16 08:03 Message: 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 ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-16 06:32 Message: The casting between a (MacDrawable *) and a (TkWindow *) I find very puzzling as well. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-16 06:01 Message: 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. ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2012-09-16 02:37 Message: 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... ---------------------------------------------------------------------- Comment By: Kevin Walzer (wordtech) Date: 2012-09-15 18:02 Message: 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 .t % toplevel .t.t .t.t % button .t.t.b -text "Manage This" .t.t.b % pack .t.t.b % update % lappend result [winfo manage .t.t] wm % 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. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-15 08:34 Message: first segfault recipe: make test TESTFLAGS='-file wm.test -match wm-manage-1.[678]' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=3567786&group_id=12997 |
From: SourceForge.net <no...@so...> - 2012-09-16 15:41:31
|
Bugs item #3567786, was opened at 2012-09-14 10:55 Message generated for change (Comment added) made by dgp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=3567786&group_id=12997 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 65. Generic Window Operations Group: development: 8.6b3 Status: Open Resolution: None Priority: 8 Private: No Submitted By: Don Porter (dgp) Assigned to: Jeffrey Hobbs (hobbs) Summary: wm.test segfaults Initial Comment: An --enable-aqua build on Snow Leopard produces segfaults in the tests wm-manage-* and wm-forget-* in wm.test. ---------------------------------------------------------------------- >Comment By: Don Porter (dgp) Date: 2012-09-16 08:41 Message: On that branch, the simplified script to cause a panic is: toplevel .t update wm forget .t wm manage .t wm deiconify .t update exit Panics in the last [update]. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-16 08:06 Message: That panic is in the last [update] in the body of test wm-manage-1.8 ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-16 08:03 Message: 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 ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-16 06:32 Message: The casting between a (MacDrawable *) and a (TkWindow *) I find very puzzling as well. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-16 06:01 Message: 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. ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2012-09-16 02:37 Message: 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... ---------------------------------------------------------------------- Comment By: Kevin Walzer (wordtech) Date: 2012-09-15 18:02 Message: 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 .t % toplevel .t.t .t.t % button .t.t.b -text "Manage This" .t.t.b % pack .t.t.b % update % lappend result [winfo manage .t.t] wm % 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. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-15 08:34 Message: first segfault recipe: make test TESTFLAGS='-file wm.test -match wm-manage-1.[678]' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=3567786&group_id=12997 |
From: SourceForge.net <no...@so...> - 2012-09-16 22:12:23
|
Bugs item #3567786, was opened at 2012-09-14 10:55 Message generated for change (Comment added) made by dgp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=3567786&group_id=12997 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 65. Generic Window Operations Group: development: 8.6b3 Status: Open Resolution: None Priority: 8 Private: No Submitted By: Don Porter (dgp) Assigned to: Jeffrey Hobbs (hobbs) Summary: wm.test segfaults Initial Comment: An --enable-aqua build on Snow Leopard produces segfaults in the tests wm-manage-* and wm-forget-* in wm.test. ---------------------------------------------------------------------- >Comment By: Don Porter (dgp) Date: 2012-09-16 15:12 Message: More progress committed to bug-3567786 branch. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-16 08:41 Message: On that branch, the simplified script to cause a panic is: toplevel .t update wm forget .t wm manage .t wm deiconify .t update exit Panics in the last [update]. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-16 08:06 Message: That panic is in the last [update] in the body of test wm-manage-1.8 ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-16 08:03 Message: 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 ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-16 06:32 Message: The casting between a (MacDrawable *) and a (TkWindow *) I find very puzzling as well. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-16 06:01 Message: 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. ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2012-09-16 02:37 Message: 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... ---------------------------------------------------------------------- Comment By: Kevin Walzer (wordtech) Date: 2012-09-15 18:02 Message: 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 .t % toplevel .t.t .t.t % button .t.t.b -text "Manage This" .t.t.b % pack .t.t.b % update % lappend result [winfo manage .t.t] wm % 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. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-15 08:34 Message: first segfault recipe: make test TESTFLAGS='-file wm.test -match wm-manage-1.[678]' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=3567786&group_id=12997 |
From: SourceForge.net <no...@so...> - 2012-09-16 22:37:28
|
Bugs item #3567786, was opened at 2012-09-14 10:55 Message generated for change (Comment added) made by dgp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=3567786&group_id=12997 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 65. Generic Window Operations Group: development: 8.6b3 Status: Open Resolution: None >Priority: 9 Private: No Submitted By: Don Porter (dgp) Assigned to: Jeffrey Hobbs (hobbs) Summary: wm.test segfaults Initial Comment: An --enable-aqua build on Snow Leopard produces segfaults in the tests wm-manage-* and wm-forget-* in wm.test. ---------------------------------------------------------------------- >Comment By: Don Porter (dgp) Date: 2012-09-16 15:37 Message: 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. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-16 15:12 Message: More progress committed to bug-3567786 branch. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-16 08:41 Message: On that branch, the simplified script to cause a panic is: toplevel .t update wm forget .t wm manage .t wm deiconify .t update exit Panics in the last [update]. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-16 08:06 Message: That panic is in the last [update] in the body of test wm-manage-1.8 ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-16 08:03 Message: 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 ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-16 06:32 Message: The casting between a (MacDrawable *) and a (TkWindow *) I find very puzzling as well. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-16 06:01 Message: 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. ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2012-09-16 02:37 Message: 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... ---------------------------------------------------------------------- Comment By: Kevin Walzer (wordtech) Date: 2012-09-15 18:02 Message: 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 .t % toplevel .t.t .t.t % button .t.t.b -text "Manage This" .t.t.b % pack .t.t.b % update % lappend result [winfo manage .t.t] wm % 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. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-15 08:34 Message: first segfault recipe: make test TESTFLAGS='-file wm.test -match wm-manage-1.[678]' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=3567786&group_id=12997 |
From: SourceForge.net <no...@so...> - 2012-09-17 14:02:24
|
Bugs item #3567786, was opened at 2012-09-14 10:55 Message generated for change (Comment added) made by wordtech You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=3567786&group_id=12997 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 65. Generic Window Operations Group: development: 8.6b3 Status: Open Resolution: None Priority: 9 Private: No Submitted By: Don Porter (dgp) Assigned to: Jeffrey Hobbs (hobbs) Summary: wm.test segfaults Initial Comment: An --enable-aqua build on Snow Leopard produces segfaults in the tests wm-manage-* and wm-forget-* in wm.test. ---------------------------------------------------------------------- >Comment By: Kevin Walzer (wordtech) Date: 2012-09-17 07:02 Message: @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. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-16 15:37 Message: 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. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-16 15:12 Message: More progress committed to bug-3567786 branch. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-16 08:41 Message: On that branch, the simplified script to cause a panic is: toplevel .t update wm forget .t wm manage .t wm deiconify .t update exit Panics in the last [update]. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-16 08:06 Message: That panic is in the last [update] in the body of test wm-manage-1.8 ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-16 08:03 Message: 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 ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-16 06:32 Message: The casting between a (MacDrawable *) and a (TkWindow *) I find very puzzling as well. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-16 06:01 Message: 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. ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2012-09-16 02:37 Message: 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... ---------------------------------------------------------------------- Comment By: Kevin Walzer (wordtech) Date: 2012-09-15 18:02 Message: 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 .t % toplevel .t.t .t.t % button .t.t.b -text "Manage This" .t.t.b % pack .t.t.b % update % lappend result [winfo manage .t.t] wm % 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. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-15 08:34 Message: first segfault recipe: make test TESTFLAGS='-file wm.test -match wm-manage-1.[678]' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=3567786&group_id=12997 |
From: SourceForge.net <no...@so...> - 2012-10-24 19:08:00
|
Bugs item #3567786, was opened at 2012-09-14 10:55 Message generated for change (Settings changed) made by dgp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=3567786&group_id=12997 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 65. Generic Window Operations Group: development: 8.6b3 >Status: Closed >Resolution: Fixed Priority: 9 Private: No Submitted By: Don Porter (dgp) >Assigned to: Don Porter (dgp) Summary: wm.test segfaults Initial Comment: An --enable-aqua build on Snow Leopard produces segfaults in the tests wm-manage-* and wm-forget-* in wm.test. ---------------------------------------------------------------------- Comment By: Kevin Walzer (wordtech) Date: 2012-09-17 07:02 Message: @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. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-16 15:37 Message: 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. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-16 15:12 Message: More progress committed to bug-3567786 branch. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-16 08:41 Message: On that branch, the simplified script to cause a panic is: toplevel .t update wm forget .t wm manage .t wm deiconify .t update exit Panics in the last [update]. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-16 08:06 Message: That panic is in the last [update] in the body of test wm-manage-1.8 ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-16 08:03 Message: 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 ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-16 06:32 Message: The casting between a (MacDrawable *) and a (TkWindow *) I find very puzzling as well. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-16 06:01 Message: 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. ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2012-09-16 02:37 Message: 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... ---------------------------------------------------------------------- Comment By: Kevin Walzer (wordtech) Date: 2012-09-15 18:02 Message: 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 .t % toplevel .t.t .t.t % button .t.t.b -text "Manage This" .t.t.b % pack .t.t.b % update % lappend result [winfo manage .t.t] wm % 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. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-09-15 08:34 Message: first segfault recipe: make test TESTFLAGS='-file wm.test -match wm-manage-1.[678]' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=3567786&group_id=12997 |