Hi,
I am getting an occasional interpreter crash in a pretty complex system that is hard to reduce, and it’s not exactly repeatable. I don’t know how to read apple crash reports, does anyone have any insights about what is causing this? All I can gather is that it’s to do with Qt …
0 sclang 0x102392dc0 DebugFrameConstructor::fillDebugFrame(VMGlobals*, PyrFrame*, pyrslot*) + 44
1 sclang 0x102392ce8 DebugFrameConstructor::makeDebugFrame(VMGlobals*, PyrFrame*, pyrslot*) + 260
2 sclang 0x102392ce8 DebugFrameConstructor::makeDebugFrame(VMGlobals*, PyrFrame*, pyrslot*) + 260
3 sclang 0x10238cc4c prGetBackTrace(VMGlobals*, int) + 44
4 sclang 0x10238ffc0 doPrimitive(VMGlobals*, PyrMethod*, int) + 192
5 sclang 0x1023fe59c Interpret(VMGlobals*) + 22164
6 sclang 0x1023f8d8c runInterpreter + 40
It has segfaulted while getting a backtrace, likely after an error has been thrown in sc. Since it fails while getting the trace, it seems likely the call stack is borked.
Do you have any code to reproduce this?
Huh… If an error is thrown in sc, it doesn’t make it to the post window… all that is printed is
Interpreter has crashed or stopped forcefully. [Exit code: 11]
I will try to codify a reproducer, but so far it’s happened twice and not happened twice while following the same long sequence of steps in a complex environment… not a fun one
If it’s within a try or protect block, then it has to collect the backtrace before posting the error dump. If it crashes while collecting the backtrace, then it won’t reach the point of posting the error.
hjh
Uh oh… I have several try blocks. I guess these aren’t totally safe then
It might be some where with lots of iteration, recursion, or processing lots of data.
I have eliminated all but two try blocks, which are necessary because they are interpreting user-supplied code and need to recover gracefully from a typo, and are only called at very specific moments. Since I have done this, I have been unable to reproduce the previous point at which this crash happened, which is encouraging. I had to write a couple tricky nested conditionals to make this work, which probably was the source of the previous error. But there is another crash that occurs while I’m certain neither of these remaining try blocks is active:
I see it is also trying to construct a DebugFrame… but again no error is posted.
As far as I can tell, what it was doing at the time wasn’t particularly iterative or recursive, or processing lots of data (unless you count the building of 9 image files max resolution in the neighborhood of 200x1800 pixels that it had done about a second before the crash – all appropriately .freed when done drawing)
Can you find any hints in this crash report?
(I have built in a feature where it saves a backup on each change, so I am able to load the last state before the crash… and doing similar activity on that backed up state doesn’t generate any errors)
I’m not good at reading these crash reports at all, but something caught my attention:
VM - Fault hit memory shortage
Are you running out of free memory? Could this indicate a memory leak somewhere that builds up over time until it crashes the application? In such cases, when you restart supercollider from the last known state, memory would not have been filled up yet, so no error would appear.
Oh interesting… I have been trying to keep tabs on memory consumption… while I’ve been watching it seems fine (freeing timeline frees all resources, no Object.dependantsDictionary buildup, etc.) – but there is an undo history which I just realized was growing unchecked. I don’t think it got terribly big in my scenario (I started my steps after fresh recompile), but I will limit its size and try the sequence of steps again. And watch my system memory this time.
Thanks everyone for these tips… from eliminating most try blocks and limiting undo history size I don’t get these crashes anymore.
I am still getting a very slow buildup of memory usage, which persists after language recompile and disappears when I quit and reopen the IDE. So far this hasn’t triggered a crash, but I wonder if there’s a way to find where this is coming from… as far as I can tell, everything is being freed when it should be.
Perhaps a long shot, but I’ve got a PR that fixes one known memory leak.
If you are familiar with building from source you could give that a try.
Otherwise, if you can produce an example that we can try it might be possible to track it down.