[ILUG] pthread stack problems?

Dermot McGahon dermot at dspsrv.com
Tue Jun 29 09:31:10 IST 2004


On Mon, 28 Jun 2004 20:23:13 +0100, Bryan O'Donoghue <bryano at europlex.ie>  
wrote:

>> Right. The only difference is the pthread function. efence will only
>> work correctly if the efence malloc is being used. I don't know if
>> that pthread function is supposed to be allocating memory using
>> malloc, but it's possible that due to shared library order or
>> something that the normal glibc malloc is being called instead of
>> the efence one.
>
> I don't know on that one.

It could be worth finding out.

$ nm -v /usr/local/bin/mplayer | grep malloc
          U malloc@@GLIBC_2.0

This uses the glibc malloc. You would hope to see something
different here.



> #2  0x4003c4e1 in pthread_onexit_process () from  
> /lib/i686/libpthread.so.0

I don't have the source (or the time) to look at this, but
this C function does free memory.


> I'm not sure of the correct commands to pinpoint that integer in the  
> pthread library.

You have a stack trace now. Download and read the source.

You could try mtrace()/memprof/valgrind for other perspectives.

Post a question to a pthreads/glibc mailing list?


> In any case maybe my understanding of the exit system call is  
> inadequate, but, shouldn't exit() be the *last* thing that gets called  
> by my program?
>
> WTF is all this post exit() pthread stuff anyway?

Deleting thread local storage memory :)

There is nothing wrong with thread housekeeping being done as a
consequence of an exit call. It's a multi-threaded program, there
is more than one exit.


Dermot.
--



More information about the ILUG mailing list