Why do segmentation faults happen when using the ProJucer? I’ve noticed that when I add code to mainContentComponent::paint(Graphics &g) that if it involves using g at all (like, g.drawLine() ) i’ll get a segmentation fault and will have to quit ProJucer, reopen it, Clean the project and then it’ll work fine. But why? I can edit numerical values for existing code while using ProJucer just fine, but if I add new code, it’ll either crash the JIT or cause this segmentation fault forcing me to restart ProJucer. it’s not a deal-breaker, but it is annoying…
Can you explain more clearly what you’re seeing? Because if the JIT crashes, you don’t have to re-start the app - that’s why we use a child process.
I’m seeing stuff like this:
All i did was type line 72 and it hangs.
No amount of cleaning, or clicking the restart compiler button gets it going again. I have to quit ProJucer and reopen the project.
Very odd… Cleaning and restarting the compiler will basically restart everything. Can’t really see why relaunching the app would make any difference.
We’ll be doing more debugging + fixing of the projucer as we go on, but would always expect there to be edge-cases where it crashes because of random internal state issues.
cool. if you want, I can send a zip of what I was working on, and maybe you can see what my code was doing to trigger this. It would be amazing if you guys eventually got ProJucer working to the level that AirCode works for the app Codea, which is a LUA IDE for iPad.
Just to add a bit more info to this, it seems if I have some code like this and change one of the values from positive to negative, it always causes a segmentation fault.
sheer.startNewSubPath(startX + (0*horizontalScale), startY + (0*verticalScale));
//change a 0 to a negative value via the slider in ProJucer
sheer.startNewSubPath(startX + (-3*horizontalScale), startY + (0*verticalScale));
//results in segmentation fault.
So maybe your JIT compiler is assuming that i’m using a uint there instead of an int? However, it might be tied to my being zoomed in more than 100% while changing values? that always results in a segmentation fault
so here’s what I’ve deduced.
I have no issues with proJucer if I turn off Real-Time Compilation and instead use “Command B” to update my code, provided that I save the file after I update it before building it again.
However, clicking on a slider that appears when you hover over a number seems to turn on real-time compilation even if it’s turned off.
If I write a line of code that hasn’t been compiled yet, and then hover over a numerical value such that the slider appears and click somewhere on the slider, I’ll get a segmentation Fault. Obviously, i’m modifying values for instructions that haven’t been compiled yet so that makes sense. A solution might be to not display the slider on numbers that are part of lines of code that haven’t been compiled yet… just a thought.
I still have the issue of when a number changes from positive to negative, or changes from single digits to double digits causing a segmentation fault. It seems like the Compiler is having trouble dealing with parsing the extra characters? Like it’s already determined that the token at line X Character Y is only 1 character long, and when it encounters 2 characters (the minus sign), it doesn’t know what to do, and all of the tokens that follow can’t be processed because they’re no longer in the original position they were tokenized at? I’m grasping at straws here… just trying to think out loud…
I can’t reproduce any of this… It’s tricky with this kind of thing because it depends a great deal on your exact code structure, but I tried the whole negative->positive thing and turning compilation on and off, but it all survived just fine in my test cases…