If you run Julia in a separate process and use a socket connection then the SIGSEGV use by SBCL won't matter as the handlers would be swapped by the system at process swap time.
If you are using sb-ext:run-program the sub-program, in this case, Julia would have to replace-and-chain SIGSEGV. Since the failure is being caught in Julia there could be a couple reasons. One I already mentioned (replace and chain failure). Another might be how sb-ext:run-program handles process memory. It could be that there really isn't enough process memory to run Julia as a sub-process. For size-limited computations enlarging memory as you did would work fine. Julia seems to use 200MB of memory https://discourse.julialang.org/t/julia-memory-overhead/1861 Julia provides "handle-signals" to enable or disable default signal handlers: julis --handle-signals=no A more subtle error might be that SBCL moved a memory reference from the embedded process interface. See https://docs.julialang.org/en/v1/manual/embedding/ A known approach is to use swank (this is how emacs embed certain programs): https://github.com/brown/swank-client If you really want to play hardball then allocate sbcl memory with the allocated object is larger than BYTES-CONSED-BETWEEN-GCS. This it tends to get promoted to gen 1 right after allocation, while the reference is still live. Allocate all Julia memory from addresses within that block. Or you could memory-map a "file" and do what appears to be file-io but use memory references into the pseudo-file. When all else fails you could hack Julia source code with an SBCL friendly function to call along with some SBCL friendly routines to copy Julia/SBCL objects back and forth. There are many ways to skin a cat. Be sure to read the side of the box: This is a quantum entanglement test. Please be sure that you observe the cat before choosing to skin it. Tim On Sat, Dec 31, 2022 at 4:29 PM Waldek Hebisch < [email protected]> wrote: > On Sat, Dec 31, 2022 at 04:29:48PM +0100, Grégory Vanuxem wrote: > > Hi, > > > > In fact I think this is the well known SBCL message: « heap is exhausted, > > augment dynamic space size » or something like that. > > Hmm, you should not see this on so small computation. SBCL uses > SIGSEGV to determine if pages are modified or not. If you run > sbcl via gdb you should see a lot of SIGSEGV-s which in C program > would mean crash, but are normal in sbcl. > > You write that you can run when you give 8G to sbcl. I would be > _very_ suspicious of such a solution. Simply, I saw too many > programs that were horribly broken, yet under light tests > appeared to work correctly. One possiblity is that having 8G > you did not manage to trigger sbcl garbage collection (or maybe > major collection since sbcl collector is generational). > > -- > Waldek Hebisch > > -- > You received this message because you are subscribed to a topic in the > Google Groups "FriCAS - computer algebra system" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/fricas-devel/9WNtYSSJp0w/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/fricas-devel/20221231221319.fdm4yfoakbt5vbnc%40fricas.math.uni.wroc.pl > . > -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAJn5L%3DKKtUB2RvaPJ2vWODk%2Bm1D7xSSVvF9fQd%3D28pvvLuTYdg%40mail.gmail.com.
