On Aug 23, 9:14 am, Nils Bruin <nbr...@sfu.ca> wrote: > So it's no surprise at all that integer_free_integer_pool seems to > call ecl_dealloc, because it does (via some gmp macro for deallocating > a gmp integer), and since that integer was allocated by another memory > manager, a segfault is entirely expected. > I think this is a complete showstopper for including ecl as a library. > Not letting ecl set its memory management for gmp would not be an > option, because only ecl knows if the memory can be freed.
ECL does not free its own memory. It leaves the task for the garbage collector. I see several solutions, and perhaps many others exist, so no "complete showstopper" - Build ECL with its own copy of the library using a different namespace. - Make GMP/MPIR's allocation routine a thread-local value and run ECL in its own thread. This is probably the most elegant solution and best for Sage -- running ECL in its own thread is the closes to isolating it without running a separate process. - Let the garbage collector handle also all memory allocation in your code. This can be done, for the garbage collector is designed to coexist with arbitrary C code and provides wrappers to malloc/free. - Surround ECL's uses of GMP (probably more "concentrated" than Sage's) with mp_set_memory_functions. > Concerning signals: > > Is it necessary for ECL to be notified of signals? I think it's good > if sage gets them, so "sigaction" might be the better way to go. ECL does not need to be notified of signals. The important thing is that Sage's code does not interrupt ECL's code at arbitrary places and then transfers control out of them. For instance, interrupts during memory allocation are bad. Also when initializing certain objects. If the interrupt handler jumps out of that code in an arbitrary way, the program may be left in a corrupt state. If your signal handler does not jump to outer points, but rather does normal returns, then there is no problem with installing that handler. Otherwise, as I said, we can instruct ECL's handler to delay signals after the critical code has finished and then pass them to whatever handler was installed before. Use of sigaction inside ECL is definitely _not_ an option. It is a very expensive call to put in front of every memory allocation routine. As a side note, no sensible signal handler would do any other thing than returning, for POSIX interrupts do not guarantee reentrancy of code. However, I do not know what is the quality of Sage's interrupt handling right now. Juanjo --~--~---------~--~----~------------~-------~--~----~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
