Programming

I'm just saying that in these functions, the only memory I manage myself is in a single array, char line[]. All other memory management is done by the library. And since library-related memory troubles will be problems *within* the Pari stack rather than overflowing the Pari stack*, the particular tool recommended here seem powerless to help me.

What I would need is something that could help me debug memory use within the Pari stack.

* I recognize that you haven't seen the library code, so this you're going to have to trust... or not.

Agreed. It's error-prone, to be sure. The biggest problem (in my experience with this library) is leaving garbage behind, but I have had occasional problems of corrupted data -- say, moving the pointer too far so that some members of a live structure can be overwritten later.

The testing behind the library code is quite solid; I'm not concerned about it going past the end of the stack or overwriting things in the 'valid data' portion. My code, on the other hand, is comparatively suspect: I could move the pointer to the wrong place, so that the (correct) library code would overwrite my data.

There are, as you suggest, several stack variables, but the only one that I use regularly is avma, the "available memory area" pointer.

Memory related troubles within the pari stack will not cause inexplicable problems outside pari. To cause crashes in unrelated things, either the heap or the stack is getting mangled somewhere by something. Since this is clearly impossible, your program was never crashing and this thread does not exist, and you have no need of a memory debugger to check for problems that never existed.

Less sarcastically, 'garbage on the stack' won't crash stdio or anything else programmed sensibly. Every function call you make leaves garbage on the stack, pari's nothing remarkable in that respect. If you're getting segfaults in senseless places, either your stack's being corrupted, or your heap. (Or you're having hardware problems like memory errors.) A memory debugger -- or really, any debugger at all -- will be more useful than a thousand people staring at the 1% of your code you're willing to present. In the time we've spend arguing about it you could've tried lots of things.

Then the problem was never with memory.

Of course. It is something I need to be concerned with, though -- most of my early programs with the library were unusable (crashed whenever run) by using up all of the stack.

No, no segfaults -- not now, not before.

It died from some signal in a senseless place. If not a segfault then what? You didn't say, so we picked the obvious one to happen in that manner, a segfault.

Unfortunately I don't recall and it's fallen off the screen. Is there something analogous to .bash_history that keeps errors?

Let me get this straight: you have a custom memory management library, and your code using that library crashes?

OK.

You need all the help you can get. But there's not much out there.

Your only hope is to do something like download a demo copy of Purify and use it. And then pray that you don't have any bugs in your custom library.

And good luck.

You're going to need it.

There's a reason why nobody writes their own memory management libraries. First off, the multiple libraries available for free on your OS of choice are almost certainly fast enough. If they're not, you're most likely doing something wrong, like an over-reliance on malloc()/free() and/or new/delete. And if the OS libaries truly aren't fast enough (and if you're not multithreaded on a massively parallel application, they ARE fast enough!), there are third-party memory management libraries available.

Go price something like Smartheap. Then calculate all the hours spent on your custom memory library and how much those hours cost. Want to bet Smartheap is cheaper? If you even need it in the first place.

There are probably literally thousands of man-years invested by many absolutely brilliant computer scientists and programmers in all the memory-management libraries available in today's operating systems. And those products have been thoroughly tested - for literally decades.

You want a car analogy? Writing your own memory management library is like chiseling out a stone wheel for a sports car. The only reason to do it is for the sake of doing it - as a hobby or academic learning experience. Because there's no way you can duplicate the engineering history behind a "normal" wheel. Even if you do manage to chisel out a wheel that manages to outperform a "normal" wheel in a tiny operating range, you'll never really know how durable your wheel is because it's totally untested.

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!)