> > And when I run the release-0.3 branch under valgrind (even something as >> simple as the empty script `julia -e ""`), the results can be somewhat >> scary (at least that is my interpretation). > > Valgrind tends to report false positives in language runtimes using > mark-and-sweep garbage collection, if I recall correctly
The valgrind issues I saw last time I ran it (2 mo. ago) were mostly (possibly all) missing suppressions for core calls like memcpy. I haven't yet tried with the latest valgrind version as suggested here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758905 On Tue, Dec 30, 2014 at 5:27 PM, Steven G. Johnson <[email protected]> wrote: > > On Tuesday, December 30, 2014 5:02:00 PM UTC-5, Jim Garrison wrote: >> >> Part of the reason I was inclined to think that exceptions are >> unsupported is that I often see my code segfault if I create an exception >> e.g. by pressing Ctrl+C. For instance, if I open the REPL, and type >> >> julia> x = rand(4000,4000) >> julia> x * x >> >> and press Ctrl+C during execution, I nearly always get a segfault. In >> Python I almost never see a segfault as an exception unwinds (and when I >> do, I file a bug). But in Julia it seems to be the norm for me. >> > > I'm not seeing a segfault in this particular case on my machine, but in > general the difficulty is that external C libraries (such as openblas) are > rarely interrupt-safe: stopping them at a random part and then restarting > the function call will often crash. My suggestion has been to defer ctrl-c > interrupts (SIGINT signals) around external C calls (ccall), but this has > not been implemented yet: https://github.com/JuliaLang/julia/issues/2622 > > (My understanding is that Python similarly disables interrupts in external > C library: > http://stackoverflow.com/questions/14271697/ctrlc-doesnt-interrupt-call-to-shared-library-using-ctypes-in-python > ) > > >> And when I run the release-0.3 branch under valgrind (even something as >> simple as the empty script `julia -e ""`), the results can be somewhat >> scary (at least that is my interpretation). >> > > Valgrind tends to report false positives in language runtimes using > mark-and-sweep garbage collection, if I recall correctly > > Steven >
