Eliot, Replacing the Smalltalk code with C would be daunting task. I had a similar idea, which was to write something that does the iteration in one function. That would be more manageable, but when faced with the reality of doing even that, I was reminded that one scenario worked perfectly, and one was giving goofy results. The latter might have been an illconditioned model. A slightly simpler model fits the data without "getting itself in a twist." Some additional diagnostic output will show me what happened just before a segment fault. It's possible that I'm accessing some undefined state after a failed iteration, or something equally silly. Still, I think the segment faults are overkill/suspicious. Bill ________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Eliot Miranda [eliot.miranda@gmail.com] Sent: Wednesday, May 09, 2012 11:58 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Help reading dump? On Wed, May 9, 2012 at 8:16 AM, Schwab,Wilhelm K <bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: The attached is diagnostic output from the Linux vm. I am doing some iterative numerical analysis that won't always work out, so I expect errors and non-sense results at times - it all depends on whether a particular segment of a signal is clean or noisy; if the latter, all assumptions are off. One thought is that early terminated iterations (or maybe ones that go too long?) are leaving conditions that finalization can't clean, or maybe does not clean before the next iteration begins. A segmentation fault seems a bit harsh, but they are happening and I need to find a way around them. Is there anything in the attached dump that strikes you as significant? Maybe something that says whether its the main thread or a background thread that's blowing up, or some other clue that is obvious to the correct eye? As it is, I see the #iterate, #basicIterate part of the stack, which is what I would expect the code to be trying to do - fit curves to data. The numbers at the beginning are trace info (using C++ cout) to confirm sanity of the arriving parameters. My next thought is to add some more tracing to show which segment/harmonic is being attacked as it blows up. Then I might be able to set clever breakpoints and get some handle on it. Suggestions are welcome. Put instrumentation around the calls that allow you to write a C program that makes the exact same calls and see if that crashes? Bill -- best, Eliot