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.