Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #90673 > unrolled thread

[C/POSIX] pthread_exit()

Back to article view | Back to comp.lang.c

Contents

  [C/POSIX] pthread_exit() JKB <jkb@koenigsberg.invalid> - 2016-07-20 16:47 +0000
    Re: [C/POSIX] pthread_exit() "James R. Kuyper" <jameskuyper@verizon.net> - 2016-07-20 13:42 -0400
      Re: [C/POSIX] pthread_exit() Keith Thompson <kst-u@mib.org> - 2016-07-20 11:33 -0700
      Re: [C/POSIX] pthread_exit() JKB <jkb@koenigsberg.invalid> - 2016-07-21 10:10 +0000
      Re: [C/POSIX] pthread_exit() Randy Howard <rhoward.mx@EverybodyUsesIt.com> - 2016-07-22 08:10 -0500
        Re: [C/POSIX] pthread_exit() JKB <jkb@koenigsberg.invalid> - 2016-07-22 13:42 +0000
          Re: [C/POSIX] pthread_exit() Randy Howard <rhoward.mx@EverybodyUsesIt.com> - 2016-07-22 09:44 -0500
            Re: [C/POSIX] pthread_exit() JKB <jkb@koenigsberg.invalid> - 2016-07-22 14:48 +0000
        Re: [C/POSIX] pthread_exit() Richard Heathfield <rjh@cpax.org.uk> - 2016-07-22 14:52 +0100
        Re: [C/POSIX] pthread_exit() supercat@casperkitty.com - 2016-07-22 08:51 -0700
        Re: [C/POSIX] pthread_exit() James Kuyper <jameskuyper@verizon.net> - 2016-07-22 13:26 -0400
        Re: [C/POSIX] pthread_exit() Keith Thompson <kst-u@mib.org> - 2016-07-22 10:28 -0700
          Re: [C/POSIX] pthread_exit() Ian Collins <ian-news@hotmail.com> - 2016-07-23 16:12 +1200
          Re: [C/POSIX] pthread_exit() Randy Howard <rhoward.mx@EverybodyUsesIt.com> - 2016-07-23 16:43 -0500
            Re: [C/POSIX] pthread_exit() "James R. Kuyper" <jameskuyper@verizon.net> - 2016-07-23 18:17 -0400
              Re: [C/POSIX] pthread_exit() Keith Thompson <kst-u@mib.org> - 2016-07-23 20:45 -0700
              Re: [C/POSIX] pthread_exit() James Kuyper <jameskuyper@verizon.net> - 2016-07-24 07:27 -0400
                Re: [C/POSIX] pthread_exit() Randy Howard <rhoward.mx@EverybodyUsesIt.com> - 2016-07-25 15:22 -0500
                  Re: [C/POSIX] pthread_exit() Ian Collins <ian-news@hotmail.com> - 2016-07-26 08:26 +1200
                  Re: [C/POSIX] pthread_exit() "James R. Kuyper" <jameskuyper@verizon.net> - 2016-07-25 16:32 -0400
                    Re: [C/POSIX] pthread_exit() Randy Howard <rhoward.mx@EverybodyUsesIt.com> - 2016-07-25 15:52 -0500
                      Re: [C/POSIX] pthread_exit() "James R. Kuyper" <jameskuyper@verizon.net> - 2016-07-25 16:59 -0400
                        Re: [C/POSIX] pthread_exit() Randy Howard <rhoward.mx@EverybodyUsesIt.com> - 2016-07-25 16:36 -0500
    Re: [C/POSIX] pthread_exit() Johann Klammer <klammerj@NOSPAM.a1.net> - 2016-07-21 11:54 +0200
      Re: [C/POSIX] pthread_exit() JKB <jkb@koenigsberg.invalid> - 2016-07-22 08:17 +0000
        Re: [C/POSIX] pthread_exit() JKB <jkb@koenigsberg.invalid> - 2016-07-22 08:47 +0000
    Re: [C/POSIX] pthread_exit() Melzzzzz <mel@zzzzz.com> - 2016-07-23 00:52 +0200
      Re: [C/POSIX] pthread_exit() JKB <jkb@koenigsberg.invalid> - 2016-07-25 11:43 +0000
        Re: [C/POSIX] pthread_exit() Melzzzzz <mel@zzzzz.com> - 2016-07-25 13:47 +0200
          Re: [C/POSIX] pthread_exit() JKB <jkb@koenigsberg.invalid> - 2016-07-25 11:58 +0000
            Re: [C/POSIX] pthread_exit() Melzzzzz <mel@zzzzz.com> - 2016-07-25 14:00 +0200
              Re: [C/POSIX] pthread_exit() JKB <jkb@koenigsberg.invalid> - 2016-07-25 12:18 +0000
                Re: [C/POSIX] pthread_exit() Melzzzzz <mel@zzzzz.com> - 2016-07-25 14:20 +0200
                  Re: [C/POSIX] pthread_exit() JKB <jkb@koenigsberg.invalid> - 2016-07-25 12:26 +0000
                    Re: [C/POSIX] pthread_exit() Melzzzzz <mel@zzzzz.com> - 2016-07-25 14:28 +0200
                      Re: [C/POSIX] pthread_exit() JKB <jkb@koenigsberg.invalid> - 2016-07-25 12:35 +0000
                        Re: [C/POSIX] pthread_exit() JKB <jkb@koenigsberg.invalid> - 2016-07-25 13:44 +0000

