crashed in malloc

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi all,
I am experiencing a wierd crash in malloc. There is one call with
malloc(208) and my application crashes in some 'MemPoolSetHighThreads'
funciton which is internally called by malloc.

There does not seem to be any problem with the code surrounding it, and I
dont think that a crash in malloc(208) should be related to the code
surrounding it.
One thing to note here is that the application experienced a crash on a
multiprocessor machine. I just searched through net and found that there
might be memory allocation problems in multiprocessor machines.

Does anyone have any idea about why crash can occur in malloc?
I would appreciate any pointers in this regards.

Thanks in advance,
Tushar.
 
I am experiencing a wierd crash in malloc. There is one call with
malloc(208) and my application crashes in some 'MemPoolSetHighThreads'
funciton which is internally called by malloc.
Click to expand...

Heap corruption is usually the first suspect.
You can try to test the application with PageHeap to see if that's the case:
http://www.debuginfo.com/tips/userbpntdll.html

PageHeap should also be able to detect some synchronization-related bugs.

Regards,
Oleg
[VC++ MVP http://www.debuginfo.com/]
 
Could it be that you are using the single threaded runtime library perhaps?
for multithreading apps you have to use the multithreaded runtime library.

apart from that my best guess is memory corruption due to race conditions or
wrong pointers. that can cause any sort of behavior, including crashes in the
runtime library or nt dlls.

a last thing that comes to mind is that you might be using a lib that uses a
different version of the runtime library than the one you are using (for
example single threaded vs multithreaded) so that you are using
multithreading with a library that was only intended for single threading, or
something like that.

kind regards,
Bruno.
 
Thanks for the reply Oleg.
Unfortunately, my application does not use the Windows heap but uses
SmartHeap.
Would PageHeap.exe help in this case?

Thanks,
Tushar.

Oleg Starodumov said:
I am experiencing a wierd crash in malloc. There is one call with
malloc(208) and my application crashes in some 'MemPoolSetHighThreads'
funciton which is internally called by malloc.
Click to expand...

Heap corruption is usually the first suspect.
You can try to test the application with PageHeap to see if that's the case:
http://www.debuginfo.com/tips/userbpntdll.html

PageHeap should also be able to detect some synchronization-related bugs.

Regards,
Oleg
[VC++ MVP http://www.debuginfo.com/]
Click to expand...
 
Thanks for the reply Bruno.
The application has been build with multithreaded run time libraries and it
has a number of threads running in parallel at any time.
I think the heap corruption due to some pointer assignment is the most
likely cause of the crash, but with a number of threads running, this has
become virtually impossible to find which thread might be causing the memory
corruption and where....:-(

Thanks again,
Tushar.
 
debugging a multithreaded program is tricky indeed.
Here are a few things you can try:

- if things are passed from one thread to the other, check if there can be
race conditions.
- if possible, remove threads one at a time to see which thread triggers the
problem. this only works if your program can somehow run without all the
threads you mentioned.
- remove code from the different threads until the system becomes stable.
then you'll have found at least part of the problem.
- explain the architecture / implementation of your multithreaded program to
someone else. chances are that during the explanation, you'll notice
something fishy.

kind regards,
Bruno.
 
Unfortunately, my application does not use the Windows heap but uses
SmartHeap. Would PageHeap.exe help in this case?
Click to expand...

Most likely it cannot help, unless you can rebuild the application to use
the standard Win32 heap.

If it is not possible, I would second the approach suggested by Bruno.
In addition, if the app's design allows, it might make sense to use defensive locking
(protect large pieces of code with sync. objects until the problem disappears,
then narrow down the scope of synchronization to find the place where
the problem reappears). Often tracing can also help to find race conditions
and other similar problems.

Oleg
 
Back
Top