On Tuesday 25 August 2009 20:35:48 Juanjo wrote: > On Aug 25, 7:28 pm, Nils Bruin <nbr...@sfu.ca> wrote: > > 4) cl_boot() in libecl.so calls mp_set_memory_functions to set the > > memory functions, presumably on the copy of libgmp.a that has been > > included in the build of libecl.so (libecl.so is certainly not > > advertising any dependencies on libgmp.so when I call ldd on it). > > 5) I exit sage and get a segfault. The stack trace shows that > > free_integer_pool called ecl_dealloc. This is evidence that cl_boot > > called the mp_set_memory_functions that sage itself uses as well. > > I am afraid that dlopen is resolving the references in a wrong way: it > takes all occurrences of _mp* symbols in libecl.so and resolves them > using the symbols that are already installed from Sage's binary image. > Just a conjecture, though, from what happens when using dlopen / > dlsym : symbols are resolved using _all_ binaries that are loaded by > default, unless you specify which ones. > > I think that the cheapest solution is the one you suggested: allocate > the bignums manually and hope that GMP does not reallocate them. This > can be easily done in ECL, because the actual bignum creation is > restricted to a few functions in src/c/big.d. In all calculations with > bignums the procedure is as follows: > 1* Identify bignum operands > 2* Create one or more intermediate operators as GMP integers with > some preallocated limbs. > 3* Perform the calculations using the intermediate operators. > 4* Create a bignum object from the intermediate value. > 5* Clear that intermediate operator. > Steps 2,3,5 would work even with Sage's allocator, just by ensuring > that step 5* uses mpz_clear (Right now we do not need it). Step 4* > would be the only one to change, manually allocating the memory that > GMP needs. >
GMP will still need to allocate memory for internal needs using its allocator, but it is freed again . If the destination operand has enough memory for the largest possible output +1 then this should be enough , although I dont know if we can guarantee it , or if we want to( ie if we guarantee it now , then we have to forever) > And just to make it clear: I am more than willing to include these > changes in upstream, with the only constraint that it would be > selected by some configuration flag. > > 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 -~----------~----~----~----~------~----~------~--~---