Page 2 of 2 — ← Prev page 1 [2]

#91056

On 7/25/16 3:32 PM, James R. Kuyper wrote:
> On 07/25/2016 04:22 PM, Randy Howard wrote:
> ....
>> Indeed.  Meanwhile, pthread support is available on Windows,
>
> I asked you a question about POSIX and Windows on 2016-07-23, which you
> never answered. The above comment reinforces my suspicion that you
> should be able to answer it. Can you?


I've somehow missed it, apparently.


-- 
Randy Howard
(replace the obvious text in the obvious way if you wish to contact me 
directly)

[toc] | [prev] | [next] | [standalone]

#91058

On 07/25/2016 04:52 PM, Randy Howard wrote:
> On 7/25/16 3:32 PM, James R. Kuyper wrote:
>> On 07/25/2016 04:22 PM, Randy Howard wrote:
>> ....
>>> Indeed.  Meanwhile, pthread support is available on Windows,
>>
>> I asked you a question about POSIX and Windows on 2016-07-23, which you
>> never answered. The above comment reinforces my suspicion that you
>> should be able to answer it. Can you?
>
>
> I've somehow missed it, apparently.

I can repeat it:

The last time I heard expert opinion on the matter, I was told that 
there is a POSIX subsystem for Windows, which implements many (but not 
all) of the features required to conform fully to POSIX, and that use of 
this sub-system is incompatible with full use of all Win32 features. 
Other people claimed that those experts were talking nonsense, with the 
implication that there is an implementation of pthreads that both fully 
conforms to POSIX and is fully compatible with all features of Win32 - 
except, they never actually said so, they just implied it, and never 
answered detailed questions about those implications.

I investigated as far as could on my own, which wasn't very far, since I 
am not a Windows expert, nor do I have any Windows machine I could test 
things on. I found a Microsoft web site which listed dozens of pthreads 
functions that it freely admitted were both required by POSIX, and not 
implemented in the POSIX subsystem for Windows, which would favor the 
statements of the first group I mentioned. However, I couldn't find any 
clear statements on the Microsoft web site about the simultaneous use of 
the POSIX subsystem and Win32. That's not because my searches didn't 
turn up anything - it was  because my searches turned up too much 
information, and I couldn't sift through it to find the particular 
information I was looking for.

You sound like someone familiar with the relevant issues, can you 
discuss them?

[toc] | [prev] | [next] | [standalone]

#91061

On 7/25/16 3:59 PM, James R. Kuyper wrote:
> On 07/25/2016 04:52 PM, Randy Howard wrote:
>> On 7/25/16 3:32 PM, James R. Kuyper wrote:
>>> On 07/25/2016 04:22 PM, Randy Howard wrote:
>>> ....
>>>> Indeed.  Meanwhile, pthread support is available on Windows,
>>>
>>> I asked you a question about POSIX and Windows on 2016-07-23, which you
>>> never answered. The above comment reinforces my suspicion that you
>>> should be able to answer it. Can you?
>>
>>
>> I've somehow missed it, apparently.
>
> I can repeat it:
>
> The last time I heard expert opinion on the matter, I was told that
> there is a POSIX subsystem for Windows, which implements many (but not
> all) of the features required to conform fully to POSIX, and that use of
> this sub-system is incompatible with full use of all Win32 features.
> Other people claimed that those experts were talking nonsense, with the
> implication that there is an implementation of pthreads that both fully
> conforms to POSIX and is fully compatible with all features of Win32 -
> except, they never actually said so, they just implied it, and never
> answered detailed questions about those implications.

There is some support for a lot of POSIX functions under Windows, even
if you do not include pthreads under that umbrella. Some of them behave
exactly like you would expect elsewhere, others are 'sort of' like what
you would expect, so in that sense, NOT fully compatible. This is in
the context of things supported by Microsoft themselves on the platform.

Pthreads support that I made use of was done externally, originally
called pthreads-win32, although that was later made to work on win64 as
well and possibly renamed? In general, the bolt-on at the time was 
pretty straightforward.

I haven't used recent versions of the windows pthreads support, as I no
longer can be bribed with enough money to make me work on Windows ever
again.

However, when I was using it, modulo a few bugs that were resolved, I
didn't have any serious difficulty porting pthreads code that ran on
half a dozen other platforms to Windows. The pthreads for windows
project has (or at least had) a fairly active mailing list that helped
get things sorted out pretty quickly.

Getting other things to work portably was more difficult, although I
did learn a fair bit about hiding Windows specific uniqueness issues
(like winsock vs. sockets) behind veneer layers so most of the
mainline code didn't have to be touched at all to run on Windows as well 
as the systems it already supported. At the time, I had to support
Linux, OS X, a number of UNIX platforms, Netware and Windows for a suite 
of programs that all used pthreads rather heavily. Getting
pthreads to work on Windows was one of the simpler parts of the
windows port, thanks to the pthreads-win32 effort.

