ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
any idea why this sigsuspend is getting called soon after thread tries to write on fd=3. After this call my thread waits for the signal for for ever. I am not sure, which signal it is.
My process is deamon so stdin/stdout/err is closed.
I have compiled dmalloc library with my program and during this run dmalloc is active by setting DMALLOC_OPTIONS env variable.
Looks like I found the problem.
The problem what I think is
1). thread1 is about to lock a mutex but at the same time it got schduled out.
2). thread2 frees the c++ object containing the same mutex. The thread's code gets the same mutex lock before deleting the object.
3). Now when thread1 again gets scheduled, it tries to lock the deleted object's mutex and so it waits for ever since the destructor for the object never unlocks the mutex. However it calls pthread_mutex_destroy () on the mutex.
4). Now since that object is deleted for ever and object is unreferenced so thread2 or anybody else never call unlock for same mutex.
Note: My object's destructor calls pthread_mutex_destroy () on same mutes.
So there are little unexplain things are there but I dont like the idea of triying to aquire a lock on deleted object. I solved this problem by puting mutex out of the object at global level. This solution worked for me now.