hokay... I think I have a method of getting the IDE to run with gdb attached, which might be useful in trying to trace where things are going wrong (although Max doesn't produce any meaningful symbol code... so mileage isn't likely to be much)
The following enters the realms of shell scripting... if you aren't sure, stay away ;-)
Create yourself an executable script with something along the lines of the following in it :
..change the name of "gtkMaxIDE" to the name of the app you want to attach gdb to.
This launches the application in the background, then immediately launches gdb and attaches it to the PID of the app.
You should then see a large list of "reading symbols" statements, as gdb processes all the libraries.
Once it has finished, you should be left with the following prompt:
do "continue" to carry on with the app startup...
If your application crashes, you should then be able to enter "bt" or "backtrace" and it will reveal where things went wrong.
One downside to the way in which Max is set up is that by default, SIGV signals (seg-faults / crashes) are trapped by Max and passed on safely, in which case gdb will tell you that your app in fact exited happily.
If you *really* want to do some serious debugging, you will need to comment out the following line of appstud.linux.c in the appstub module:
:o)
The following enters the realms of shell scripting... if you aren't sure, stay away ;-)
Create yourself an executable script with something along the lines of the following in it :
./gtkMaxIDE & gdb ./gtkMaxIDE $!
..change the name of "gtkMaxIDE" to the name of the app you want to attach gdb to.
This launches the application in the background, then immediately launches gdb and attaches it to the PID of the app.
You should then see a large list of "reading symbols" statements, as gdb processes all the libraries.
Once it has finished, you should be left with the following prompt:
(gdb)do "continue" to carry on with the app startup...
(gdb) continue
If your application crashes, you should then be able to enter "bt" or "backtrace" and it will reveal where things went wrong.
One downside to the way in which Max is set up is that by default, SIGV signals (seg-faults / crashes) are trapped by Max and passed on safely, in which case gdb will tell you that your app in fact exited happily.
If you *really* want to do some serious debugging, you will need to comment out the following line of appstud.linux.c in the appstub module:
signal( SIGSEGV,sighandler );
:o)