Segfaults in Malloc() and Malloc_Consolidate()

Segmentation fault in malloc_consolidate (malloc.c) that valgrind doesn't detect

Ok. This is NOT the problem:

I am thinking of a bug in libstdc++

The problem is that you overwrote some memory buffer and corrupted one of the structures used by the memory manager. The hard part is going to be finding it. Does not valgrind give you information about writting past the end of an allocated piece of memory.

Don't do this:

Eventually, I am even considering to replace std::string with simpler char*. Maybe a little drastic, but I wouldn't set it aside.

You already have enough problems with memory management. This will just add more problems. There is absolutely NOTHING wrong with std::string or the memory management routines. They are heavily tested and used. If there was something wrong people all over the world would start screaming (it would be big news).

Reading your code at http://mercurial.intuxication.org/hg/lte_sim/file/c2ef6e0b6d41/src/ it seems like you are still stuck in a C style of writting code (C with Classes). So you have the power of C++ to automate (the blowing up of your code) but still have all the problems associated with C.

You need to re-look at your code in terms of ownership. You pass things around by pointer way too much. As a result it is hard to follow the ownership of the pointer (and thus who is responsible for deleting it).

I think you best bet at finding the bug is to write unit tests for each class. Then run the unit tests through val-grind. I know its a pain (but you should have done it to start with now you have the pain all in one go).

segfault of malloc_consolidate from gethostbyname

If you're crashing within the innards of the malloc-type functions, you've almost certainly corrupted the memory arena.

At some point, you've (for example) allocated 30 bytes then tried to fill it with 60 bytes of data.

You need to track down the root cause of this problem which is, unfortunately, not in the code you've shown. It's far more likely to be in your own code, at some indeterminant point before you call gethostbyname(). Look for anywhere where you allocate heap memory then write to it.

Your "negative" progress is also a good indication of this sort of problem since a trashed arena can cause myriad problems.

signal 11 SIGSEGV in malloc?

Any crash inside malloc (or free) is an almost sure sign of heap corruption, which can come in many forms:

• overflowing or underflowing a heap buffer
• freeing something twice
• freeing a non-heap pointer
• writing to freed block
• etc.

These bugs are very hard to catch without tool support, because the crash often comes many thousands of instructions, and possibly many calls to malloc or free later, in code that is often in a completely different part of the program and very far from where the bug is.

The good news is that tools like Valgrind or AddressSanitizer usually point you straight at the problem.

---

Related Topics