Re: [Gcl-devel] Bug#816982 closed by Camm Maguire <address@hidden> (Bug#816982: fixed in maxima 5.38.0-3)

[Camm Maguire]

Greetings, and thanks again for your report!

While this issue was related to the strategy with which GCL seeks to use
available memory, the issue also pertains to an anomaly in the algorithm
the kernel uses to detect oom, hence the appearance only under
particular combinations of ram and swap.  Specifically, GCL probes brk
at startup to see how much memory it can grab, and uniformly grows
within this bound by a size-independent algorithm.  If the fault purely
lay with GCL, it should show up in all memory configurations.  Instead,
the kernel is denying a fork()/exec() required to run gcc externally in
certain quasi-half-full situations but not others.  The unpredictability
mimics earlier problems on certain machines in which brk() would deliver
the memory only for the kernel to give a segfault later when writes to
it were attempted.

Now it is true that this fork()/exec() could be made more robust and
oom-resistant by using posix_spawn() or equivalent procedure that does
not attempt to copy the virtual memory image.  Even though Linux is
copy-on-write, the kernel page tables must still be copied, even though
they will never be used if we immediately call exec().  But this only
minimizes the issue.

Better still would be to spawn a gcc-calling daemon early on with
minimal memory footprint.  Then one avoids spawning children as memory
gets full.  I may get around to this.

For now I've put in a heuristic to try to match the heuristic used in
the kernel.  We default GCL_MEM_MULTIPLE to 0.85, which appears to
always allow the fork()/exec() to run.  This obviously is not optimal,
but works for now.

Take care,

Santiago Vila <address@hidden> writes:

>>    * Bug fix: "FTBFS when built with dpkg-buildpackage -A (tests fail)",
>
> Thanks a lot.
>
> Perhaps I should have made a bug retitle because I suspect this did
> not have anything to do with "dpkg-buildpackage -A" as such.
>
> You talked before in this bug about problems with garbage collection.
> Would be possible for you to tell (briefly) what kind of problem this
> was after all?
>
> And more importantly: After the fix, will it now work with 2GB of RAM
> as well as 3GB or 4GB or any higher amount of memory?
>
> [ You will remember that the fact that it worked ok in your computer
>   and it did not in another one with more memory was the most annoying
>   thing about this bug ]
>
>
>
>

-- 
Camm Maguire                                        address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah