crash combat

[msepsis]

I’m wondering if there might be anything that can be done to the structure of the environment in which ctrlr panel Lua scripts run to help prevent ctrlr from crashing when debugging scripts? There’s a very nice tracker that’s been out for a bit of time based off fasttracker called renoise which allows you to build lua based tools, somehow they managed to design the sandbox so renoise *never* crashes on Lua errors, it simply disables the script and reports the error.

I’ve just been noticing a lot more frequent lock ups / crashes in ctrlr on both mac and windows than historically when ctrlr would be more likely to just give an error and disable the script. . . who knows might just be that the panel has gotten more intricate and complex than before.

. . . still it’s not up to you to ensure we’re writing good code but we’re all human and ctrlr seems to be a bit more less forgiving to syntax errors, etc lately.

just curious!

Monstrum Media | Music, Sound & Software Design, Chicago / San Francisco listen

[atom]

I can’t really seperate Lua that way, since i let lua access program memory directly so that it can quickly access stuff like MIDI data etc. I guess i could seperate that somehow, but the performance would suck.

I don’t know how you guys do it, so far i have not managed to crash Ctrlr using Lua, yes i managed to crash Ctrlr because of other bugs in the c++ code, just not Lua.

If you can tell me what situations or what Lua code is causing the crashes i can work on implementing those methods better, please remember that any method/class in Lua that’s not native lua is coded by me or is a direct binding to JUCE (that direct binding does net guarantee it will be stable though). A lot of stuff is re-written by me to act as JUCE classes but had to be modified.

So maybe you can give me some info on what’s the biggest problem and I’ll try to make it better.

[SWB]

Well, I’m not sure but all this crashing reminds me of my own crashing hell experiences on my Mac a few months ago. Look at this topic: http://ctrlr.org/forums/topic/crashing-hell-on-mac-please-help/
and then especially towards the end of the topic where atom mentions an issue with the Apple LLVM compiler… But maybe I’m totally wrong. If so, my apologies!

[msepsis]

atom wrote:

so far i have not managed to crash Ctrlr using Lua…

I’m sure you likely take a lot less pokes in the dark than some of us do w/ scripting as you certainly have a far deeper understanding of it than at least I do. So this doesn’t really shock me. If it’s not possible to crash proof ctrlr w/o taking a performance hit that’s fine.

one thing I know off the top of my head that will crash ctrlr because of lua scripting is if I click a save to / load from file button on my waldorf rocket panel, then hit cancel when the file browser pops up. I can shoot you the panel in a pm in a second.

On a mac if you have any lua errors the program (ctrlr) just locks, spinning wheel of death and ctrlr stops responding w/ no option but to force quit. At least on windows you tend to get more opportunity to see what the problem is via error messages but on a mac, forget it. In a few cases I would just open the panel on ctrlr for win in xp to try to get some hints via error messages. In some cases I’d get an error message but in others ctrlr (rev 1454) would suddenly crash when simply opening the Lua editor, or just seemingly out of the blue, 20 seconds after hitting a button with a script and seeing seemingly normal operation. Since it typically happens for me (crashes) after implementing some new feature I think of to the panel then debugging any potential issues it’s pretty hard to pinpoint exactly which Lua syntax error(s) crash ctrlr otherwise I wouldn’t be debugging it – i’d know what the issue is — Or if I was you i’d be smart enough not to make the dumb mistake in the first place which causes the crash / lock up! 🙂

• This reply was modified 10 years, 10 months ago by msepsis.

Monstrum Media | Music, Sound & Software Design, Chicago / San Francisco listen

[Author]

Posts