[Tcl-bugs] [ tktoolkit-Bugs-671330 ] segfault when e.g. deiconifying destroyed window

[SourceForge.net <no...@so...>]

Bugs item #671330, was opened at 2003-01-20 20:59
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112997&aid=671330&group_id=12997

Category: 67. Unix Window Operations
Group: 8.4.1
Status: Open
Resolution: None
Priority: 9
Submitted By: Gerhard Hintermayer (hinteger)
Assigned to: Joe English (jenglish)
Summary: segfault when e.g. deiconifying destroyed window

Initial Comment:
(at least that's what it looks to me)
I have a (quite long) script that does on toplevel on
the local screen and on on a remote screen. If there
are more top-levels on the remote screen (sometimes
requires user interaction) I do raise & deiconify the
toplevel on <Visibility> and <Unmap> event (just in
case the operator tries to close the window). In case
more toplevels are fighting for the topmost postion, I
do the raising with a (random) delay of ~2000 ms.
Sometimes I do get segfaults, when, so far I have
debugged the thing, I do deiconify the window. I thing
(but I'm not sure) this is when I binded an empty
script to the two events, destroyed the toplevel and
the random delay is still running and fireing the
deiconify/raise later. (Well, that might not be a good
way to code, but that's another story). It could as
well be, that X on on of the 2 screens terminates, I
just don't know.

You can check the thread "suggestion to track down
segfaults"
at Google
http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&safe=off&threadm=3E2814AC.9070107%40inode.at&prev=/groups%3Fdq%3D%26num%3D30%26hl%3Den%26lr%3D%26ie%3DUTF-8%26group%3Dcomp.lang.tcl%26safe%3Doff%26start%3D30

Everything (code exaples and stack traces are listed there)

I've spent quit a lot hours trying to set up a x-liner
to reproduce the error, but I was'nt successful. Sorry.
If you want me to do some more debugging, give me a
note (and a list of gdb commands ;-) )

Gerhard

----------------------------------------------------------------------

>Comment By: Gerhard Hintermayer (hinteger)
Date: 2003-01-20 23:29

Message:
Logged In: YES 
user_id=124720

1) I did have the segfaults also berfore I compiled with
TCL_MEM_DEBUG, cannot say if more often or not. By inserting
"puts" I found out, that the error was when I entered the
event loop (via a after/vwait). Then I started using a
TCL_MEM_DEBUG enabled wish.

2) don't want to remove the catch, because real-life
application. Sometimes people log (terminate X), so not
catching this might be a bad thing.

3) did that already,but forgot to post : error is when
deiconifying.


----------------------------------------------------------------------

Comment By: Joe English (jenglish)
Date: 2003-01-20 22:54

Message:
Logged In: YES 
user_id=68433

Some more things to try (and thanks for your patience):
Does this still happen (or happen less frequently) when
running *without* TCL_MEM_DEBUG?

With TCL_MEM_DEBUG enabled, does this still happen if you
remove the 'catch' statements from the 'after' script in
proc raise_win:

>         catch {wm deiconify $w}
>         catch {raise $w}

Lastly, if you're willing to fight with the debugger again
:-), can you tell if the crash is happening in the call to
[wm deiconify] or the call to [wm raise]?  (printing
objv[1]->bytes in the Tk_WmObjCmd stack frame should help
you tell.)

An essential clue: from the stack backtrace, at
unix/tkUnixWm.c line 1036, 'winPtr' points into
already-freed storage.  The value of winPtr comes from a
previous call to TkGetWindowFromObj.

I am not sure _how_ this is happening, but it looks like
TkGetWindowFromObj() is to blame.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112997&aid=671330&group_id=12997