If a random C library (call it libfoo; this can be gtk or something else entirely unrelated to julia) calls a callback which then calls longjmp, it’s very likely that the state of the data structures managed by libfoo will be corrupted. That is, unless libfoo has been explicitly and very carefully designed to be safe for this kind of thing which is fairly uncommon. There is nothing the julia task runtime can do about this; if you do throw an exception which skips over the stack frames of an external library anything may happen, including memory leaks, resource leaks, random segfaults hours later, or if you’re very lucky nothing bad at all. Don’t rely on it!
The julia runtime itself has been explicitly and carefully designed to be exception (currently implemented with longjmp) safe, but only for longjmps which are managed by julia itself. If you find a case where a native julia exception crashes the julia runtime (with or without a crash dump) this is a bug and should be reported. Just don’t mix julia exceptions in callbacks with external library code and expect it to work 
If you mixed C++ exceptions with C longjmp there’s a good chance of memory corruption etc, and std::terminate would never be called there either.