Menu
▾
▴
[Tcl-bugs] [ tktoolkit-Bugs-1449550 ] access violation crash in Tk_AttachHWND
|
From: SourceForge.net <no...@so...> - 2006-06-01 04:21:26
|
Bugs item #1449550, was opened at 2006-03-14 05:07 Message generated for change (Comment added) made by hobbs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=1449550&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: 13. Win Menus Group: current: 8.5a4 Status: Pending Resolution: Works For Me Priority: 8 Submitted By: Vince Darley (vincentdarley) Assigned to: Todd Helfter (tmh) Summary: access violation crash in Tk_AttachHWND Initial Comment: 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. ---------------------------------------------------------------------- >Comment By: Jeffrey Hobbs (hobbs) Date: 2006-05-31 21:21 Message: 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). ---------------------------------------------------------------------- Comment By: Mark Garvey (dunkfan) Date: 2006-05-31 08:01 Message: 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 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-05-30 09:06 Message: Logged In: NO I haven't seen this with latest cvs HEAD, but have only 1 day of informal testing so far... Vince. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2006-05-29 09:45 Message: 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. ---------------------------------------------------------------------- Comment By: Mark Garvey (dunkfan) Date: 2006-05-29 03:15 Message: 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. ---------------------------------------------------------------------- Comment By: Mark Garvey (dunkfan) Date: 2006-05-29 02:35 Message: 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. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2006-05-26 12:56 Message: 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. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-03-23 10:02 Message: 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. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2006-03-23 09:35 Message: Logged In: YES user_id=80530 status? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=1449550&group_id=12997 |