Is it possible? Sure. There is no way for the OS to know this, and its your responsibility. Fortunately, it's not really that hard to find the culprit if the deadlock is readily reproducible. Again, I am assuming that this is indeed a deadlock because there is absolutely nothing fishy about the call stack that you printed. It's not sure-fire, but a good way to start would be to use gdb to examine all your other threads, and see which ones are also waiting ona mutex. You'd see essentially the same call sequence.
I think you should just analyze the order of all nested mutex locks, and find any and all cases where some other thread has nested locks where any two locked mutexes occur in reverse order of any other two nested, locked mutexes. If you find a case, then it will eventually deadlock, and you'll have to change your program logic to reverse the order of nested locks. That's the only way to prove to yourself that the code won't ever deadlock.
Aside from that, are you sure that you're not committing something really simple, like the same thread locking the mutex twice? Or forgetting to unlock the mutex in certain paths of execution?
You might even ask yourself if multithreading is really advantageous and worth the additional care it requires in the first place.
To be honest, I don't know if the -g flag actually affects the emitted code. I do know, however, that it's not uncommon to see different behavior with and without the -g flag.
Ajay Bansal writes:
But IS THAT POSSIBLE?? I mean that release mode binaries do not report a
deadlock??
Only difference between two build is of "-g" flag. There is no extra
code written in speacial debug flags (e.g DEBUG or _DEBUG" in MY CODE.
-----Original Message-----
From: Don Dade [mailto:ddade@digitalstatecraft.com] Sent: Friday, March 07, 2003 12:20 AM
To: redhat-devel-list@redhat.com
Subject: Re: pthread_mutex_lock call hangs
Hi Ajay,
This is the normal sequence for LinuxThreads pthread_mutex_lock(). I
would guess that you've got a very subtle bug that is causing a deadlock when
you compile and run with debugging turned on.
I'd go through the code and find all the possible ways in which you
could have nested mutex locks, and see if you find any two sequences that
contain a pair in reversed order. These will be the potential deadlocks. Or, if
it's feasible, could you put a cout around all your locks and unlocks to see
what two mutices are deadlocked?
It sure sounds like a deadlock, not something wrong with the call.
HTH,
Don
Ajay Bansal writes:
may be somebody over here can answer this
-----Original Message-----
From: Ajay Bansal
Sent: Thursday, March 06, 2003 9:36 PM
To: gcc-help@gcc.gnu.org
Subject: pthread_mutex_lock call hangs
Hi All
I am on RH73, gcc 3.2.1
I have a scenario in which, only if the code is in debug mode, pthread_mutex_lock call hangs. following is the trace given by pstack command.
0x420292e5: __sigsuspend + 0x21 (bfffd52c, 20, bfffd52c, 404e3ef5, 10000, 10) + 90
0x404d7679: __pthread_wait_for_restart_signal + 0x59 (404e00a0, 402f6b14, 402ee2c4, 404d945e, 18, 40c4ecc4) + 50
0x404d94b9: __pthread_alt_lock + 0x69 (8100108, 0, 402c2234, 404d60be,
0, 4000b022) + 10
0x404d6116: __pthread_mutex_lock + 0x66 (81000f8, 400, 40ac7bac, 400, 403401ea, 4036e170)
What could be the reason. Please note that the code works great if has
been built in the release mode.
TIA
Ajay Bansal
_______________________________________________
Redhat-devel-list mailing list
Redhat-devel-list@redhat.com
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
_______________________________________________
Redhat-devel-list mailing list
Redhat-devel-list@redhat.com
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
_______________________________________________ Redhat-devel-list mailing list Redhat-devel-list@redhat.com https://listman.redhat.com/mailman/listinfo/redhat-devel-list
