Re: Patch: support callback on allocation overflow instead of calling abort()

2020-10-07 Thread Colin Caine
I agree with what I think Marc is suggesting, that we can get a good solution
here without accounting for all (or perhaps any) memory leaks.

The Julia project doesn't really care about memory leaks in this context anyway.
Here's a comment by one of the language designers, Stefan Karpinski (they're not
subscribed to this list):

>> Since the function could have allocated memory for intermediate computations,
>> how do you avoid memory leaks?
>
> Not much you can do: chances are if you get to the point of OOMing, the
> process is going to crash, we just want the ability to do it more gracefully
> than a C abort call, which is something that a library should really never do.
> If GMP wants to be super careful, it could free anything that was allocated
> before returning an error, but it would also be fine to document that when an
> OOM error is returned some allocated memory may be lost.

(Original: https://github.com/JuliaLang/julia/pull/31215#issuecomment-704279237
)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs


Re: Patch: support callback on allocation overflow instead of calling abort()

2020-10-07 Thread Colin Caine
Hi Niels,

This sounds hopeful!


> To make any progress with adding a callback like this, we'd need to
> either:
>
> 1. Find out and document how to longjmp out from the callback safely.
>
> 2. Agree and document that when GMP invokes this callback, GMP state
> should be considered invalid. The process must not make any further
> calls to any GMP functions.
>
> And in the latter case, would that be satisfactory for Julia's use?

Yes, this latter case is sufficient for us.

Our users could catch the error and continue anyway, but we can
document, as you can, that this is risky.

On Tue, 6 Oct 2020, 15:59 Niels Möller,  wrote:

> Colin Caine  writes:
>
> > Sorry, this patch was posted to this list last month, but I didn't see it
> > in the archives. See here for related discussion:
> > https://gmplib.org/list-archives/gmp-bugs/2020-September/004865.html
>
> I asked some questions (some off list), and haven't seen satisfactory
> answers. The thing is, it seems fairly safe to use the propsed callback
> to write a friendly error message, backtrace of involved julia
> functions, etc, and then exit the process.
>
> But my impression is that julia may also longjmp out and continue
> execution, and to me, that seems very brittle. You can have memory
> leaks, you may leave GMP data structures in an inconsistent state.
>
> To make any progress with adding a callback like this, we'd need to
> either:
>
> 1. Find out and document how to longjmp out from the callback safely.
>
> 2. Agree and document that when GMP invokes this callback, GMP state
>should be considered invalid. The process must not make any further
>calls to any GMP functions.
>
> And in the latter case, would that be satisfactory for Julia's use?
>
> There are other approaches to avoid these crashes, e.g., I think the
> recent emacs integration uses a (configurable) limit on bignum size, and
> will raise an emacs exception long before hitting GMP's limits, and the
> emacs process can go on running with no issues.
>
> Regards,
> /Niels
>
> --
> Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
> Internet email is subject to wholesale government surveillance.
>
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs