Memory Corruption

[Harsha]

Hi All,

There is some memory corruption in my application.
It is due to the fact that it is multithreaded.
Is this due to some missing mutex locking?

Is there any way to find where it is crashing or where the corruption
is occuring?
I have the applications FATAL log. (it's on windows)
I am not familiar with debugging core dumps and also since it is
multithreaded I am not sure how to approach this problem.

Thanks in advance,
Harsha

 

[Flash Gordon]

Hi All,

There is some memory corruption in my application.

Then replace the memory your program is using.

It is due to the fact that it is multithreaded.

Standard C does not support multithreading so that is off topic here.

Is this due to some missing mutex locking?

How can anyone tell without having seen your code? Don't post it here
though, since it is obviously not standard C and so not topical.

Is there any way to find where it is crashing or where the corruption
is occuring?

Well, if it was me where I used to work I might have used in In-Circuit
Emulator or got a HW engineer to hook up a logic analyser.

I have the applications FATAL log. (it's on windows)
I am not familiar with debugging core dumps and also since it is
multithreaded I am not sure how to approach this problem.

Well, since it is on Windows I suggest you try one of the Windows groups
where they actually know how threading on Windows works. However, if you
don't post the code don't expect much help.

 

[Vladimir Oka]

Hi All,

There is some memory corruption in my application.

Sounds like you have a problem.

It is due to the fact that it is multithreaded.

Standard C knows not of threads, so you're unlikely to get help here.

Is this due to some missing mutex locking?

Who knows?

Is there any way to find where it is crashing or where the corruption
is occuring?
Probably.

I have the applications FATAL log. (it's on windows)

Good. That should be a start.

I am not familiar with debugging core dumps and also since it is
multithreaded I am not sure how to approach this problem.

Ask in one of the Windows groups, or one where threads and similar are
topical.

However, when you do, I'd strongly advise you give more details about
the problem, preferrably a minimal compilable example that exhibits the
problem. It is true that Usenet is a place where programming gurus roam
free, but psychics are far and few in between. Crystal balls are also
roumored to be in very short supply these days.

 

[Richard G. Riley]

Hi All,

There is some memory corruption in my application.
It is due to the fact that it is multithreaded.

How do you know this?

Is this due to some missing mutex locking?

No way of knowing from the information you have given.

Is there any way to find where it is crashing or where the corruption
is occuring?

If its in a multithreaded environment it can be tricky. Run it under a
debugger and try to get a call stack when the crash occurs : failing
that get a core dump and learn how to analyse it.

Maybe you can run a profiler to log the calls etc : this might reveal
much to.

I have the applications FATAL log. (it's on windows)
I am not familiar with debugging core dumps and also since it is
multithreaded I am not sure how to approach this problem.

Its a science in itself and off topic in this group. Google up
boundschecker and look to minimise your thread interaction points : if
possible remove all multi threading and then add it back it slowly to
isolate the bug.

Best of luck : you might need it!

 

[websnarf]

There is some memory corruption in my application.
It is due to the fact that it is multithreaded.

This is a common problem.

Is this due to some missing mutex locking?

Anything is possible, without seeing the code its impossible to tell --
but for multithreaded applications its still commonly a very hard
problem even if you do have source.

Is there any way to find where it is crashing or where the corruption
is occuring?

Yeah, with careful debugging in a very Sherlock Holmes style. More
seriously though, if you have a good enough debugger you should set
watch points on your corruption if its deterministic. If its not
deterministic, you have a harder problem on your hands -- but you can
instrument your code with self-integrity checks which can serve the
required purpose. This is most helpful if you have mechanisms for
classifying raw pointers. Its kind of messy to implement but well
worth it and quite doable on most platforms.