|
From: Philippe W. <phi...@sk...> - 2013-01-17 20:19:04
|
On Thu, 2013-01-17 at 20:02 +0530, Muthumeenal Natarajan wrote: > Hi Rich, > > Sure, Thanks for your help. > Pls do let us know..if this is something to do with C++ (when using static variables, > if we remove the static variables from the class, it gets postponed to another class > down the line which has static variable...) If so, is there a work around or patch ? > We can't remove these static variables from these classes.. > so pls help us to run valgrind with our code. > > Also if this is the problem with C++, you must have already got such error reports. > .we remember seeing some blogs with patches for the same, we couldn't download the > same...so pls let us know if there're patches in official valgrind site which can be used. The previous logs you have captured have quite clearly shown that the problem is *not* a lack of memory. The advice of Rich to create a small set of sources allowing others to reproduce the problem is a good way to work. If that is not possible (closed sources) or too difficult, I suggest you follow then my previous advice: Have two GDBs, one debugging a native (working) execution; another GDB debugging the execution under Valgrind. Of course, do not let it run till it crashes. Instead, put breakpoints before the crash (for example at NewDelete.cpp:64 or at LtePdcpConstants.cpp:7) and then use next/step/... in parallel in both GDBs. Then at some point in time, the behaviour will diverge. That might give some idea what is going wrong. Philippe |