One of the "problems" with BlitzMax is that it "wraps" some of the low level signals so that they are caught and throw an exception instead. Which is fine, until you want to know exactly where the error occurred.
It traps the SIGSEV signal, so tools such as gdb won't be able to show you *where* the segfault happened.
If you comment out, in appstub.linux.c :
build mods, and run again, the app should segfault without the exception you are currently getting.
It's then just a case of running the app via gdb, where you should be able to backtrace on the sigsev, and find out what *exactly* is breaking.
Obviously, I would consider this *advanced*, use, and only something you'd want to try if you knew what you were doing down there to start with ;-)
One thing to note is that gdb can appear to lock up when running GTK code. You can sometimes get around it by ctrl-c'ing -> continue -> ctrl-c -> continue, a few times. Or, kick off the app, and *then* run gdb using the "pid" option.
As I said, it's advanced stuff to fiddle about with, and you may not want to dirty your hands down there :-)
It traps the SIGSEV signal, so tools such as gdb won't be able to show you *where* the segfault happened.
If you comment out, in appstub.linux.c :
signal( SIGSEGV,sighandler );
build mods, and run again, the app should segfault without the exception you are currently getting.
It's then just a case of running the app via gdb, where you should be able to backtrace on the sigsev, and find out what *exactly* is breaking.
Obviously, I would consider this *advanced*, use, and only something you'd want to try if you knew what you were doing down there to start with ;-)
One thing to note is that gdb can appear to lock up when running GTK code. You can sometimes get around it by ctrl-c'ing -> continue -> ctrl-c -> continue, a few times. Or, kick off the app, and *then* run gdb using the "pid" option.
As I said, it's advanced stuff to fiddle about with, and you may not want to dirty your hands down there :-)