Mingw builds lock up under windows

[Beherith]

I managed to successfully build with mingw under windows 7, but I have this issue where if I launch the build from windows command prompt, it works fine, but if I launch it from explorer by double clicking, it just sits there eating 100% cpu and hangs without ever getting to the 'choose map and mod' screen. No error is thrown by it.

From infolog:

Code: Select all

Warning: Hang in ThreadPool
Warning: Hang in ThreadPool
Warning: [Watchdog] Hang detection triggered for Spring 96.0.
Warning:   (in thread: main)
Warning: DLL information:
Error: 0x00400000	spring
Error: 0x77750000	ntdll
Error: 0x769c0000	kernel32
Error: 0x75530000	KERNELBASE
...

[abma]

gdb backtrace?

infolog.txt contains no stacktrace.

gdb -p should work on windows, too.

[Beherith]

It doesnt crash when launched from a .bat file, it doesnt crash when launched from gdb
It only crashes on double click launch

[Beherith]

I got it to crash under gdb:

Code: Select all

Program received signal SIGSEGV, Segmentation fault.
0x007c804d in pair<spring_time, void> (this=0xbaadf00d, __y=..., __x=...) at c:/tdm-gcc-32/bin/../lib/gcc/mingw32/4.7.2/include/c++/bits/stl_pair.h:131
131             : first(__x), second(std::forward<_U2>(__y)) { }
(gdb) bt
#0  0x007c804d in pair<spring_time, void> (this=0xbaadf00d, __y=..., __x=...)
    at c:/tdm-gcc-32/bin/../lib/gcc/mingw32/4.7.2/include/c++/bits/stl_pair.h:131
#1  construct<std::pair<spring_time, spring_time>, spring_time const&, spring_time> (__p=0xbaadf00d, this=0x1c7de798)
    at c:/tdm-gcc-32/bin/../lib/gcc/mingw32/4.7.2/include/c++/ext/new_allocator.h:110
#2  emplace_back<spring_time const&, spring_time> (this=0x1c7de798) at c:/tdm-gcc-32/bin/../lib/gcc/mingw32/4.7.2/include/c++/bits/deque.tcc:139
#3  ScopedMtTimer::~ScopedMtTimer (this=0x28f680, __in_chrg=<optimized out>) at S:\spring_96_source\spring\rts\System\TimeProfiler.cpp:137
#4  0x007d6784 in for_mt (f=..., end=<optimized out>, start=<optimized out>, step=<optimized out>)
    at S:/spring_96_source/spring/rts/System/ThreadPool.h:315
#5  for_mt (f=..., end=<optimized out>, start=<optimized out>) at S:/spring_96_source/spring/rts/System/ThreadPool.h:321
#6  _fu11714___ZNSs4_Rep20_S_empty_rep_storageE () at S:\spring_96_source\spring\rts\System\FileSystem\ArchiveScanner.cpp:772
#7  0x007d7404 in _fu11730___ZNSs4_Rep20_S_empty_rep_storageE () at S:\spring_96_source\spring\rts\System\FileSystem\ArchiveScanner.cpp:649
#8  0x007d8229 in _fu11749___ZNSs4_Rep20_S_empty_rep_storageE () at S:\spring_96_source\spring\rts\System\FileSystem\ArchiveScanner.cpp:438
#9  0x007d9177 in CArchiveScanner::ScanDirs (this=0x16ff9648, scanDirs=..., doChecksum=true)
    at S:\spring_96_source\spring\rts\System\FileSystem\ArchiveScanner.cpp:390
#10 0x007d94e2 in _fu11788___ZNSs4_Rep20_S_empty_rep_storageE () at S:\spring_96_source\spring\rts\System\FileSystem\ArchiveScanner.cpp:364
#11 0x007e3ffd in FileSystemInitializer::Initialize () at S:\spring_96_source\spring\rts\System\FileSystem\FileSystemInitializer.cpp:38
#12 0x007ba89f in _fu11186___ZNSs4_Rep20_S_empty_rep_storageE () at S:\spring_96_source\spring\rts\System\SpringApp.cpp:236
#13 0x007bb181 in SpringApp::Run (this=0x28fd4c) at S:\spring_96_source\spring\rts\System\SpringApp.cpp:1025
#14 0x007a1c17 in Run (argc=-1794753728, argv=0x95063b40) at S:\spring_96_source\spring\rts\System\Main.cpp:65
#15 0x007a24da in _fu10645___ZNSs4_Rep20_S_empty_rep_storageE () at S:\spring_96_source\spring\rts\System\Main.cpp:125
#16 0x007a266e in WinMain@16 (hInstanceIn=0x400000, hPrevInstance=0x0, lpCmdLine=0x15164cc7 "", nCmdShow=10)
    at S:\spring_96_source\spring\rts\System\Main.cpp:133
#17 0x00cecf9b in main ()

[Silentwings]

Once spring is running (and crashed), you can get its pid from resource monitor, fire up gdb and type "attach <pid>" to connect to a running instance of spring - you can then do "thread apply all bt" and get a backtrace. That way it doesn't matter how you start spring!

[Beherith]

Sweet, thanks for the tip. The culprit was Threadpool, so I disabled it.