Strange qsrand error when debugging with totalview/memoryscape

I hope there is someone using TotalView/MemoryScape here.

I use this tool for about 5 years now (from before the time they split it into two products). I mainly used for memory leak detection - IMO about 1000x better than gdb, click, catch. It was it until now (while I debugged only STL based stuff). Now I have it running on CentOS 6 32bit.

The application I originally tried to debug is a complex multithreaded beast (I have about 200 bytes leak per thread and that adds up to lots of bytes finally). To my surprise, it fails at the first step with the qsrand call.

It says: "Error: Allocator returned a misaligned block: heap may be corrupted".

No matter what I do, the application does not continue. I hope there is someone out there using TotalView who can tell me what is going on since rougewave support does not give a hand with qt.

Alternatively, I would welcome any tool what does the same memleak detection as TV does (valgrind output is a nightmare, something nice is needed what is capable to output results in an easily comprehensible format after creating and destroying 100000 threads or so).

not really a Qt programming question, is it?

Quote:

---

Originally Posted by amleto

not really a Qt programming question, is it?

---

Moved to General Programming.

Greetings Sandor,

I'm the product manager for TotalView and MemoryScape. Google brought this post to my attention.

Just a clarifying nit. We do now sell MemoryScape separately, but we also include it in the vast majority of configurations of TotalView -- so most people who have TotalView are able to use MemoryScape in the way you are describing, even with the latest versions.

First, did you try asking your question to our support folks or on the rouge wave forum? I don't see it in either system?

In any case I can probably help you with your issue.

What TotalView/MemoryScape is telling you with that message is that a malloc or realloc call returned a non-aligned address which is usually a bad sign. I'd focus my diagnostic efforts in two areas:

1. see if you can pin down exactly what call that might have been and double check that you are seeing that non-aligned return value.

2. see if you can figure out under what conditions this is happening.

A couple of things you should look at.

1. The stack backtrace. This diagnostic would generally be returned and the target stopped in the process of an alloc() or malloc() call. Do you see this on the backtrace?

2. Is this the first allocation in the program or the 99999th? You might be able to tell this by looking at the heap map (if there are already allocations there this this isn't the first) or by putting a breakpoint around malloc (or realloc, or whichever call you are using).

3. Does this happen with a really simple program. Make a test rig program that calls qsrand(). Does it work?

You mention that your program is multi-threaded. This kind of heap corruption often indicates that one of the threads is writing into part of the memory where it should not be writing. Some possible causes:

A. Writing past the end of an array
B. A race condition occurs and the program gets confused and starts doing crazy things
C. A pointer is shared between threads and copied around. Thread A determines that it is done with the object and calls free() (or deletes the object). Thread B still has a copy of the pointer and tries to access it. *Blam* bad data gets written over libc's own data structures.
D. A "plain old" wild pointer. This can happen when you read/write uninitialized data.

4. Can you tell your multi-threaded program to run single threaded (for testing purposes)? If so does this problem go away?

Let me know if this helps.

Cheers,
Chris

Sandor,

Another thought, from one of my colleagues here:

"You can go into the advanced options and turn off the reporting of that particular
error. Sometimes they are real, but don't affect the running of the program.
That might get him past the beginning and allow him to get to the problem with
his leaks."

Cheers,
Chris