In general, apart from GUI issues, which are always painful to port
(and please, nobody try and make a case for QT here), you have the
same sort of issues in porting to windows regardless of the APIs
you use outside of libc. You end up doing some sort of compile time
platform detection and 'munging' to make Windows bend to your will.
Once you figure that out, it's not as horrible as you think.

> I investigated as far as could on my own, which wasn't very far, since I
> am not a Windows expert, nor do I have any Windows machine I could test
> things on. I found a Microsoft web site which listed dozens of pthreads
> functions that it freely admitted were both required by POSIX, and not
> implemented in the POSIX subsystem for Windows, which would favor the
> statements of the first group I mentioned. However, I couldn't find any
> clear statements on the Microsoft web site about the simultaneous use of
> the POSIX subsystem and Win32. That's not because my searches didn't
> turn up anything - it was  because my searches turned up too much
> information, and I couldn't sift through it to find the particular
> information I was looking for.

If you are interested only in Windows *native* support for pthreads, I
think you will be disappointed, unless they have made significant
changes in recent years. At the time I was still worried about pthreads
on Windows, I was using only externally developed support. I have no
useful information to contribute about Microsoft's direct support for
them, if it exists.

I hope that's at least somewhat helpful, I'm afraid my experience is
rapidly becoming dated.


-- 
Randy Howard
(replace the obvious text in the obvious way if you wish to contact me 
directly)

[toc] | [prev] | [next] | [standalone]

#90715

On 07/20/2016 06:47 PM, JKB wrote:
> 	Hello,
> 
> 	I'm debugging a huge program that can enter in deadlock on a
> 	pthread_exit() syscall. I use gcc compiler on Linux or NetBSD.
> 
> 	Before writing here, I have tried to debug this program with
> 	valgrind and helgrind without any success. I have tried Purify also.
> 
> 	Original program is available at :
> 	http://www.rpl2.net/telechargements.php -> snapshot
> 
> 	With following test program :
> 
> #!/usr/local/bin/rpl -spd
> TEST
> <<
> 	0 -> I
> 	<< do 'TEST2' detach wfproc 'I' incr I disp until false end >>
>>>
> 
> TEST2
> <<
>>>
> 
> 	rpl enters in deadlock after a random number of cycles in do/until
> 	loop. I have checked all memory access and I haven't found any memory
> 	corruption. For example, last time I have launched my test program,
> 	execution stops with :
> 
> ...
> 1090390
> 1090391
> 1090392
> 1090393
> 1090394
> 1090395
> 1090396
> 1090397
> 
> 	With gdb, I can obtain a backtrace of faulty thread :
> 
> (gdb) bt
> #0  __lll_lock_wait () at
> ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
> #1  0x00007f9ebbb0bb92 in __GI___pthread_mutex_lock (
>     mutex=0x7f9ebc674970 <_rtld_global+2352>)
>     at ../nptl/pthread_mutex_lock.c:116
> #2  0x00007f9ebb1fdbaf in __GI___dl_iterate_phdr
> 	(callback=0x7f9ebaedae40, 
>     data=0x7f9eb9c878b0) at dl-iteratephdr.c:41
> #3  0x00007f9ebaedc1be in _Unwind_Find_FDE ()
>     from /lib/x86_64-linux-gnu/libgcc_s.so.1
> #4  0x00007f9ebaed8bb3 in ?? () from
>     /lib/x86_64-linux-gnu/libgcc_s.so.1
> #5  0x00007f9ebaed9dd0 in ?? () from
>     /lib/x86_64-linux-gnu/libgcc_s.so.1
> #6  0x00007f9ebaeda3d6 in _Unwind_ForcedUnwind ()
>     from /lib/x86_64-linux-gnu/libgcc_s.so.1
> #7  0x00007f9ebbb11ae0 in __GI___pthread_unwind
>     (buf=<optimized out>) at unwind.c:126
> #8  0x00007f9ebbb0a5a5 in __do_cancel () at pthreadP.h:283
> #9  __pthread_exit (value=value@entry=0x0) at pthread_exit.c:28
> ...
> 
> 	Each time, one of the pthread_exit() syscall in src/interruptions.c
> 	enter in deadlock. I have tried to relink my program with -Wl,-z,now
> 	as I have seen some very similar issue on internet, but it doesn't
> 	fix my trouble.
> 	
> 	How can I debug this mistake ?
> 
> 	Regards,
> 
> 	JB
> 

It waits for an internal mutex. 
You'll have to check the other threads for locks..
I think the gdb commands were:

`info threads'
and
`thread <n>'
to switch betw them.

use backtrace as before and perhaps you'll find it.
Also check that the thread structure has not been destroyed early, 
if the pthread_t itself sits in a malloced block.

[toc] | [prev] | [next] | [standalone]

#90756

