Le dim. 1 janv. 2023 à 11:10, Tim Daly <[email protected]> a écrit :
>
> 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.
No, it's a shared library (a wrapper) built in the fricas/src/lib
directory and loaded at startup with libjulia.so.
(defun init-julia(wrapper-lib)
(if (ignore-errors (|quiet_load_alien| wrapper-lib) t)
(|quiet_load_alien| "libjulia.so")))
> Since the failure is being caught in Julia there could be a couple
> reasons. One I already mentioned (replace and chain failure).
Yes, my first thought is to temporarily bypass the Julia signals
handler and see what happens at SBCL level. When I encountered the bug
mentioned at the beginning of this thread what came in my mind was a
bad memory access to arrays or something like that and I modified
src/lisp/interp-proclaims to (debug 3) (safety 3) but, yes, Julia
catches the signal and crash as it has no way to handle this error:
fatal: error thrown and no exception handler available.
ReadOnlyMemoryError()
So this modification was without effect.
> 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
Yes!!! Good! I'll test that. Since this is implemented there must be a
way to bypass Julia signals handler via the Julia library.
Otherwise, I think I'll have to first look at Julia source code and
eventually do a temporary dirty hack to Julia.
__
Greg
PS: I'll take a look at the second part of your mail later as it
contains tons of things.
> 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.
--
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/CAHnU2dbfSkBvG5ebnj8_VttE7ZEdjYGRh%2BUZUsRerOecsXE9FA%40mail.gmail.com.
