Thread: exit() call pthread_mutex_lock()

hi all,
i my C program when i call exit() it calls pthread_mutex_lock() without any reason.
thus send the prcess in deadlock....
for the backtrace:
c - exit() call pthread_mutex_lock() - Stack Overflow

thanks in advance.

Originally Posted by grumpy

The most likely explanation is that some (apparently unrelated) function in your code (or in the "network checker" code you refer to) has molested a pointer

Ad you can see in the source code, the network check is never spawned if there isn't valid options.
So...alla the code beign executed is in Main & option_handler...where i cannot find anything that can write on bad pointers or something like.
Do you see anything bad in these 2 functions??

Also, you call destroy_all() in autocrack.c, on line 301, right before you call exit. That function messes with threads, mutexes, linked lists and god knows what else. I think it's a likely candidate for trashing memory. Try commenting it out and simply calling exit to see if the immediate problem goes away. Then at least you can start narrowing it down.

If you can create something this complex, you should really start getting intimate with gdb if you haven't yet.

If you can create something this complex, you should really start getting intimate with gdb if you haven't yet.

valgrind too

Originally Posted by Salem

Here you can see in the mutex object itself is a field indicating which thread currently owns the mutex. When you know this, you can either locate a thread which has already exited (as in this case), or a still living thread which still has the lock. Either way, you'll know the locking thread and should be closer to figuring out WHY it still has the lock.

sorry for the late reply but i just give an exam and i have another on 18/09...
so, i'm quite familiar with GDB and valgrind but i cannot analyze the locked mutex since i don't known what it is.
i've tried to analyze local variables and arguments of the frame which call pthread_mutex_lock, but i cannot find anything, neither an address....
and valgrind freeze when the deadlock occurs.

Originally Posted by anduril462

Also, you call destroy_all() in autocrack.c, on line 301, right before you call exit. That function messes with threads, mutexes, linked lists and god knows what else. I think it's a likely candidate for trashing memory. Try commenting it out and simply calling exit to see if the immediate problem goes away. Then at least you can start narrowing it down.

If you can create something this complex, you should really start getting intimate with gdb if you haven't yet.

i will try in this evening, really, sorry for the late reply.

anyway thanks to all for the replies, i asked to many mailinglists and they simply tell me to use return or the _exit() function... i wanna known WHY this "bug" happen, not a workaround!

PS:
sorry for my doggish english! lol

so, changing these lines

Code:

            if(option_index < NET_CHK_TIMEOUT)
            {
                report(debug,"I've wait internet check for %d ms.",option_index);
                pthread_join(globals.tpool->thread, (void **) &option_index);
            }
            else
                option_index = ETIMEDOUT;

to

Code:

            pthread_join(globals.tpool->thread, (void **) &option_index);
            if(option_index < NET_CHK_TIMEOUT)
                report(debug,"I've wait internet check for %d ms.",option_index);
            else
                option_index = ETIMEDOUT;

in autocrack.c reduces tens of times the reproducibility of the bug.

i will try to remake the same network state as the first time the bug is appear ( router connected to modem but modem not connected to ADSL signal ) since the back trace is changed:

Code:

Program received signal SIGINT, Interrupt.
0x00007ffff6e6b3ae in __lll_lock_wait_private () from /lib64/libc.so.6
(gdb) bt
#0  0x00007ffff6e6b3ae in __lll_lock_wait_private () from /lib64/libc.so.6
#1  0x00007ffff6e012bf in _L_lock_6442 () from /lib64/libc.so.6
#2  0x00007ffff6dff6d1 in free () from /lib64/libc.so.6
#3  0x0000000000413e8f in option_handler (argc=2, argv=0x7fffffffdba8) at autocrack.c:289
#4  0x00000000004135a7 in main (argc=2, argv=0x7fffffffdba8) at autocrack.c:34
(gdb) i thr
  Id   Target Id         Frame 
* 1    Thread 0x7ffff7fc9700 (LWP 5525) "autocrack" 0x00007ffff6e6b3ae in __lll_lock_wait_private () from /lib64/libc.so.6
(gdb) up
#1  0x00007ffff6e012bf in _L_lock_6442 () from /lib64/libc.so.6
(gdb) i locals
No symbol table info available.
(gdb) i args
No symbol table info available.
(gdb) up
#2  0x00007ffff6dff6d1 in free () from /lib64/libc.so.6
(gdb) i args
No symbol table info available.
(gdb) i locals
No symbol table info available.
(gdb) x/dw &pool_lock.__data.__owner
0x61c2a8 <pool_lock+8>: 0
(gdb) x/dw &pool_lock.__data.__lock 
0x61c2a0 <pool_lock>:   0
(gdb) x/xw &globals.hash_list
0x61c278 <globals+120>: 0x00000000
(gdb) x/xw &globals.wpa_list
0x61c268 <globals+104>: 0x00000000
(gdb) x/xw &globals.tpool->lock.__data.__owner
0x61e0d8:       0x00000000
(gdb) x/xw &globals.tpool->lock.__data.__lock 
0x61e0d0:       0x00000000
(gdb) x/xw &globals.tpool->next                    
0x61e0f8:       0x00000000

the only pthread_mutex_t in this program are "pool_lock" as global variable, "lock" in the "_hash" struct and "lock" inside the "t_info" struct.
as you can see in the GDB session mutex hasn't owners, hash_list is empty end the mutex of the only item of the thread pool isn't locked.
as you can see in line 130:

Code:

globals.tpool = malloc(sizeof(struct t_info));

tpool is set by malloc, which ( thanks to macros ) is replaced with a mine function that set all bytes to '0'. so also the mutex is initialized, right?!

I will update you this afternoon.