[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#410899: marked as done (libc6: _IO_stdfile_0_lock deadlock in printf cancellation)

Your message dated Sun, 13 Mar 2016 19:52:23 +0100
with message-id <20160313185223.GA10281@aurel32.net>
and subject line Bug#410899: libc6: _IO_stdfile_0_lock deadlock in printf cancellation
has caused the Debian Bug report #410899,
regarding libc6: _IO_stdfile_0_lock deadlock in printf cancellation
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
410899: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=410899
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: libc6
Version: 2.3.6.ds1-11
Severity: normal

Hi,

I'm led to believe (from older libc docs that include POSIX threads)
that printf is a known cancellation point (albeit indirectly).

However, in practice it appears that if it is called with a cancellation
request pending it will deadlock...  The following code reproduces this:


#define _REENTRANT 1

#include <pthread.h>
#include <stdio.h>

void *thread(void*)
{
    printf("hello thread\n");
    return NULL;
}

int main()
{
    pthread_t id;
    pthread_create(&id,NULL,thread,NULL);
    pthread_cancel(id);
    printf("joining thread\n");
    pthread_join(id,NULL);
    printf("done\n");

    return 0;
}


$ g++ -g thread_join.cpp -o thread_join -pthread
$ ./thread_join
joining thread
<hang>


$ gdb ./thread_join 18867
(gdb) info threads
  1 Thread 47608883437824 (LWP 18867)  0x00002b4cce7f530b in __lll_mutex_lock_wait () from /lib/libc.so.6
(gdb) bt
#0  0x00002b4cce7f530b in __lll_mutex_lock_wait () from /lib/libc.so.6
#1  0x00002b4cce959090 in _IO_stdfile_0_lock () from /lib/libc.so.6
#2  0x0000000000000000 in ?? ()

Cheers,
Ron


-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-amd64
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)

Versions of packages libc6 depends on:
ii  tzdata                        2007a-3    Time Zone and Daylight Saving Time

libc6 recommends no packages.

-- no debconf information

--- End Message ---
--- Begin Message --- 
Version: 2.7-18

On 2007-02-14 21:33, Ron wrote:
> Package: libc6
> Version: 2.3.6.ds1-11
> Severity: normal
> 
> Hi,
> 
> I'm led to believe (from older libc docs that include POSIX threads)
> that printf is a known cancellation point (albeit indirectly).
> 
> However, in practice it appears that if it is called with a cancellation
> request pending it will deadlock...  The following code reproduces this:
> 
> 
> #define _REENTRANT 1
> 
> #include <pthread.h>
> #include <stdio.h>
> 
> void *thread(void*)
> {
>     printf("hello thread\n");
>     return NULL;
> }
> 
> int main()
> {
>     pthread_t id;
>     pthread_create(&id,NULL,thread,NULL);
>     pthread_cancel(id);
>     printf("joining thread\n");
>     pthread_join(id,NULL);
>     printf("done\n");
> 
>     return 0;
> }
> 
> 
> $ g++ -g thread_join.cpp -o thread_join -pthread
> $ ./thread_join
> joining thread
> <hang>
> 
> 
> $ gdb ./thread_join 18867
> (gdb) info threads
>   1 Thread 47608883437824 (LWP 18867)  0x00002b4cce7f530b in __lll_mutex_lock_wait () from /lib/libc.so.6
> (gdb) bt
> #0  0x00002b4cce7f530b in __lll_mutex_lock_wait () from /lib/libc.so.6
> #1  0x00002b4cce959090 in _IO_stdfile_0_lock () from /lib/libc.so.6
> #2  0x0000000000000000 in ?? ()

The problem is reproducible in Etch, but not in Lenny. I believe the
problem has been fixed in between, I am therefore closing the bug.

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

--- End Message ---
Reply to: