Below is a sample C++ program containing a leak which ::findleaks
doesn't seem to pick up.
The leak happens when a thread is cancelled before joining.
Cancelling stops the stack getting unwound, which in turn stops a C++
destructor getting invoked which would clear up some memory.
It's obviously a bad idea to call pthread_cancel like this, but I
thought I'd raise this example in case you felt this was something that
::findleaks could/should capture.
The sample code below was compiled with flags taken from our normal
build.
uname -a: SunOS devbuild10 5.10 Generic_127111-06 sun4v sparc
SUNW,SPARC-Enterprise-T2000
compiled with: opt/gcc-4.2.3/bin/g++ -pthread -mcpu=v9 -D__sparc_v9=1
-I/opt/gcc-4.2.3/include/c++/4.2.3 pthread_cancel_test.cpp -o
pthread_cancel_test
#include <unistd.h>
#include <pthread.h>
#include <iostream>
#include <memory>
using namespace std;
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
struct Block { char block[1024]; };
struct WithDtor
{
WithDtor(): leakMe(new Block()) { cout << "WithDtor::WithDtor()" <<
endl; }
// following destructor not called
~WithDtor() { cout << "WithDtor::~WithDtor()" << endl; }
// this is not deadbeefed, whilst normally it would clear when the
object is destroyed
auto_ptr<Block> leakMe;
};
void*
threadFun(void*)
{
WithDtor x;
pthread_mutex_lock(&mutex);
pthread_cond_wait(&cond, &mutex);
}
int
main()
{
{
pthread_t thread;
pthread_create(&thread, 0, &threadFun, 0);
pthread_cancel(thread);
void* result = 0;
pthread_join(thread, &result);
}
sleep(60);
return 0;
}
The content of this e-mail is confidential and may be privileged. It may be
read, copied and used only by the intended recipient and may not be disclosed,
copied or distributed. If you received this email in error, please contact the
sender immediately by return e-mail or by telephoning +44 20 7260 2000, delete
it and do not disclose its contents to any person. You should take full
responsibility for checking this email for viruses. Markit reserves the right
to monitor all e-mail communications through its network.
Markit and its affiliated companies make no warranty as to the accuracy or
completeness of any information contained in this message and hereby exclude
any liability of any kind for the information contained herein. Any opinions
expressed in this message are those of the author and do not necessarily
reflect the opinions of Markit.
For full details about Markit, its offerings and legal terms and conditions,
please see Markit's website at http://www.markit.com <http://www.markit.com/> .
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/mdb-discuss/attachments/20080806/6e722a9a/attachment.html>
