From: Daniel Armyr on 29 Apr 2010 03:28 Hi again. So is there someone out there who actually knows how to read these stack-traces?
From: Bruno Luong on 29 Apr 2010 03:52 "Daniel Armyr" <firstname(a)lastname.se> wrote in message <hrbce3$1ke$1(a)fred.mathworks.com>... > Hi again. > So is there someone out there who actually knows how to read these stack-traces? Very often the stack information is useless, because it only tells a very specific state of your computer and one point in time, when it already crashes. 99% it causes by memory corruption due to miss-use of pointers, arrays, ... The error should be tracked by the mean of debugging. Bruno
From: dpb on 29 Apr 2010 09:22 Daniel Armyr wrote: > Hi again. > So is there someone out there who actually knows how to read these > stack-traces? As Bruno says, for general debugging it's probably not terribly relevant. The documentation for the specific compiler may provide the details; may not. Not being primarily C/C++ but Fortran, I didn't recognize the particular compiler but probably the first value is the entry point to the routine. In general, the most effective thing is to use all error/warning generation facilities of the compiler in generating the code including array bounds checking, etc., etc., and minimize optimizations to make the compiler generate most linear (in sense of translation of source) while developing. Generally you'll either have a null pointer, either miss a dereference (or dereference what should be constant) or have a bounds error that generates the problem. Other things can happen, of course, but those are the most common. --
|
Pages: 1 Prev: Cholesky decomposition Next: Matlab Mex Compiler and Csdp.Exe Error |