[Mingw-users] "msvcrt!_abnormal_termination" in XP but not win7

[James H. <bi...@de...>]

My first post... bear with me. I have an application-crash issue that isn't 
behaving like other crashes I've seen. (I searched the list for 
"msvcrt!_abnormal_termination" and the only matching post wasn't relevant.)

The application is SuperCollider [1], a programming language for music and 
audio. The backend is in c++ and implements its own byte code interpreter for 
the object-oriented language. Typically, code is run interactively using one of 
several editor interfaces, but this issue reproduces when using the generic 
readline interface, so we don't have to worry about other front ends.

The issue occurs when something (in the sc-language) is scheduled on the most 
commonly used clock, BUT -- only in Windows XP. There's no problem in Windows 7. 
Also, it isn't a general problem with scheduling in the language. Another type 
of clock (SystemClock, which always runs in seconds) doesn't show the problem.

// this should wait half a beat, then print "hello\n" in the console
// 1 beat usually = 1 second, but the tempo can be changed (hence TempoClock)
TempoClock.sched(0.5, { "hello".postln });

Running sclang in gdb turned up a surprisingly short stack trace. No prior stack 
frames before the abnormal_termination.

#0  0x77c3554a in msvcrt!_abnormal_termination ()
   from C:\WINDOWS\system32\msvcrt.dll

The results of "thread apply all bt" can be found at [2], about halfway down the 
page.

I also wanted to "git bisect," but I can't find a "good" commit in my XP build 
environment. This is strange because of the issue's history:

- SC3.4.x was compiled using MSVC, with a python front-end. No problem with the 
above code.

- SC3.5 - 3.5.4 was compiled using mingw, and can be run from the command line 
(readline interface) or using gedit as a front-end. In the binary releases 
(built in win7), there is no problem with the above code in either win7 or XP.

- SC3.6 is also compiled using mingw, and the binary (alpha) releases so far 
have been built in win7. No problems with the test code in win7, but it crashes 
in all XP environments.

- At first we thought it might be an issue with using a binary in XP, which was 
built in win7, so I set up a mingw environment on one computer that is still 
running XP, using the same dependent libraries that were used for the win7 
build. In my builds, the issue occurs going all the way back to the 3.5.0 source 
code -- whereas the problem doesn't happen in the 3.5.x builds that were made by 
my colleague running win7 (but it does occur in his 3.6 builds).

Oh, and the problem goes away in my builds if I switch my CMAKE_BUILD_TYPE to 
"Debug."

What's making this especially difficult to troubleshoot is that none of the 
SuperCollider developers knows Windows development very well: enough to 
configure mingw but not enough to know what to do with mysterious problems that 
seem to involve the "fine print" of Windows system DLLs.

So I thought I would ask if anyone has seen anything like this, or has any ideas 
how to get more information when gdb doesn't say much and git bisect can't be 
used. (Or, if there's a better place to ask the question, recommendations would 
be welcome.)

Thanks,
hjh


[1] http://supercollider.sourceforge.net
[2] https://github.com/supercollider/supercollider/issues/547