[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