Le Thu, 21 Jul 2016 11:54:19 +0200,
Johann Klammer <klammerj@NOSPAM.a1.net> écrivait :
> On 07/20/2016 06:47 PM, JKB wrote:
>> 	Hello,
>> 
>> 	I'm debugging a huge program that can enter in deadlock on a
>> 	pthread_exit() syscall. I use gcc compiler on Linux or NetBSD.
>> 
>> 	Before writing here, I have tried to debug this program with
>> 	valgrind and helgrind without any success. I have tried Purify also.
>> 
>> 	Original program is available at :
>> 	http://www.rpl2.net/telechargements.php -> snapshot
>> 
>> 	With following test program :
>> 
>> #!/usr/local/bin/rpl -spd
>> TEST
>> <<
>> 	0 -> I
>> 	<< do 'TEST2' detach wfproc 'I' incr I disp until false end >>
>>>>
>> 
>> TEST2
>> <<
>>>>
>> 
>> 	rpl enters in deadlock after a random number of cycles in do/until
>> 	loop. I have checked all memory access and I haven't found any memory
>> 	corruption. For example, last time I have launched my test program,
>> 	execution stops with :
>> 
>> ...
>> 1090390
>> 1090391
>> 1090392
>> 1090393
>> 1090394
>> 1090395
>> 1090396
>> 1090397
>> 
>> 	With gdb, I can obtain a backtrace of faulty thread :
>> 
>> (gdb) bt
>> #0  __lll_lock_wait () at
>> ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
>> #1  0x00007f9ebbb0bb92 in __GI___pthread_mutex_lock (
>>     mutex=0x7f9ebc674970 <_rtld_global+2352>)
>>     at ../nptl/pthread_mutex_lock.c:116
>> #2  0x00007f9ebb1fdbaf in __GI___dl_iterate_phdr
>> 	(callback=0x7f9ebaedae40, 
>>     data=0x7f9eb9c878b0) at dl-iteratephdr.c:41
>> #3  0x00007f9ebaedc1be in _Unwind_Find_FDE ()
>>     from /lib/x86_64-linux-gnu/libgcc_s.so.1
>> #4  0x00007f9ebaed8bb3 in ?? () from
>>     /lib/x86_64-linux-gnu/libgcc_s.so.1
>> #5  0x00007f9ebaed9dd0 in ?? () from
>>     /lib/x86_64-linux-gnu/libgcc_s.so.1
>> #6  0x00007f9ebaeda3d6 in _Unwind_ForcedUnwind ()
>>     from /lib/x86_64-linux-gnu/libgcc_s.so.1
>> #7  0x00007f9ebbb11ae0 in __GI___pthread_unwind
>>     (buf=<optimized out>) at unwind.c:126
>> #8  0x00007f9ebbb0a5a5 in __do_cancel () at pthreadP.h:283
>> #9  __pthread_exit (value=value@entry=0x0) at pthread_exit.c:28
>> ...
>> 
>> 	Each time, one of the pthread_exit() syscall in src/interruptions.c
>> 	enter in deadlock. I have tried to relink my program with -Wl,-z,now
>> 	as I have seen some very similar issue on internet, but it doesn't
>> 	fix my trouble.
>> 	
>> 	How can I debug this mistake ?
>> 
>> 	Regards,
>> 
>> 	JB
>> 
>
> It waits for an internal mutex. 
> You'll have to check the other threads for locks..
> I think the gdb commands were:
>
> `info threads'
> and
> `thread <n>'
> to switch betw them.
>
> use backtrace as before and perhaps you'll find it.
> Also check that the thread structure has not been destroyed early, 
> if the pthread_t itself sits in a malloced block.

	Of course, I have checked that I haven't allocation issue.
	My pthread_t struct is in a mmaped memory I unmap after
	pthread_join(). But I wonder if I can allocate pthread_t in a mmapped
	object.

	Regards,

	JKB

-- 
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr

[toc] | [prev] | [next] | [standalone]

#90759

