Ubuntu
glibc package

Memory problems on pthread_cancel()

Bug #50722 reported by i_dont_want_to_register
18
This bug affects 1 person
Affects Status Importance Assigned to Milestone
glibc (Ubuntu)
Won't Fix
High
Unassigned

Bug Description

$ cat ops.c
#include <unistd.h>
#include <pthread.h>

void *func(void *nop)
{
  sleep(100);
  return NULL;
}

int main(int argc, char *argv[])
{
  void *ptr;
  pthread_t id;
  pthread_create(&id,NULL,func,NULL);
  pthread_cancel(id);
  pthread_join(id,&ptr);
  return 0;
}

$ cc ops.c -o ops -lpthread -ggdb -Wall

$ valgrind ./ops
==23044== Memcheck, a memory error detector.
==23044== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==23044== Using LibVEX rev 1471, a library for dynamic binary translation.
==23044== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==23044== Using valgrind-3.1.0-Debian, a dynamic binary instrumentation framework.
==23044== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==23044== For more details, rerun with: -v
==23044==
==23044== Invalid read of size 8
==23044== at 0x4010664: (within /lib/ld-2.3.6.so)
==23044== by 0x40089BC: (within /lib/ld-2.3.6.so)
==23044== by 0x4004DF3: (within /lib/ld-2.3.6.so)
==23044== by 0x4006612: (within /lib/ld-2.3.6.so)
==23044== by 0x4D2C51B: (within /lib/libc-2.3.6.so)
==23044== by 0x400B13F: (within /lib/ld-2.3.6.so)
==23044== by 0x4D2D0C9: _dl_open (in /lib/libc-2.3.6.so)
==23044== by 0x4D2E627: (within /lib/libc-2.3.6.so)
==23044== by 0x400B13F: (within /lib/ld-2.3.6.so)
==23044== by 0x4D2E6D2: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==23044== by 0x4B2ABCB: pthread_cancel_init (in /lib/libpthread-2.3.6.so)
==23044== by 0x4B27867: pthread_cancel (in /lib/libpthread-2.3.6.so)
==23044== Address 0x566D0F8 is 16 bytes inside a block of size 19 alloc'd
==23044== at 0x4A19A16: malloc (vg_replace_malloc.c:149)
==23044== by 0x4006A00: (within /lib/ld-2.3.6.so)
==23044== by 0x4D2C51B: (within /lib/libc-2.3.6.so)
==23044== by 0x400B13F: (within /lib/ld-2.3.6.so)
==23044== by 0x4D2D0C9: _dl_open (in /lib/libc-2.3.6.so)
==23044== by 0x4D2E627: (within /lib/libc-2.3.6.so)
==23044== by 0x400B13F: (within /lib/ld-2.3.6.so)
==23044== by 0x4D2E6D2: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==23044== by 0x4B2ABCB: pthread_cancel_init (in /lib/libpthread-2.3.6.so)
==23044== by 0x4B27867: pthread_cancel (in /lib/libpthread-2.3.6.so)
==23044== by 0x400624: main (ops.c:15)
==23044==
==23044== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 8 from 1)
==23044== malloc/free: in use at exit: 1,604 bytes in 6 blocks.
==23044== malloc/free: 6 allocs, 0 frees, 1,604 bytes allocated.
==23044== For counts of detected errors, rerun with: -v
==23044== searching for pointers to 6 not-freed blocks.
==23044== checked 8,567,792 bytes.
==23044==
==23044== LEAK SUMMARY:
==23044== definitely lost: 0 bytes in 0 blocks.
==23044== possibly lost: 136 bytes in 1 blocks.
==23044== still reachable: 1,468 bytes in 5 blocks.
==23044== suppressed: 0 bytes in 0 blocks.
==23044== Reachable blocks (those to which a pointer was found) are not shown.
==23044== To see them, rerun with: --show-reachable=yes

$ uname -a
Linux ub2006 2.6.15-25-amd64-generic #1 SMP PREEMPT Wed Jun 14 11:28:03 UTC 2006 x86_64 GNU/Linux

$ ls -al /lib/ld-linux-x86-64.so.2
lrwxrwxrwx 1 root root 11 2006-06-02 12:51 /lib/ld-linux-x86-64.so.2 -> ld-2.3.6.so

Revision history for this message
Chris Sherlock (ta-bu-shi-da-yu) wrote :
Download full text (42.8 KiB)

