Menu
▾
▴
[Mingw-notify] [ mingw-Bugs-1646259 ] mingw-5.1.3.exe sometimes crashes
|
From: SourceForge.net <no...@so...> - 2007-02-03 03:11:51
|
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-02-02 22:11 Message: Logged In: YES user_id=1190938 Originator: YES The mingw-5.1.3.exe installer is apparently built with an inetc plugin of 10-jun-2006. Further exploration has found that the crashing was occurring in a routine, ParentWndProc(), of that plugin. That routine is no longer a part of the current plugin, and so hopefully its logic (and failures) have been addressed in the later versions. When an acceptable version of the installer can be built and released with a later version of the plugin, this should be closed. (The current version of the plugin incorrectly draws the progress update area, as experienced by multiple individuals, two of us with the mingw installer. The inetc maintainer is aware that several people have this problem, but he has not been able to reproduce it and correct it yet.) (aside: It seems like when I submit comments, the status of this has been changing, and ernie has to change it back. Am I doing something wrong? The status field on my form is showing pending when I submit...) ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2007-01-30 09:05 Message: Logged In: YES user_id=15438 Originator: NO You should ask on the mingw-users list. Dave Murphy should be the responder since he is the one that built it. ---------------------------------------------------------------------- Comment By: contributor (contributor) Date: 2007-01-30 05:55 Message: Logged In: YES user_id=1190938 Originator: YES I have found a forum thread "supporting" inetc development. Interaction there suggests that timers are being destroyed in inetc add-in versions from sep 7, 2006 onward. (Examining the source, I still don't see how, and am continuing dialog regarding that. But if it has been corrected, that may explain why I couldn't reproduce with the version I built, as I have a more recent wiki version - don't know how/where to obtain the earlier verion(s).) What version of the inetc.dll is used to build the mingw-5.1.3.exe installer? (inetc forum thread at: http://forums.winamp.com/showthread.php?s=&postid=2116414#post2116414) ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2007-01-29 14:30 Message: Logged In: YES user_id=15438 Originator: NO Thanks for the follow up. I really like to see users take this kind of initiative to exercise the problem. We will now need to wait for NSIS to respond. ---------------------------------------------------------------------- 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 |