From: SourceForge.net <no...@so...> - 2007-01-29 17:43:55
|
Bugs item #1646259, was opened at 2007-01-27 22:40 Message generated for change (Comment added) made by contributor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1646259&group_id=2435 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: MinGW Installer Group: None Status: Open Resolution: Works For Me Priority: 5 Private: No Submitted By: contributor (contributor) Assigned to: Nobody/Anonymous (nobody) Summary: mingw-5.1.3.exe sometimes crashes Initial Comment: athlon64, winxp sp2, 1.5GBRAM, at least 4GB free hard drive. Downloaded mingw-5.1.3.exe has crashed multiple times attempting to install candidate. (I saw a report somewhere that 5.1.2 had crashed for someone else, but did not repeat.) Multiple attempts did eventually result in apparently complete installation. Attempting to download tools/source and building my own version of that installer apparently does not produce equivalent installer. (Crashes don't occur, but display problems do.) I speculate some attempt to call a window procedure that is no longer valid may be occurring in the downloaded version. (NSIS issue? But it makes mingw installer look bad...) I have debugged enough to know that the code just before user32!InternalCallWinProc+0x28 is calling window procedures. (I did not have the patience to see if they were ever anything other than ms windows window procedures.) This stack is taken from windbg, opened with a (drwatson) generated crash dump file: WARNING: Frame IP not in any known module. Following frames may be wrong. 0012fbac 77d48709 0x100012b4 0012fbd8 77d487eb user32!InternalCallWinProc+0x28 0012fc40 77d4b368 user32!UserCallWinProcCheckWow+0x150 0012fc94 77d4b3b4 user32!DispatchClientMessage+0xa3 0012fcbc 7c90eae3 user32!__fnDWORD+0x24 0012fce0 77d493c6 ntdll!KiUserCallbackDispatcher+0x13 0012fd0c 77d493df user32!NtUserPeekMessage+0xc 0012fd38 77d6e92b user32!PeekMessageW+0xbc 0012fd80 77d5688a user32!DialogBox2+0xe4 0012fda8 77d568cc user32!InternalDialogBox+0xd0 0012fdc8 77d5892d user32!DialogBoxIndirectParamAorW+0x37 0012fdf4 0040379a user32!DialogBoxParamA+0x4c 0012fe0c 0042a000 MinGW_5_1_3+0x379a 00000000 00000000 MinGW_5_1_3+0x2a000 The modules list does not show any module loaded with an address range that includes 0x100012b4. Since I apparently can't build an exact (enough) replica of the (NSIS/mingw combo) installer that reproduces the crashes (even though I tried to do so obtaining what I believe are all the correct tool versions (NSIS) and MINGW CVS source), I provide the information in case it may be useful to someone else. ---------------------------------------------------------------------- >Comment By: contributor (contributor) Date: 2007-01-29 12:43 Message: Logged In: YES user_id=1190938 Originator: YES It appears that inetc.cpp sets a timer in its onInitDlg() routine, that it A) does not trap the return timer id, and B)therefore cannot (and does not) kill the timer at any point. I have submitted a bug report against NSIS: http://sourceforge.net/tracker/index.php?func=detail&aid=1647321&group_id=22049&atid=373085 ---------------------------------------------------------------------- Comment By: contributor (contributor) Date: 2007-01-29 11:53 Message: Logged In: YES user_id=1190938 Originator: YES I haven't run a memory check as it doesn't look to me like a memory problem. Every time it crashes, the invalid address has always been the same (0x10001b24). I've just gotten the crash to occur running the downloaded mingw-5.1.3.exe under windbg. The address would have been at offset 0x12b4 inside of inetc.dll. Debugging it under visual studio express (which shows module UNload as well as load), inetc.dll has been unloaded shortly before the crash occurs... I speculate that the address (or offset 0x12b4) in that code is a callback address of some kind, and it is being called _after_ the dll is unloaded. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2007-01-28 09:56 Message: Logged In: YES user_id=15438 Originator: NO You might want to execute some memory checker to ensure you have good memory on your PC. Your rebuilding the binary is only avoiding the memory area that is causing you an issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1646259&group_id=2435 |