a bug with pthread?

a bug with pthread?

Post by Randy Chapma » Tue, 30 Dec 1997 04:00:00



[public reply, as I think a few people might be interested in the results]

Quote:>// pthread_detach (*chld_thr);

Without doing this, you will leak memory.  The pthread library MUST keep
information for each thread that exits until it has been reaped, unless it
is detached.  You will find the same "leaky" behavior exists on Solaris
(yes, I tried your program there).

Note also two other problems in your code.  First off

Quote:>      delete clt;

But the pointer that was passed in was on the *stack*.  You can't delete
something from the stack like that (on my glibc6 machine, this causes a core
dump).

Secondly (and much worse, IMHO), is the fact that you passed in a stack
structure.  It appears that you have omitted some code, so I will assume
what you do is fill in this stack structure with some data and then pass the
pointer in like you do.  But what if the following chain of events occur?

Fill in data for thread 1.
Call pthread_create for thread 1.
Fill in data for thread 2.
Call pthread_create for thread 2.
--now, thread 1 starts running-- (yes, this is a perfectly valid happening)
--now, thread 2 starts running-- (yes, this is a perfectly valid happening)

You will note that both threads get the data meants for thread 2.  Your
original idea of deleting clt is correct -- clt needs to be in the heap, not
on the stack.

Best of luck!
--randy


> I test the performance of pthreads using this code.
>I found that the program size keep increasing even if
>the thread has been stoped. Seem to be some memory leak.
>Is there anything wrong
>with my code or  a bug in pthread? please give me some
>hints. Thanks!

>PS. you can use ps -fu yourusername  -o vsz -o rss -o comm
>to see the size of the process.

[code clipped]
 
 
 

1. Are pthreads' semaphores supposed to do this or is it a Linux bug?

By mistake, I had coded (in pseudo code)

Program Initialization
    Initialize semaphore with sem_init()
    acquire semaphore with sem_wait()
    if( Optional Test )
        {
        ...
        release semaphore with sem_post()
        }
    ...

Program Processing
    ...

Program Termination
    acquire semaphore with sem_wait()
    ...

And didn't execute the optional test and the program hung.  Fine, I
understand that.  But then I changed the last sem_wait() to sem_trywait()
and the program still hung.  That I don't understand.  Is this a bug or is
there something in these semaphores that hangs when a program tries to wait
on a semaphore that it already has acquired?

FWIW, It's gcc-2.95.3 & libc-5.3.12-31.

    TIA
        Norm

2. Sparc Install [no CD-ROM]

3. Bug in Solaris pthreads when using SCHED_RR??

4. bug or not?

5. Pthread bug

6. sysinfo

7. aix pthread bug?

8. binutils bug/requirements

9. Pthreads bug fix [was Re: jdk1.3.1p5]

10. a bug with pthread?

11. pthreads bug fix revised

12. Bug in <pthread.h> ?

13. Bug in libc ? Or bug in nslookup ?