Le Fri, 22 Jul 2016 08:17:00 +0000 (UTC),
JKB <jkb@koenigsberg.invalid> écrivait :
> Le Thu, 21 Jul 2016 11:54:19 +0200,
> Johann Klammer <klammerj@NOSPAM.a1.net> écrivait :
>> On 07/20/2016 06:47 PM, JKB wrote:
>>> 	Hello,
>>> 
>>> 	I'm debugging a huge program that can enter in deadlock on a
>>> 	pthread_exit() syscall. I use gcc compiler on Linux or NetBSD.
>>> 
>>> 	Before writing here, I have tried to debug this program with
>>> 	valgrind and helgrind without any success. I have tried Purify also.
>>> 
>>> 	Original program is available at :
>>> 	http://www.rpl2.net/telechargements.php -> snapshot
>>> 
>>> 	With following test program :
>>> 
>>> #!/usr/local/bin/rpl -spd
>>> TEST
>>> <<
>>> 	0 -> I
>>> 	<< do 'TEST2' detach wfproc 'I' incr I disp until false end >>
>>>>>
>>> 
>>> TEST2
>>> <<
>>>>>
>>> 
>>> 	rpl enters in deadlock after a random number of cycles in do/until
>>> 	loop. I have checked all memory access and I haven't found any memory
>>> 	corruption. For example, last time I have launched my test program,
>>> 	execution stops with :
>>> 
>>> ...
>>> 1090390
>>> 1090391
>>> 1090392
>>> 1090393
>>> 1090394
>>> 1090395
>>> 1090396
>>> 1090397
>>> 
>>> 	With gdb, I can obtain a backtrace of faulty thread :
>>> 
>>> (gdb) bt
>>> #0  __lll_lock_wait () at
>>> ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
>>> #1  0x00007f9ebbb0bb92 in __GI___pthread_mutex_lock (
>>>     mutex=0x7f9ebc674970 <_rtld_global+2352>)
>>>     at ../nptl/pthread_mutex_lock.c:116
>>> #2  0x00007f9ebb1fdbaf in __GI___dl_iterate_phdr
>>> 	(callback=0x7f9ebaedae40, 
>>>     data=0x7f9eb9c878b0) at dl-iteratephdr.c:41
>>> #3  0x00007f9ebaedc1be in _Unwind_Find_FDE ()
>>>     from /lib/x86_64-linux-gnu/libgcc_s.so.1
>>> #4  0x00007f9ebaed8bb3 in ?? () from
>>>     /lib/x86_64-linux-gnu/libgcc_s.so.1
>>> #5  0x00007f9ebaed9dd0 in ?? () from
>>>     /lib/x86_64-linux-gnu/libgcc_s.so.1
>>> #6  0x00007f9ebaeda3d6 in _Unwind_ForcedUnwind ()
>>>     from /lib/x86_64-linux-gnu/libgcc_s.so.1
>>> #7  0x00007f9ebbb11ae0 in __GI___pthread_unwind
>>>     (buf=<optimized out>) at unwind.c:126
>>> #8  0x00007f9ebbb0a5a5 in __do_cancel () at pthreadP.h:283
>>> #9  __pthread_exit (value=value@entry=0x0) at pthread_exit.c:28
>>> ...
>>> 
>>> 	Each time, one of the pthread_exit() syscall in src/interruptions.c
>>> 	enter in deadlock. I have tried to relink my program with -Wl,-z,now
>>> 	as I have seen some very similar issue on internet, but it doesn't
>>> 	fix my trouble.
>>> 	
>>> 	How can I debug this mistake ?
>>> 
>>> 	Regards,
>>> 
>>> 	JB
>>> 
>>
>> It waits for an internal mutex. 
>> You'll have to check the other threads for locks..
>> I think the gdb commands were:
>>
>> `info threads'
>> and
>> `thread <n>'
>> to switch betw them.
>>
>> use backtrace as before and perhaps you'll find it.
>> Also check that the thread structure has not been destroyed early, 
>> if the pthread_t itself sits in a malloced block.
>
> 	Of course, I have checked that I haven't allocation issue.
> 	My pthread_t struct is in a mmaped memory I unmap after
> 	pthread_join(). But I wonder if I can allocate pthread_t in a mmapped
> 	object.

	I have checked I only try to access to pthread_t from pid that has
	created faulty thread. Thus, even if pthread_t contains some
	pointers, data always remain accessible. To validate, I have replaced
	mmaped object by global variable and I obtain the same random deadlock
	in pthread_join().

	JKB

-- 
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr

[toc] | [prev] | [next] | [standalone]

#90826

On Wed, 20 Jul 2016 16:47:01 +0000 (UTC)
JKB <jkb@koenigsberg.invalid> wrote:

> 	Hello,
> 
> 	I'm debugging a huge program that can enter in deadlock on a
> 	pthread_exit() syscall. I use gcc compiler on Linux or NetBSD.

Do you observe same behavior on both systems?

[toc] | [prev] | [next] | [standalone]

#90966

Le Sat, 23 Jul 2016 00:52:17 +0200,
Melzzzzz <mel@zzzzz.com> écrivait :
> On Wed, 20 Jul 2016 16:47:01 +0000 (UTC)
> JKB <jkb@koenigsberg.invalid> wrote:
>
>> 	Hello,
>> 
>> 	I'm debugging a huge program that can enter in deadlock on a
>> 	pthread_exit() syscall. I use gcc compiler on Linux or NetBSD.
>
> Do you observe same behavior on both systems?

	Not exactly. On Linux side, pthread_exit() enters in a deadlock. On
	NetBSD side, I don't know. Execution stops, but when I try to attach
	gdb on faulty process, it abots with sigtrap if I remember.

	I'm sure there is an issue in my code, and I'm not sure that it is
	pthread related. pthread_exit() only triggers the bug. It's not a
	memory corruption, maybe a race condition, but I have looked for
	this condition with a piece of paper without any result.

	Best regards,

	JKB

-- 
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr

[toc] | [prev] | [next] | [standalone]

#90967

On Mon, 25 Jul 2016 11:43:57 +0000 (UTC)
JKB <jkb@koenigsberg.invalid> wrote:

