So you have no idea why code using your own personally-developed stack-modifier was crashing or how, or why it stopped, but are 100% certain it wasn't a segfault despite it having all the hallmarks of one because that would be inconvenient. Faith-based software-maintenance, I tell you.
Oh well, I'm done arguing until you have new data or questions. You know our positions already. Like achenle says, good luck, you're going to need it. (Though I thoroughly disagree that there's no way to improve on modern memory management!)
I don't know what you mean by "custom", but yes I have a library and yes it forces its users to manage memory in a particular way. But memory management is not the purpose of the library: it's for computational and algebraic number theory.
The code did crash when I posted this thread. I since rewrote large portions of the code and it works now.
Probably.
I don't really have a choice: if I want to use the Pari library, I have to work with its memory management.
But I don't really think it's that bad. Here are some selections from the user manual on Pari:
� First, PARI routines do their own garbage collecting, which means that whenever a documented function from the library returns, only its result(s) have been added to the stack, possibly up to a very small overhead (non-documented ones may not do this). In particular, a PARI function that does not return a GEN does not clutter the stack. Thus, if your computation is small enough (e.g. you call few PARI routines, or most of them return long integers), then you do not need to do any garbage collecting. This is probably the case in many of your subroutines. Of course the objects that were on the stack before the function call are left alone. Except for the ones listed below, PARI functions only collect their own garbage.
� It may happen that all objects that were created after a certain point can be deleted - for instance, if the final result you need is not a GEN, or if some search proved futile. Then, it is enough to record the value of avma just before the first garbage is created, and restore it upon exit:
pari_sp av = avma; /* record initial avma */
garbage ...
avma = av; /* restore it */
All objects created in the garbage zone will eventually be overwritten: they should no longer be accessed avma has been restored.
[...]
First, gerepile has turned out to be a flexible and fast garbage collector for number-theoretic computations, which compares favorably with more sophisticated methods used in other systems. Our benchmarks indicate that the price paid for using gerepile and gerepile-related copies, when properly used, is usually less than 1% of the total running time, which is quite acceptable!
Second, it is of course harder on the programmer, and quite error-prone if you do not stick to a consistent PARI programming style. If all seems lost, just use gerepilecopy (or gerepileall) to fix up the stack for you. You can always optimize later when you have sorted out exactly which routines are crucial and what objects need to be preserved and their usual sizes.
It's not an option, because I need to use Pari.
---------- Post updated at 02:23 PM ---------- Previous update was at 02:17 PM ----------
I saw what the error was at the time, but that was several days ago. I don't recall now. I can recognize a segfault when I see one.
Important clarification here: I certainly did not develop the library! It's taken two Ph.D projects and dozens of contributors almost two decades to create.
This is something of a "Corona688-told-me-so" post.
I found the error, and it was a SEGFAULT-causing error. But it wasn't anything to do with Pari's novel memory management; just a simple mistake anyone could have made (and I was apparently boneheaded enough to make).
char* kept = getBValue(line);
GEN value = strtoi(kept);
if (kept == NULL)
continue;
My function getBValue, if it cannot find a value in the line it is passed, returns NULL. Rather than testing its return value (kept) for NULL, I pass it to anther function... and only then test for NULL.
