rebase: Throw OutOfMemoryError when gmp tries to allocate memory beyond the limit

[musm]

rebased #29029
and closes #8286
courtesy @grep0

[musm]

Is this name fine? Uppercase and all? What about ALLOC_OVERFLOW_PATCH ?

[musm]

I'm building julia but for some reason it's not picking up patches to GMP. My Make.user file looks like

MARCH=native
USE_BINARYBUILDER_LLVM=1
USE_BINARYBUILDER_OPENBLAS=1
USE_BINARYBUILDER_SUITESPARSE=1

Do I have to do anything special to make sure julia builds the patched GMP file?

FWIW this is from a cross-compile and withan out of tree build

Fixed: I had to delete the srcache file to get julia to patch the gmp file.

[musm]

Alright this PR is ready to be merged when ready. I confirmed also that it works locally.

[musm]

Looks like an unrelated spawn failure on 32-bit windows.

[KristofferC]

Restarted it

[musm]

thanks all green now

[musm]

@JeffBezanson you approved the original PR, does this now look good to merge?

[doronbehar]

Hey all and sorry for bumping an old thread. I'm trying to collect what libraries that Julia depends upon, haven't included the patches you suggested them. I noticed that GMP 6.2.0, which was released long enough after this PR, hasn't included the patch here. See:

https://gmplib.org/repo/gmp-6.2/file/tip/memory.c#l39

Is my observation correct? I'm curios because I'm trying to package Julia for my distro and I want to know what libraries it should be safe enough to use our distro's versions vs your patched versions.

[nalimilan]

Indeed #8286 was marked as upstream, but nothing happened AFAICT.

[doronbehar]

Is there a link to an upstream patch submission? No feedback at all from their side? I even consider nagging them myself (yea I know it's not easy since it's a mailing list and not a GitHub PR) but I need something to hold on, not to mention I'd need to check the patch applies to their current version...

[nalimilan]

I mean that AFAICT nobody reported it upstream so far. Filing an issue with our patch it probably better than doing nothing, even if the patch may be slightly outdated.

[StefanKarpinski]

Agree. If you wouldn't mind doing that, it would be greatly appreciated.

[cmcaine]

I emailed this to the gmp-bugs mailing list today because it didn't look like anyone else had done it yet.

If the mailing list software didn't hate gmail then it should be publicly visible in the October archives in a few days: https://gmplib.org/list-archives/gmp-bugs/2020-October/thread.html

[musm]

@cmcaine I opened an upstream request last month actually https://gmplib.org/list-archives/gmp-bugs/2020-September/004865.html looks like there is a library bug, but the resolution wasn't clear on which route the library developers are planning on going regarding this patch.

[cmcaine]

Woops! I don't know how I missed that :( Edit: Well, my repeat message prompted some new discussion about memory leaks, so that's okay. https://gmplib.org/list-archives/gmp-bugs/2020-October/004896.html Vincent Lefevre wrote: "Since the function could have allocated memory for intermediate computations, how do you avoid memory leaks?"

[StefanKarpinski]

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.