> Le Sat, 23 Jul 2016 00:52:17 +0200,
> Melzzzzz <mel@zzzzz.com> écrivait :
> > On Wed, 20 Jul 2016 16:47:01 +0000 (UTC)
> > JKB <jkb@koenigsberg.invalid> wrote:
> >  
> >> 	Hello,
> >> 
> >> 	I'm debugging a huge program that can enter in deadlock on
> >> a pthread_exit() syscall. I use gcc compiler on Linux or NetBSD.  
> >
> > Do you observe same behavior on both systems?  
> 
> 	Not exactly. On Linux side, pthread_exit() enters in a
> deadlock. On NetBSD side, I don't know. Execution stops, but when I
> try to attach gdb on faulty process, it abots with sigtrap if I
> remember.
> 
> 	I'm sure there is an issue in my code, and I'm not sure that
> it is pthread related. pthread_exit() only triggers the bug. It's not
> a memory corruption, maybe a race condition, but I have looked for
> 	this condition with a piece of paper without any result.
> 
> 	Best regards,
> 
> 	JKB
> 

If pthread_exit enters deadlock that means either something holds lock
or mutex memory is corrupted. NetBSD case shows that probably memory is
corrupted rather deadlock...

[toc] | [prev] | [next] | [standalone]

#90968

Le Mon, 25 Jul 2016 13:47:25 +0200,
Melzzzzz <mel@zzzzz.com> écrivait :
> On Mon, 25 Jul 2016 11:43:57 +0000 (UTC)
> JKB <jkb@koenigsberg.invalid> wrote:
>
>> Le Sat, 23 Jul 2016 00:52:17 +0200,
>> Melzzzzz <mel@zzzzz.com> écrivait :
>> > On Wed, 20 Jul 2016 16:47:01 +0000 (UTC)
>> > JKB <jkb@koenigsberg.invalid> wrote:
>> >  
>> >> 	Hello,
>> >> 
>> >> 	I'm debugging a huge program that can enter in deadlock on
>> >> a pthread_exit() syscall. I use gcc compiler on Linux or NetBSD.  
>> >
>> > Do you observe same behavior on both systems?  
>> 
>> 	Not exactly. On Linux side, pthread_exit() enters in a
>> deadlock. On NetBSD side, I don't know. Execution stops, but when I
>> try to attach gdb on faulty process, it abots with sigtrap if I
>> remember.
>> 
>> 	I'm sure there is an issue in my code, and I'm not sure that
>> it is pthread related. pthread_exit() only triggers the bug. It's not
>> a memory corruption, maybe a race condition, but I have looked for
>> 	this condition with a piece of paper without any result.
>> 
>> 	Best regards,
>> 
>> 	JKB
>> 
>
> If pthread_exit enters deadlock that means either something holds lock
> or mutex memory is corrupted. NetBSD case shows that probably memory is
> corrupted rather deadlock...

	Maybe. pthread_exit() (on glibc side) enters in deadlock in
	libunwind. I don't see how could lock this mutex. It could be a
	memory corruption also, but I'm trying to track a memory corruption for a
	long time without any success.

	Regards,

	JKB

-- 
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr

[toc] | [prev] | [next] | [standalone]

#90969

On Mon, 25 Jul 2016 11:58:38 +0000 (UTC)
JKB <jkb@koenigsberg.invalid> wrote:

> Le Mon, 25 Jul 2016 13:47:25 +0200,
> Melzzzzz <mel@zzzzz.com> écrivait :
> > On Mon, 25 Jul 2016 11:43:57 +0000 (UTC)
> > JKB <jkb@koenigsberg.invalid> wrote:
> >  
> >> Le Sat, 23 Jul 2016 00:52:17 +0200,
> >> Melzzzzz <mel@zzzzz.com> écrivait :  
> >> > On Wed, 20 Jul 2016 16:47:01 +0000 (UTC)
> >> > JKB <jkb@koenigsberg.invalid> wrote:
> >> >    
> >> >> 	Hello,
> >> >> 
> >> >> 	I'm debugging a huge program that can enter in deadlock
> >> >> on a pthread_exit() syscall. I use gcc compiler on Linux or
> >> >> NetBSD.    
> >> >
> >> > Do you observe same behavior on both systems?    
> >> 
> >> 	Not exactly. On Linux side, pthread_exit() enters in a
> >> deadlock. On NetBSD side, I don't know. Execution stops, but when I
> >> try to attach gdb on faulty process, it abots with sigtrap if I
> >> remember.
> >> 
> >> 	I'm sure there is an issue in my code, and I'm not sure
> >> that it is pthread related. pthread_exit() only triggers the bug.
> >> It's not a memory corruption, maybe a race condition, but I have
> >> looked for this condition with a piece of paper without any result.
> >> 
> >> 	Best regards,
> >> 
> >> 	JKB
> >>   
> >
> > If pthread_exit enters deadlock that means either something holds
> > lock or mutex memory is corrupted. NetBSD case shows that probably
> > memory is corrupted rather deadlock...  
> 
> 	Maybe. pthread_exit() (on glibc side) enters in deadlock in
> 	libunwind. I don't see how could lock this mutex. It could be
> a memory corruption also, but I'm trying to track a memory corruption
> for a long time without any success.
> 
> 	Regards,
> 
> 	JKB
> 

Do you unmap a lot? Perhaps you just unmap some region of process
memory leading to this problem?

[toc] | [prev] | [next] | [standalone]

#90977

