Crash at __tcf_0

Question

In our application, we see a crash after its execution. The stack trace shows that the failure was due to a global variable present in the cpp file. The generated valgrind report shows an incorrect free / read / write error, which means that it is trying to remove memory that is no longer valid.

File: crash.cpp

namespace abc { MutexClass obj; //A is a class // remaining code ChildClass::ChildClass():Parent(obj){} } 

Then we put this variable in an unnamed namespace, and we no longer crash, and valgrind does not report an invalid read / write / error:

File: nocrash.cpp

 namespace { MutexClass obj; } namespace abc { // remaining code ChildClass::ChildClass():Parent(obj){} } 

The above examples are a stripped down version of the class causing the problem.

We are not sure why placing a variable in an unnamed namespace resolves this issue. Does the cleaning order change? We tried to write simple code, but the cleaning order that we observed was the same for both cases.

The Mutex object is passed as a parameter to the constructor of the base class. The only purpose of the Mutex object is to use in the constructor of the base class. The Mutex object is not used anywhere in the code.

Valgrind report for crash

===================================================

Theme 1:

Incorrect reading of size 1

at 0x3A24C08260: pthread_mutex_destroy (at / lib64 / libpthread-2.5.so)

0x5ABE3DD: osl_destroyMutex (libuno_sal.so.3)

by 0xECD69D1: osl :: Mutex :: ~ Mutex () (mutex.hxx: 65)

0xEF207F5: __tcf_0 ( Dispose.cpp: 27 )

on 0x3A24033354: output (in / lib64 / libc-2.5.so)

0x3A2401D97A: (below the main one) (in / lib64 / libc-2.5.so)

The address 0xeb6bb88 is 16 bytes inside a block of size 40 free'd

on 0x4A05B3E: free (vg_replace_malloc.c: 323)

on 0x3A24033354: output (in / lib64 / libc-2.5.so)

0x3A2401D97A: (below the main one) (in / lib64 / libc-2.5.so)

Invalid size 4 record

at 0x3A24C08272: pthread_mutex_destroy (at / lib64 / libpthread-2.5.so)

0x5ABE3DD: osl_destroyMutex (in libuno_sal.so.3)

by 0xECD69D1: osl :: Mutex :: ~ Mutex () (mutex.hxx: 65)

0xEF207F5: __tcf_0 ( Dispose.cpp: 27 )

on 0x3A24033354: output (in / lib64 / libc-2.5.so)

0x3A2401D97A: (below the main one) (in / lib64 / libc-2.5.so)

The address 0xeb6bb88 is 16 bytes inside a block of size 40 free'd

on 0x4A05B3E: free (vg_replace_malloc.c: 323)

on 0x3A24033354: output (in / lib64 / libc-2.5.so)

0x3A2401D97A: (below the main one) (in / lib64 / libc-2.5.so)

Invalid free () / delete / delete []

on 0x4A05B3E: free (vg_replace_malloc.c: 323)

by 0xECD69D1: osl :: Mutex :: ~ Mutex () (mutex.hxx: 65)

0xEF207F5: __tcf_0 ( Dispose.cpp: 27 )

on 0x3A24033354: output (in / lib64 / libc-2.5.so)

0x3A2401D97A: (below the main one) (in / lib64 / libc-2.5.so)

The address 0xeb6bb78 is 0 bytes inside a block of size 40 free'd

on 0x4A05B3E: free (vg_replace_malloc.c: 323)

on 0x3A24033354: output (in / lib64 / libc-2.5.so)

0x3A2401D97A: (below the main one) (in / lib64 / libc-2.5.so)

===================================================

The mutex variable is defined on the Dispose.cpp: 27 line.

We will be grateful for any help on this matter.

Thanks,

Sudeep

Answer 1

Check other files. You probably have another global variable named obj in the abc namespace. Going to an unnamed namespace has the same effect as static in C, which avoids name conflicts (and, if so, any namespace other than abc will also stop the problem). Such an error usually leads to a link error, but sometimes strange things happen.

Note that global variables that will not be used by other files must be in an unnamed namespace to avoid name conflicts.

Answer 2

There is no problem with the code that you showed us.

Perhaps the problem is with class A ?

Answer 3

Is your variable a name with an initial underscore?

If so, then it’s normal that you found trouble.

Global names with an initial underscore are reserved and should not be used. Also names with an initial underscore followed by a capital letter in any context, or names with several adjacent underscores.

This is a rule that, for reasons that I really don’t understand, is often violated by many programmers just for the pleasure of doing it ...

Answer 4

Moving the code, like you, will reorder the construction and destruction of A compared to other globals in the same Translation Unit. If you created A earlier, it will be deleted later. (LIFO principle). Now other objects can count on A Check which objects were previously created before A , and now after A