Run it on RHEL. If there is a memory issue, it doesn't matter what OS you're running on. It just happens to manifest itself as a crash on one OS vs. another. I run into this issue all the time, as our applications run on both Windows and Linux, and a tool will crash on one OS, but not the other. However, running something like valgrind (or Purify) on the "good" system usually finds the error.
I just ran valgrind on RHEL but it doesn't show any error I expected like 'invalid offset' that might have caused the crash.
Attached is the valgrind output.
It happened that some valgrind was already there on the Freebsd machine as well. When I ran with it, I got a
==74907==
==74907== Invalid read of size 4
==74907== at 0x2D0A0942: __default_alloc_template<false, 0>::_Y_allocate(unsigned int) (stlinst.cc:142)
==74907== by 0x2D03EF3C: __default_alloc_template<false, 0>::_Y_allocate(unsigned int) (/home/y/include/g++/stl_alloc.h:502)
==74907== by 0x2D0A0EB8: __default_alloc_template<false, 0>::allocate(unsigned int) (stl/stl_alloc.h:436)
==74907== by 0x2DB6A82D: simple_alloc<_Rb_tree_node<LibEntry>, __default_alloc_template<false, 0> >::allocate(unsigned int) (/home/y/include/g++/stl_alloc.h:251)
==74907== Address 0x5B20552D is not stack'd, malloc'd or free'd
Attached is the whole output. Does this give out any clue?
Somewhere you are mishandling pointers and/or dynamically allocated memory. Any further information requires source code and us running the program.
Can someone please help? My project is stuck on this and am not even able to explain to superiors why I'm stuck.
A question: were you ready to debug these issues? Knowing how to debug issues with pointers and dynamically allocated memory should be a prerequisite if you were given responsibility for this program.
Regards,
Paul McKenzie
Last edited by Paul McKenzie; October 13th, 2009 at 04:57 AM.
I and others here that suggested the use of valgrind were hoping that valgrind would point out to the cause of the memory problem rather than only the effect , which is some Rbtree blah blah inside stl. Without any kind of clue to what is the offending code I don't see how even an expert with 30 years C++ experience would solve it.
I and others here that suggested the use of valgrind were hoping that valgrind would point out to the cause of the memory problem rather than only the effect , which is some Rbtree blah blah inside stl. Without any kind of clue to what is the offending code I don't see how even an expert with 30 years C++ experience would solve it.
I and others here that suggested the use of valgrind were hoping that valgrind would point out to the cause of the memory problem rather than only the effect , which is some Rbtree blah blah inside stl. Without any kind of clue to what is the offending code I don't see how even an expert with 30 years C++ experience would solve it.
Believe me, others and myself have solved much tougher problems. Crashing due to mishandling pointers or dynamically allocated memory isn't something weird -- your error is not unique to the world of C++. You are lucky in that you can duplicate the problem consistently. Much tougher problems are when the problem occurs intermittently.
How about commenting out code until the problem goes away (i.e. divide and conquer)? Then you introduce code until the problem exists.
Regards,
Paul McKenzie
Last edited by Paul McKenzie; October 13th, 2009 at 06:59 AM.
Without any kind of clue to what is the offending code I don't see how even an expert with 30 years C++ experience would solve it.
Again, you must be new to debugging C++ programs. Like I said, when you have dynamic allocation problems that's just how it is--completely different sections than the guilty section would crash. If no-one, even someone with '30 years experience' could fix it, then any large scale app would crash and be 'unfixable'. (is that what you're telling your manager? 'its an unfixable bug, not even the most experienced could fix it'? lame )
Fixing these types of bugs is not easy, but not impossible. Depends on how tenacious you are about it.
Those "Conditional jump or move depends on uninitialised value(s)" messages in the valgrind output are important. They may or may not be related to your specific problem, but you should focus on fixing them first.
With valgrind errors, as with compiler errors, always focus on the first one before moving on. Some or many of the later errors could be triggered by the first one.
Unfortunately, this error is one of the harder ones to track down even with valgrind, because it only tells you where the conditional occurred (typically an if statement or while loop), when the actual problem is the data being fed into that. You need to back-track that data and see where it's not being initialized properly.
Those "Conditional jump or move depends on uninitialised value(s)" messages in the valgrind output are important. They may or may not be related to your specific problem, but you should focus on fixing them first.
This message occurs not in my code but inside some of the dependent libraries such as ssl. There is nothing I can do about that.
I 'm still stuck with this god-foresaken issue.
This message occurs not in my code but inside some of the dependent libraries such as ssl. There is nothing I can do about that.
Corrupting the heap, passing bad parameters to the library, or not calling the library's initialize methods correctly are some possible ways that a bug in your code could be causing the crash to show up in SSL.
Originally Posted by BarefootGuy
I 'm still stuck with this god-foresaken issue.
You forever will be, unless you lose this 'the problem couldn't be in my code' / 'how could anyone possibly fix this' attitude.
Originally Posted by Paul McKenzie
How about commenting out code until the problem goes away (i.e. divide and conquer)? Then you introduce code until the problem exists.
Originally Posted by Martin O
Can you create an SSCCE that crashes on FreeBsd? Even though it won't crash on another OS, if you create a SSCCE, someone is more likely to be able to pinpoint your problem.
This message occurs not in my code but inside some of the dependent libraries such as ssl. There is nothing I can do about that.
Never blame other libraries unless you have solid, concrete, proven evidence that it is the library causing the problem.
I create third-party libraries, and in many of the cases where a user has a crash, it is their code (passing NULL or bad pointers to my routines, and sometimes not having a good grasp of the language they're using to communicate with my libraries, thereby munging things up and creating a messy program).
I 'm still stuck with this god-foresaken issue.
Then you need to get a good C++ programmer to sit down with you and actually work with your application. More than likely, it won't take them more than a day to fix or zero in your problem if they have the right tools for the job.
Messages on a forum going back and forth, with very little to no code, isn't going to solve your problem.
A great many of the valgrind errors occur due to a call you make on line 6670 in your main() function. My guess is you've got an uninitialized value in main() somewhere.
And by the way, a file over 6000 lines long is a good indication that you aren't being as modular as you should be.
It's possible that the valgrind errors could be false positives. Sometimes code is written like this:
Code:
if (x[0] != 0)
x[0] = 0;
and that could cause such a valgrind output without actually being dangerous. Although, I wouldn't write code that way because I believe in most cases the if statement could actually be slower than just doing the assignment.
However, you should assume there's a problem with your code until you've definitively determined that the issue isn't something you need to worry about, typically by inspecting the source of the library causing it.
Last edited by Lindley; October 19th, 2009 at 11:25 AM.
* The Best Reasons to Target Windows 8
Learn some of the best reasons why you should seriously consider bringing your Android mobile development expertise to bear on the Windows 8 platform.
Reply With Quote
Originally Posted by BarefootGuy
(is that what you're telling your manager? 'its an unfixable bug, not even the most experienced could fix it'? lame 
)