In this portion of code:
if (twdPtr == NULL) {
twdPtr = (TkWinDrawable *) ckalloc(sizeof(TkWinDrawable));
twdPtr->type = TWD_WINDOW;
twdPtr->window.winPtr = (TkWindow *) tkwin;
>>> } else if (twdPtr->window.handle != NULL) {
entryPtr = Tcl_FindHashEntry(&tsdPtr->windowTable,
(char *)twdPtr->window.handle);
Tcl_DeleteHashEntry(entryPtr);
}
the 'twdPtr' has value 0x000001.
Here's the stack trace:
Tk_AttachHWND(Tk_Window_ * 0x02d510d8, HWND__ *
0x00031b18) line 73 + 5 bytes
TkpMakeWindow(TkWindow * 0x02d510d8, unsigned long
0x00000000) line 279 + 13 bytes
Tk_MakeWindowExist(Tk_Window_ * 0x02d510d8) line 1684 +
13 bytes
MenuSelectEvent(TkMenu * 0x02d35350) line 2868 + 11 bytes
RecursivelyClearActiveMenu(TkMenu * 0x02d35350) line
1285 + 9 bytes
RecursivelyClearActiveMenu(TkMenu * 0x022103c0) line
1295 + 17 bytes
RecursivelyClearActiveMenu(TkMenu * 0x0235c930) line
1295 + 17 bytes
RecursivelyClearActiveMenu(TkMenu * 0x0206d6a8) line
1295 + 17 bytes
TkWinHandleMenuEvent(HWND__ * * 0x0026f60c, unsigned
int * 0x0026f610, unsigned int * 0x0026f614, long *
0x0026f618, long * 0x0026f600) line 1010 + 9 bytes
WmProc(HWND__ * 0x001015f6, unsigned int 0x00000116,
unsigned int 0x00210805, long 0x00000000) line 7834 +
25 bytes
USER32! 77d48734()
This tends to happen when my computer is running a
variety of other intensive processes and I haven't used
this particular Tk application for a while. When I
then click on its menubar to activate it and try to
open a menu, *boom*. [Speculation: perhaps some
resource has been cleaned up by the OS and Tk doesn't
realise that?]
Vince.
Logged In: YES
user_id=80530
status?
Logged In: NO
I still see the bug all the time, but haven't the faintest
idea what causes it. It doesn't seem anyone else has looked
at it... -Vince.
Logged In: YES
user_id=72656
Does this only happen in 8.5? Note that the callchain
indicates WmProc origination, and the TkWinHandlMenuEvent
call has changed there from 8.4 to 8.5 (apparently for
better embedded handling?).
Note that I also just fixed a semi-related bug that turned
out to be a VC6 optimization bug (bug 1224330), so please
reverify this with the head.
Logged In: YES
user_id=1183601
I get this under exactly the same circumstances in 8.4.6
XP SP2. The window hasn't been used for a long time and
other intensive processes are active.
The process just dies without any warning/notification
from the OS, seemingly as the process is being swapped
back in after a long inactive period.
Today's case happened when the user clicked on the
window's taskbar item to view it. Everything had been
working fine up to that point.
Logged In: YES
user_id=1183601
Sorry that last comment was perhaps a little misleading. I
don't have a stack trace so I can't say this has anything
to do with the stack trace above. The symptoms are however
the same. Long running process (two days plus) with no
user interaction in this case from Friday evening to
Monday morning...User interacts...process dies...
The fault has so far has only been reported on one System
(Hyperthreading 512MB). The problem is intermittent but
always requires a long inactive time to occur.
Logged In: YES
user_id=72656
You mention a tray icon ... this could very well be a bug in
the extension that provides that, or some other component.
I'm not getting a strong sense that this is a core Tk bug
with the lack of repro.
Logged In: NO
I haven't seen this with latest cvs HEAD, but have only 1
day of informal testing so far...
Vince.
Logged In: YES
user_id=1183601
Thanks for your interest Jeff. Totally unrelated problem
here. Added symbols to tcl/tk 846 tile 0.6.5 and low and
behold the (or I should say "a") problem is reproducible.
Tile calls Tk_Get3DBorderFromObj which causes a Panic.
"Tk_Get3DBorderFromObj called with non-existent border!"
Most likely cause is "Remote Desktop" usage with 16bpp
display on a wish already running at 32bpp.
Seems to be related to image create photo perhaps with
the -palette option. Sorry I can't pin it down in a small
script. I removed redundant image create calls with -
palette and the problem disappeared. I hope that was it.
FYI Here's the trace...
msvcr71d.dll!_NMSG_WRITE(int rterrnum) Line 195
msvcr71d.dll!abort() Line 44
tcl84ts.dll!Tcl_PanicVA(const char * format, char *
argList) Line 108
tcl84ts.dll!Tcl_Panic(const char * arg1, ...) Line 134
tk84ts.dll!Tk_Get3DBorderFromObj(Tk_Window_ * tkwin,
Tcl_Obj * objPtr) Line 1317
tile06.dll!BackgroundElementDraw(void * clientData, void *
elementRecord, Tk_Window_ * tkwin, unsigned long d,
Ttk_Box b, unsigned int state) Line 83
tile06.dll!Ttk_DrawElement(Ttk_ElementImpl_ * element,
Ttk_Style_ * style, char * recordPtr, Tk_OptionTable_ *
optionTable, Tk_Window_ * tkwin, unsigned long d, Ttk_Box
b, unsigned int state) Line 1133
tile06.dll!Ttk_DrawNodeList(Ttk_Layout_ * layout, unsigned
int state, Ttk_LayoutNode_ * node, unsigned long d) Line
1060
tile06.dll!Ttk_DrawLayout(Ttk_Layout_ * layout, unsigned
int state, unsigned long d) Line 1069
tile06.dll!WidgetDisplay(void * recordPtr, unsigned long
d) Line 580
tile06.dll!RedisplayWidget(void * recordPtr) Line 78
tcl84ts.dll!TclServiceIdle() Line 704
tcl84ts.dll!Tcl_ServiceAll() Line 1048
tk84ts.dll!WmProc(HWND__ * hwnd, unsigned int message,
unsigned int wParam, long lParam) Line 7451
Logged In: YES
user_id=72656
The image problem is likely 1123042, and this would then be
a dup. See if you can repro anything without relying on
remote desktop, or make sure that you start all programs
after remote desktop has started (it is the bpp runtime
change that makes Tk burp).
Logged In: NO
Just saw this bug again with cvs HEAD. Same circumstances
as before -- other processes taking 99% of CPU, haven't used
the Tk application for a while, and click on a menu...
Vince.
Logged In: YES
user_id=1312539
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
Logged In: YES
user_id=32170
Re-opening, given my recent reproduction of the bug with cvs
head.