==3641== Memcheck, a memory error detector.
==3641== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==3641== Using LibVEX rev 1658, a library for dynamic binary translation.
==3641== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==3641== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation framework.
==3641== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==3641== For more details, rerun with: -v
==3641==
==3641== Warning: client switching stacks? SP change: 0xBED226BC --> 0x419D3C0
==3641== to suppress, use: --max-stackframe=1162325252 or greater
==3641== Warning: client switching stacks? SP change: 0x419D134 --> 0xBED226BC
==3641== to suppress, use: --max-stackframe=1162324600 or greater
==3641== Warning: client switching stacks? SP change: 0xBED2268C --> 0x419D134
==3641== to suppress, use: --max-stackframe=1162324648 or greater
==3641== further instances of this message will not be shown.
==3641== Conditional jump or move depends on uninitialised value(s)
==3641== at 0x403C4A6: __pth_sched_eventmanager (in /usr/lib/libpthread.so.20.0.27)
==3641==
==3641== Invalid read of size 4
==3641== at 0x4083566: swapcontext (in /lib/tls/i686/cmov/libc-2.5.so)
==3641== Address 0x419D834 is 260 bytes inside a block of size 768 alloc'd
==3641== at 0x4021620: malloc (vg_replace_malloc.c:149)
==3641== by 0x403C1E7: __pth_tcb_alloc (in /usr/lib/libpthread.so.20.0.27)
==3641== by 0x403E80D: pth_spawn (in /usr/lib/libpthread.so.20.0.27)
==3641== by 0x403AE25: pthread_create (in /usr/lib/libpthread.so.20.0.27)
==3641== by 0x80485AC: main (pth-bug.c:16)
==3641==
==3641== Invalid read of size 4
==3641== at 0x4083569: swapcontext (in /lib/tls/i686/cmov/libc-2.5.so)
==3641== Address 0x419D838 is 264 bytes inside a block of size 768 alloc'd
==3641== at 0x4021620: malloc (vg_replace_malloc.c:149)
==3641== by 0x403C1E7: __pth_tcb_alloc (in /usr/lib/libpthread.so.20.0.27)
==3641== by 0x403E80D: pth_spawn (in /usr/lib/libpthread.so.20.0.27)
==3641== by 0x403AE25: pthread_create (in /usr/lib/libpthread.so.20.0.27)
==3641== by 0x80485AC: main (pth-bug.c:16)
==3641==
==3641== Invalid read of size 4
==3641== at 0x408356C: swapcontext (in /lib/tls/i686/cmov/libc-2.5.so)
==3641== Address 0x419D83C is 268 bytes inside a block of size 768 alloc'd
==3641== at 0x4021620: malloc (vg_replace_malloc.c:149)
==3641== by 0x403C1E7: __pth_tcb_alloc (in /usr/lib/libpthread.so.20.0.27)
==3641== by 0x403E80D: pth_spawn (in /usr/lib/libpthread.so.20.0.27)
==3641== by 0x403AE25: pthread_create (in /usr/lib/libpthread.so.20.0.27)
==3641== by 0x80485AC: main (pth-bug.c:16)
==3641==
==3641== Invalid read of size 4
==3641== at 0x408356F: swapcontext (in /lib/tls/i686/cmov/libc-2.5.so)
==3641== Address 0x419D844 is 276 bytes inside a block of size 768 alloc'd
==3641== at 0x4021620: malloc (vg_replace_malloc.c:149)
==3641== by 0x403C1E7: __pth_tcb_alloc (in /usr/lib/libpthread.so.20.0.27)
==3641== by 0x403E80D: pth_spawn (in /usr/lib/libpthread.so.20.0.27)
==3641== by 0x403AE25: pthread_create (in /usr/lib/libpthread.so.20....

Revision history for this message
Jérôme Guelfucci (jerome-guelfucci-deactivatedaccount) wrote :

Thank you for your bug report. Do you still have this issue with the latest release of Ubuntu ?

Changed in glibc:
status: Unconfirmed → Needs Info
Revision history for this message
Chris Sherlock (ta-bu-shi-da-yu) wrote : Re: [Bug 50722] Re: Memory problems on pthread_cancel()

I'm afraid so... any ideas what's going on here?

Chris

On 6/8/07, Jérôme Guelfucci <email address hidden> wrote:
> Thank you for your bug report. Do you still have this issue with the
> latest release of Ubuntu ?
>
> ** Changed in: glibc (Ubuntu)
> Status: Unconfirmed => Needs Info
>
> --
> Memory problems on pthread_cancel()
> https://bugs.launchpad.net/bugs/50722
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
Jérôme Guelfucci (jerome-guelfucci-deactivatedaccount) wrote :

Sorry, I don't understand. What do you mean ?

Revision history for this message
Chris Sherlock (ta-bu-shi-da-yu) wrote :

You asked me whether the Ubuntu bug 50722 was still ongoing! It is and
I have reproduced it.

Chris

On 6/10/07, Jérôme Guelfucci <email address hidden> wrote:
> Sorry, I don't understand. What do you mean ?
>
> --
> Memory problems on pthread_cancel()
> https://bugs.launchpad.net/bugs/50722
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
Chris Sherlock (ta-bu-shi-da-yu) wrote :

You wanted to know if this bug is ongoing. It is!

Revision history for this message
Jérôme Guelfucci (jerome-guelfucci-deactivatedaccount) wrote :

Oh ok, perfect ! Sorry :) I'm marking this as confirmed.

