Re: Pthread_create and memory issues.

From: Alex Keahan (alex_at_hightemplar.com)
Date: 05/22/04

  • Next message: William M. Grim: "Jails: An rc.d script"
    To: "Cole" <cole@opteqint.net>, <freebsd-hackers@freebsd.org>
    Date: Sun, 23 May 2004 00:20:09 +0300
    
    

    On Saturday 22 May 2004 10:39 pm, Cole wrote:
    > Hi
    >
    > Ok this is just a more direct question that the thread Memory Leak.
    >
    > I have a program using pthread_create, and it runs fine, no compile errors
    > or warnings, it all works fine, not a single issue, but it very very slowly
    > uses up memory. The program creates a fixed number of threads, and after
    > each one has run to completion it stores them for a while for use again if
    > needed soon, else it destroys them after a specified amount of time.

    Cole,

    Are you certain it's not a bug in your code?

    A thread's resources are not immediately released at termination, unless
    the thread was created with the detachstate attribute set to
    PTHREAD_CREATE_DETACHED, or if pthread_detach has been called for
    its pthread_t.

    An undetached thread remains in the terminated state until its identifier is
    passed to pthread_join or pthread_detach.

    At a minimum, a terminated thread retains its pthread_t identifier and the
    return value that was returned from the thread's run function (or the value
    specified in a call to pthread_exit).

    To sum it up, you have three options:

    1) create your threads detached (PTHREAD_CREATE_DETACHED attribute),
    2) detach them after creation (pthread_detach), or
    3) join with the terminated threads to recycle them (pthread_join).

    Alex Keahan

    >
    > Now i have tried to use ElectricFence to try track down the program, and it
    > created cores all pointing round about to pthread_create. So then i tried
    > to use mpatrol, and it either doesnt even crash, or cause errors, or it
    > creates a core file that is so large with so many instructions, that is
    > well over 1000 instruction calls, but as far as i can see they both seem to
    > be pointing to pthread_create. With mpatrol i set
    > MPATROL_OPTIONS=LEAKTABLE, but it never produces any output and crashes
    > before i can even test the program. It also uses up close to 100% of the
    > cpu before crashing.
    >
    > I was just wondering if anyone else has had any other memory debugging
    > program suggestions, or has had any issues with pthread_create.
    >
    > If you want i can post the code or at the very least my pthread_create
    > call.
    >
    > Thanks
    > /Cole

    _______________________________________________
    freebsd-hackers@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
    To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"


  • Next message: William M. Grim: "Jails: An rc.d script"

    Relevant Pages

    • Re: Lightweight Alternative to Mozilla-Firebird
      ... Peter A. Cole wrote: ... > Just wondering if anyone can suggest a lighter weight alternative to Mozilla ... > up a little too much memory. ...
      (Debian-User)
    • Re: Interesting comments
      ... I've admitted my history isn't all that great nor is my memory. ... > talking about the US Cole. ... On second thought am I blaming Clinton for ...
      (sci.med.transcription)
    • Re: HP Warranty
      ... Don Cole wrote: ... I replaced the bad Ram with Memory from Crucial and everything is working ... under warranty and make HP replace it through that chassis instead. ...
      (comp.sys.hp.hardware)