Le Mon, 25 Jul 2016 14:00:43 +0200,
Melzzzzz <mel@zzzzz.com> écrivait :
> On Mon, 25 Jul 2016 11:58:38 +0000 (UTC)
> JKB <jkb@koenigsberg.invalid> wrote:
>
>> Le Mon, 25 Jul 2016 13:47:25 +0200,
>> Melzzzzz <mel@zzzzz.com> écrivait :
>> > On Mon, 25 Jul 2016 11:43:57 +0000 (UTC)
>> > JKB <jkb@koenigsberg.invalid> wrote:
>> >  
>> >> Le Sat, 23 Jul 2016 00:52:17 +0200,
>> >> Melzzzzz <mel@zzzzz.com> écrivait :  
>> >> > On Wed, 20 Jul 2016 16:47:01 +0000 (UTC)
>> >> > JKB <jkb@koenigsberg.invalid> wrote:
>> >> >    
>> >> >> 	Hello,
>> >> >> 
>> >> >> 	I'm debugging a huge program that can enter in deadlock
>> >> >> on a pthread_exit() syscall. I use gcc compiler on Linux or
>> >> >> NetBSD.    
>> >> >
>> >> > Do you observe same behavior on both systems?    
>> >> 
>> >> 	Not exactly. On Linux side, pthread_exit() enters in a
>> >> deadlock. On NetBSD side, I don't know. Execution stops, but when I
>> >> try to attach gdb on faulty process, it abots with sigtrap if I
>> >> remember.
>> >> 
>> >> 	I'm sure there is an issue in my code, and I'm not sure
>> >> that it is pthread related. pthread_exit() only triggers the bug.
>> >> It's not a memory corruption, maybe a race condition, but I have
>> >> looked for this condition with a piece of paper without any result.
>> >> 
>> >> 	Best regards,
>> >> 
>> >> 	JKB
>> >>   
>> >
>> > If pthread_exit enters deadlock that means either something holds
>> > lock or mutex memory is corrupted. NetBSD case shows that probably
>> > memory is corrupted rather deadlock...  
>> 
>> 	Maybe. pthread_exit() (on glibc side) enters in deadlock in
>> 	libunwind. I don't see how could lock this mutex. It could be
>> a memory corruption also, but I'm trying to track a memory corruption
>> for a long time without any success.
>> 
>> 	Regards,
>> 
>> 	JKB
>> 
>
> Do you unmap a lot? Perhaps you just unmap some region of process
> memory leading to this problem?

	I only use one mmap(). And I unmap this memory _after_
	pthread_join().

	When pthread_exit() enters in deadlock, I have checked that mmaped
	object is available.

	Regards,

	JKB

-- 
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr

[toc] | [prev] | [next] | [standalone]

#90980

On Mon, 25 Jul 2016 12:18:35 +0000 (UTC)
JKB <jkb@koenigsberg.invalid> wrote:

> Le Mon, 25 Jul 2016 14:00:43 +0200,
> Melzzzzz <mel@zzzzz.com> écrivait :
> > On Mon, 25 Jul 2016 11:58:38 +0000 (UTC)
> > JKB <jkb@koenigsberg.invalid> wrote:
> >  
> >> Le Mon, 25 Jul 2016 13:47:25 +0200,
> >> Melzzzzz <mel@zzzzz.com> écrivait :  
> >> > On Mon, 25 Jul 2016 11:43:57 +0000 (UTC)
> >> > JKB <jkb@koenigsberg.invalid> wrote:
> >> >    
> >> >> Le Sat, 23 Jul 2016 00:52:17 +0200,
> >> >> Melzzzzz <mel@zzzzz.com> écrivait :    
> >> >> > On Wed, 20 Jul 2016 16:47:01 +0000 (UTC)
> >> >> > JKB <jkb@koenigsberg.invalid> wrote:
> >> >> >      
> >> >> >> 	Hello,
> >> >> >> 
> >> >> >> 	I'm debugging a huge program that can enter in
> >> >> >> deadlock on a pthread_exit() syscall. I use gcc compiler on
> >> >> >> Linux or NetBSD.      
> >> >> >
> >> >> > Do you observe same behavior on both systems?      
> >> >> 
> >> >> 	Not exactly. On Linux side, pthread_exit() enters in a
> >> >> deadlock. On NetBSD side, I don't know. Execution stops, but
> >> >> when I try to attach gdb on faulty process, it abots with
> >> >> sigtrap if I remember.
> >> >> 
> >> >> 	I'm sure there is an issue in my code, and I'm not sure
> >> >> that it is pthread related. pthread_exit() only triggers the
> >> >> bug. It's not a memory corruption, maybe a race condition, but
> >> >> I have looked for this condition with a piece of paper without
> >> >> any result.
> >> >> 
> >> >> 	Best regards,
> >> >> 
> >> >> 	JKB
> >> >>     
> >> >
> >> > If pthread_exit enters deadlock that means either something holds
> >> > lock or mutex memory is corrupted. NetBSD case shows that
> >> > probably memory is corrupted rather deadlock...    
> >> 
> >> 	Maybe. pthread_exit() (on glibc side) enters in deadlock in
> >> 	libunwind. I don't see how could lock this mutex. It could
> >> be a memory corruption also, but I'm trying to track a memory
> >> corruption for a long time without any success.
> >> 
> >> 	Regards,
> >> 
> >> 	JKB
> >>   
> >
> > Do you unmap a lot? Perhaps you just unmap some region of process
> > memory leading to this problem?  
> 
> 	I only use one mmap(). And I unmap this memory _after_
> 	pthread_join().
> 
> 	When pthread_exit() enters in deadlock, I have checked that
> mmaped object is available.
> 
> 	Regards,
> 
> 	JKB
> 