Changed in glibc:
importance: Undecided → High
status: Needs Info → Confirmed
Jérôme Guelfucci (jerome-guelfucci-deactivatedaccount)
Changed in glibc:
status: Confirmed → Triaged
Revision history for this message
Jeff Bailey (jbailey) wrote :

> __pth_tcb_alloc (in /usr/lib/libpthread.so.20.0.27

Umm, this isn't from glibc. Marking it as invalid. Please use dpkg -S to figure out what package that comes from and file a bug against it. Or try again against the system glibc. Nothing but madness can come from running a third-party pthreads library.

Changed in glibc:
status: Triaged → Invalid
Revision history for this message
Chris Sherlock (ta-bu-shi-da-yu) wrote :

Hi Jeff,

I don't know I would have picked up a third party pthread library.

chris@ubuntu:~$ dpkg -S /usr/lib/libpthread.so.20.0.27
libpthread20: /usr/lib/libpthread.so.20.0.27
chris@ubuntu:~$

Chris

On Dec 8, 2007 9:49 AM, Jeff Bailey <email address hidden> wrote:
> > __pth_tcb_alloc (in /usr/lib/libpthread.so.20.0.27
>
> Umm, this isn't from glibc. Marking it as invalid. Please use dpkg -S
> to figure out what package that comes from and file a bug against it.
> Or try again against the system glibc. Nothing but madness can come
> from running a third-party pthreads library.
>
>
> ** Changed in: glibc (Ubuntu)
> Status: Triaged => Invalid
>
>
> --
> Memory problems on pthread_cancel()
> https://bugs.launchpad.net/bugs/50722
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
Daniel Janus (nathell) wrote :

I can confirm this on Hardy x86:

==15511== Memcheck, a memory error detector.
==15511== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==15511== Using LibVEX rev 1804, a library for dynamic binary translation.
==15511== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==15511== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation framework.
==15511== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==15511== For more details, rerun with: -v
==15511==
==15511== Invalid read of size 4
==15511== at 0x40151F3: (within /lib/ld-2.7.so)
==15511== by 0x4005C69: (within /lib/ld-2.7.so)
==15511== by 0x4007A97: (within /lib/ld-2.7.so)
==15511== by 0x4011543: (within /lib/ld-2.7.so)
==15511== by 0x400D5D5: (within /lib/ld-2.7.so)
==15511== by 0x4010F5D: (within /lib/ld-2.7.so)
==15511== by 0x415B291: (within /lib/tls/i686/cmov/libc-2.7.so)
==15511== by 0x400D5D5: (within /lib/ld-2.7.so)
==15511== by 0x415B454: __libc_dlopen_mode (in /lib/tls/i686/cmov/libc-2.7.so)
==15511== by 0x4043686: pthread_cancel_init (in /lib/tls/i686/cmov/libpthread-2.7.so)
==15511== by 0x403FB18: pthread_cancel (in /lib/tls/i686/cmov/libpthread-2.7.so)
==15511== by 0x80484EB: main (ops.c:15)
==15511== Address 0x499f0f0 is 16 bytes inside a block of size 19 alloc'd
==15511== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==15511== by 0x4008031: (within /lib/ld-2.7.so)
==15511== by 0x4011543: (within /lib/ld-2.7.so)
==15511== by 0x400D5D5: (within /lib/ld-2.7.so)
==15511== by 0x4010F5D: (within /lib/ld-2.7.so)
==15511== by 0x415B291: (within /lib/tls/i686/cmov/libc-2.7.so)
==15511== by 0x400D5D5: (within /lib/ld-2.7.so)
==15511== by 0x415B454: __libc_dlopen_mode (in /lib/tls/i686/cmov/libc-2.7.so)
==15511== by 0x4043686: pthread_cancel_init (in /lib/tls/i686/cmov/libpthread-2.7.so)
==15511== by 0x403FB18: pthread_cancel (in /lib/tls/i686/cmov/libpthread-2.7.so)
==15511== by 0x80484EB: main (ops.c:15)

Revision history for this message
ShwangShwing (gitonchev) wrote :

Any sollution/walk around? this bug is 2 years old.

Revision history for this message
Chris Sherlock (ta-bu-shi-da-yu) wrote :

When you get told by an Ubuntu person that you are running a 3rd party threads library, when you are using libpthread20, not sure if they are too interested.

Revision history for this message
ShwangShwing (gitonchev) wrote :

gtonchev@rnd2:~$ dpkg -S /usr/lib/libpthread.so
libc6-dev: /usr/lib/libpthread.so

So why is this bug marked as invalid?

Revision history for this message
Chris Sherlock (ta-bu-shi-da-yu) wrote :

Good question. I think someone made a mistake.

On Wed, Jul 30, 2008 at 5:02 PM, ShwangShwing <email address hidden> wrote:
> gtonchev@rnd2:~$ dpkg -S /usr/lib/libpthread.so
> libc6-dev: /usr/lib/libpthread.so
>
> So why is this bug marked as invalid?
>
> --
> Memory problems on pthread_cancel()
> https://bugs.launchpad.net/bugs/50722
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
Chris Sherlock (ta-bu-shi-da-yu) wrote :

I'm changing this to confirmed.

Changed in glibc:
status: Invalid → Confirmed
Revision history for this message
scuzzy (scuzzy) wrote :

I just tried this, and while I still get reachable blocks, I don't get any "definaly lost" memory:

==15623== LEAK SUMMARY:
==15623== definitely lost: 0 bytes in 0 blocks.
==15623== possibly lost: 0 bytes in 0 blocks.
==15623== still reachable: 892 bytes in 5 blocks.
==15623== suppressed: 0 bytes in 0 blocks.

This ammount of "reachable" memory doesn't change no matter how many threads you create/cancel/join. I'm using version libc-2.7 and libpthread-2.7.

Revision history for this message
Matthias Klose (doko) wrote :

> When you get told by an Ubuntu person that you are running
> a 3rd party threads library, when you are using libpthread20,
> not sure if they are too interested.

no, we are not. setting this to won't fix.

Changed in glibc:
status: Confirmed → Won't Fix
Revision history for this message
Chris Sherlock (ta-bu-shi-da-yu) wrote :

Ah well, I tried. It's a pity that Ubuntu doesn't want to accept bugs for components it ships, but there you go.

Revision history for this message
Matthias Klose (doko) wrote :

libpthread20 isn't shipped anymore.

Revision history for this message
Chris Sherlock (ta-bu-shi-da-yu) wrote :

Last comment from me, promise. You can't blame me for feeling a little miffed when I was told I was running a third party threading library!

Revision history for this message
Ivan Frederiks (idfred) wrote :

I get same stuff from valgrind for similar source code. I use Ubuntu 9.10 x86

==3058== HEAP SUMMARY:
==3058== in use at exit: 28 bytes in 1 blocks
==3058== total heap usage: 44 allocs, 43 frees, 122,820 bytes allocated
==3058==
==3058== Searching for pointers to 1 not-freed blocks
==3058== Checked 138,468 bytes
==3058==
==3058== 28 bytes in 1 blocks are still reachable in loss record 1 of 1
==3058== at 0x4024C1C: malloc (vg_replace_malloc.c:195)
==3058== by 0x400C01E: _dl_map_object_deps (dl-deps.c:506)
==3058== by 0x40117E0: dl_open_worker (dl-open.c:297)
==3058== by 0x400D485: _dl_catch_error (dl-error.c:178)
==3058== by 0x401119F: _dl_open (dl-open.c:586)
==3058== by 0x42930C1: do_dlopen (dl-libc.c:86)
==3058== by 0x400D485: _dl_catch_error (dl-error.c:178)
==3058== by 0x42931C0: dlerror_run (dl-libc.c:47)
==3058== by 0x42932DA: __libc_dlopen_mode (dl-libc.c:160)
==3058== by 0x4185876: pthread_cancel_init (unwind-forcedunwind.c:53)
==3058== by 0x4181EC3: pthread_cancel (pthread_cancel.c:40)
==3058== by 0x804D7ED: main (main.c:149)
==3058==
==3058== LEAK SUMMARY:
==3058== definitely lost: 0 bytes in 0 blocks
==3058== indirectly lost: 0 bytes in 0 blocks
==3058== possibly lost: 0 bytes in 0 blocks
==3058== still reachable: 28 bytes in 1 blocks
==3058== suppressed: 0 bytes in 0 blocks
==3058==
==3058== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 27 from 6)
--3058--
--3058-- used_suppression: 27 Debian libc6 (2.10.x) stripped dynamic linker
==3058==
==3058== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 27 from 6)

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.