Vector.clear is creating problem

[maven]

Hi,

I was looking at an old multithreaded program which is creating problem (core dump)!. The debugger tells the problem at vector.clear().

=>[1] __rwstd::__destroy<UCProfileData>(pointer = 0x1142994b8), line 177 in "memory"
  [2] std::allocator_interface<std::allocator<UCProfileData>,UCProfileData>::destroy(this = 0xffffffff7fffad67, p = 0x1142994b8), line 513 in "memory"
  [3] std::vector<UCProfileData,std::allocator<UCProfileData> >::__destroy(this = 0xffffffff7fffb208, start = 0x114299650, finish = 0x114299fe0), line 147 in "vector"
  [4] std::vector<UCProfileData,std::allocator<UCProfileData> >::erase(this = 0xffffffff7fffb208, first = 0x1142979a0, last = 0x114299fe0), line 522 in "vector"
  [5] std::vector<UCProfileData,std::allocator<UCProfileData> >::clear(this = 0xffffffff7fffb208), line 550 in "vector"

while looking more i found somewhere in code by commenting one assignment in vector program works OK. The assignment was in vector through an iterator also which is in a loop.

for (iter= (*it)->my_vector.begin(); iter!= (*it)->my_vector.end(); ++iter)
{
-- some code working on iterator and then
(*iter)->value=1;
}

iter is of same type as it.my_vector

Also, I observed one thing, where the vector.clear is there if i put a print to log then also it works ok.

Please help what is happening wrong here.

[grumpy]

It would help if you provided a small but complete (as in compilable, then linkable, then executable) that illustrates the symptoms. In the process of creating such a sample, you might have an "ah!" moment. Otherwise, your problem will be tractable enough for someone else to help.

All I can offer, based on the insufficient information you have provided, is indications of the nature of the cause;

1) A failure when releasing memory (or destructing objects) - which is what vector.clear() does - usually means a problem in some code executed BEFORE the clear call.

2) The problem in such BEFORE code is either a pointer molestation (writing to an invalid pointer, falling from the end of an array, etc etc) or, in multithreaded code, a failure to synchronise properly (eg a race condition, two threads trying to access the same element of a vector at once, etc etc).

I suggest looking VERY carefully in the code you have marked as "-- some code working on iterator and then". However, the problem is potentially in code which occurs before that.

As to why commenting out code, or adding a "print to log", can eliminate the symptoms, that is typical of such problems. Such things often cause a restructure of how your program uses memory at run time, which means that the invalid operation (whatever it is) corrupts something different. The operating system only detects SOME problems, and restructuring memory usage of your program can prevent the OS detecting the symptom.

[Salem]

> I was looking at an old multithreaded program which is creating problem (core dump)!.
Are you aware that STL isn't thread-safe.

If you've been doing hooky things across multiple threads on the same STL objects, then the problem is going to be somewhere else.

[iMalc]

clear doesn't create the problem, it detects the problem.