It is not problem *when* you munmap, rather *what* you munmap....

[toc] | [prev] | [next] | [standalone]

#90984

Le Mon, 25 Jul 2016 14:20:01 +0200,
Melzzzzz <mel@zzzzz.com> écrivait :
>
> It is not problem *when* you munmap, rather *what* you munmap....
>

	If I unmap() some memory after usage by pthread_join(), I don't 
	understand how this unmap() can triggered this issue. As
	pthread_exit() enters in deadlock, unmap() is never reached.

	JKB

-- 
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr

[toc] | [prev] | [next] | [standalone]

#90986

On Mon, 25 Jul 2016 12:26:53 +0000 (UTC)
JKB <jkb@koenigsberg.invalid> wrote:

> Le Mon, 25 Jul 2016 14:20:01 +0200,
> Melzzzzz <mel@zzzzz.com> écrivait :
> >
> > It is not problem *when* you munmap, rather *what* you munmap....
> >  
> 
> 	If I unmap() some memory after usage by pthread_join(), I
> don't understand how this unmap() can triggered this issue. As
> 	pthread_exit() enters in deadlock, unmap() is never reached.
> 
> 	JKB
> 

Does pthread_exit deadlocks first time it enters or after a while?
If after a while, your munmap can cause issue...

[toc] | [prev] | [next] | [standalone]

#90987

Le Mon, 25 Jul 2016 14:28:39 +0200,
Melzzzzz <mel@zzzzz.com> écrivait :
> On Mon, 25 Jul 2016 12:26:53 +0000 (UTC)
> JKB <jkb@koenigsberg.invalid> wrote:
>
>> Le Mon, 25 Jul 2016 14:20:01 +0200,
>> Melzzzzz <mel@zzzzz.com> écrivait :
>> >
>> > It is not problem *when* you munmap, rather *what* you munmap....
>> >  
>> 
>> 	If I unmap() some memory after usage by pthread_join(), I
>> don't understand how this unmap() can triggered this issue. As
>> 	pthread_exit() enters in deadlock, unmap() is never reached.
>> 
>> 	JKB
>> 
>
> Does pthread_exit deadlocks first time it enters or after a while?
> If after a while, your munmap can cause issue...

	First time.

	JKB

-- 
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr

[toc] | [prev] | [next] | [standalone]

#90991

Le Mon, 25 Jul 2016 12:35:58 +0000 (UTC),
JKB <jkb@koenigsberg.invalid> écrivait :
> Le Mon, 25 Jul 2016 14:28:39 +0200,
> Melzzzzz <mel@zzzzz.com> écrivait :
>> On Mon, 25 Jul 2016 12:26:53 +0000 (UTC)
>> JKB <jkb@koenigsberg.invalid> wrote:
>>
>>> Le Mon, 25 Jul 2016 14:20:01 +0200,
>>> Melzzzzz <mel@zzzzz.com> écrivait :
>>> >
>>> > It is not problem *when* you munmap, rather *what* you munmap....
>>> >  
>>> 
>>> 	If I unmap() some memory after usage by pthread_join(), I
>>> don't understand how this unmap() can triggered this issue. As
>>> 	pthread_exit() enters in deadlock, unmap() is never reached.
>>> 
>>> 	JKB
>>> 
>>
>> Does pthread_exit deadlocks first time it enters or after a while?
>> If after a while, your munmap can cause issue...
>
> 	First time.
>
> 	JKB
>

	Some news.

	When a pthread_exit() enters in deadlock, it is always the first
	one.

	Pseudo code :

	main()
	{
		for(;;)
		{
			if (fork() == 0)
			{
				pthread_create(thread1);
				pthread_create(thread2);
				...
				stop(thread2);
				pthread_join(thread2);
				stop(thread1);
				pthread_join(thread1);
			}
		}
	}

	stop() set a global variable to stop thread that normally exit with
	pthread_exit(). In my case, thread2's pthread_exit() enters in
	deadlock. Never thread1's one.

	If I write :

	main()
	{
		for(;;)
		{
			if (fork() == 0)
			{
				pthread_create(thread1);
				pthread_create(thread2);
				...
				stop(thread1);
				pthread_join(thread1);
				stop(thread2);
				pthread_join(thread2);
			}
		}
	}

	thread1's pthread_exit() randomly enter in deadlock. Never thread2's
	one.

	Please note that thread1 tid is allocated in a mmap() (but is only
	used from the process that have created thread1) and thread2 tid is
	allocated in a regular struct by malloc().

	Regards,

	JKB

-- 
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web