what is this non-sense error?

The below crash happens during the constructor of a class that has a member that is a templatized "set"
Happens only on Freebsd not on RHEL.
Can someone please help? My project is stuck on this and am not even able to explain to superiors why I'm stuck. I've seen nothing as meaningless as this error.

#0 __default_alloc_template<false, 0>::_Y_allocate (__n=32) at stlinst.cc:142
#1 0x200baf3d in __default_alloc_template<false, 0>::_Y_allocate (__n=32)
at /home/y/include/g++/stl_alloc.h:502
#2 0x2011aeb9 in __default_alloc_template<false, 0>::allocate (__n=32) at stl/stl_alloc.h:436
#3 0x20ad382e in simple_alloc<_Rb_tree_node<LibEntry>, __default_alloc_template<false, 0> >::allocate (__n=1) at /home/y/include/g++/stl_alloc.h:251
#4 0x20ad2af4 in _Rb_tree_alloc_base<LibEntry, allocator<LibEntry>, true>::_M_get_node (
this=0xb0254) at /home/y/include/g++/stl_tree.h:475
#5 0x20ad416c in _Rb_tree_base<LibEntry, allocator<LibEntry> >::_Rb_tree_base (this=0xb0254,
__a=@0x9fbff9d0) at /home/y/include/g++/stl_tree.h:491
#6 0x20ad38bb in _Rb_tree<LibEntry, LibEntry, _Identity<LibEntry>, less<LibEntry>, allocator<LibEntry> >::_Rb_tree (this=0xb0254, __comp=@0x9fbff9cf, __a=@0x9fbff9d0)
at /home/y/include/g++/stl_tree.h:653
#7 0x20ad2bc0 in set<LibEntry, less<LibEntry>, allocator<LibEntry> >::set (this=0xb0254)
at /home/y/include/g++/stl_set.h:75
#8 0x20acffdd in RestppLibCache::RestppLibCache (this=0xb0248) at RestLibCache.cc:180

You might want to provide some context with the code near line 180 of RestLibCache.cc, along with any relevant declarations.

Line 180 is just the default constructor

RestppLibCache::RestppLibCache()
{
/* nothing to do... */
}

The relevant declarations are
struct LibEntry;
protected:
typedef std::set<LibEntry> entries_t;
entries_t m_entries;

It's possible something in the program prior to that point is corrupting the heap. A tool like valgrind (on Linux) is usually best for pinpointing such issues.

Then it should have crashed at some earlier spot after I set
export MALLOC_CHECK_=2
right? But it didn't.

However I do believe something else is causing the crash because this started happening after some major refactorings across files (but not inside this file) . I just don't know how to catch the problem.

Paul,
As far as this class is concerned I think I have pasted all relevant code. As you can see in the stacktrace it crashes while instantiating the std::map<LibEntry> member. I don't see why what code precedes or surrounds it should matter.

Quote:

---

Originally Posted by BarefootGuy

Then it should have crashed

---

There is no "should of crashed" in the world of C++. Crashes are never and should never be expected to be "guaranteed" to occur.

Regards,

Paul McKenzie

Quote:

---

Originally Posted by BarefootGuy

Then it should have crashed at some earlier spot after I set
export MALLOC_CHECK_=2
right? But it didn't.

However I do believe something else is causing the crash because this started happening after some major refactorings across files (but not inside this file) . I just don't know how to catch the problem.

---

Make sure you are rebuilding the entire source, and not just a few modules.

Regards,

Paul McKenzie

Quote:

---

Originally Posted by Paul McKenzie

Make sure you are rebuilding the entire source, and not just a few modules.

Regards,

Paul McKenzie

---

Yes sir, I'm rebuilding the entire source.

Is there a version of valgrind available for the problematic system?

Quote:

---

Originally Posted by BarefootGuy

I don't see why what code precedes or surrounds it should matter.

---

You're obviously new to debugging C / C++.

When you have an error related to malloc / free / new / delete, it's quite possible that its because of something you're doing in a completely different section of code from where your stack trace shows. For example, you could have deleted the same pointer twice somewhere. Now in your next new / malloc call (in a completely different section of code) you'll crash. Or, more accurately, you might crash, or you might not.

The basic issue is that heap corruption can be caused anywhere, but only detected when you try to allocate or release memory (if then).

May be as you say, but as per the code I've pasted, it is the stack memory that is involved, isn't it?

A std::set will use heap memory internally.

If you have valgrind, I'm sure that will pinpoint the problem quickly. Probably an "illegal write of size x" error.

Quote:

---

Originally Posted by Lindley

Is there a version of valgrind available for the problematic system?

---

I think valgrind is only for Linux, not Freebsd. I will try with some tool available for Freebsd in the morning. It is very late now.

Quote:

---

Originally Posted by BarefootGuy

I think valgrind is only for Linux, not Freebsd. I will try with some tool available for Freebsd in the morning. It is very late now.

---

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.

Looks like there is at least a partial port available:
http://www.freebsd.org/cgi/ports.cgi?query=valgrind

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.

Viggy

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?

Quote:

---

Originally Posted by BarefootGuy

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.

Quote:

---

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

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.

Quote:

---

Originally Posted by BarefootGuy

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.

---

Mister Scott Meyers ?

Quote:

---

Originally Posted by BarefootGuy

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

Quote:

---

Originally Posted by BarefootGuy

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'. :rolleyes: (is that what you're telling your manager? 'its an unfixable bug, not even the most experienced could fix it'? lame :thumbd:)

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.

Quote:

---

Originally Posted by Lindley

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.

Quote:

---

Originally Posted by BarefootGuy

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.

Quote:

---

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.

Quote:

---

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.

---

Quote:

---

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.

---

Quote:

---

Originally Posted by BarefootGuy

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

Quote:

---

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.

Regards,

Paul McKenzie

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.