users-prolog
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Atom table exhaustion?!


From: emacstheviking
Subject: Atom table exhaustion?!
Date: Mon, 18 May 2015 16:58:54 +0100

Do atoms get garbage collected if there are no remaining references to them or do they remain in the pool until the process terminates?

Erlang has a vulnerability whereby naive code can be made to flood the atom pool, does gprolog have that same issue?

I have written a really simple wrapper around libuuid and currently I am returning an atom... if I call my function 10,000 times, do I end up with 10,000 redundant atom table entries or will they be collected "soon" ?

As the code is so small I've included it here, starting with the foreign declaration:

:- foreign(uuid_generate(-codes), [fct_name(gp_uuid_generate)]).

And then the code... I would have liked to have returned a dynamically allocated string containing the characters but I am not yet sure how to go about that... would I declare the parameter as "?codes" and then unify it with the C-string value.... is this going to leak memory all over the place?

Thanks,
Sean.

#include <stdio.h>
#include <gprolog.h>
#include <uuid/uuid.h>

PlBool gp_uuid_generate(char* uuidTerm)
{
  uuid_t uuid;
  char szUUID[32+1];

  uuid_generate(uuid);
  uuid_unparse(uuid, szUUID);

  *uuidTerm = Pl_Mk_String(szUUID);

  return PL_TRUE;
}

INITIAL GUESS: YES, it can go bang!

| ?- statistics.
Memory               limit         in use            free

   trail  stack      16383 Kb            0 Kb        16383 Kb
   cstr   stack      16384 Kb            0 Kb        16384 Kb
   global stack      32767 Kb            4 Kb        32763 Kb
   local  stack      16383 Kb            0 Kb        16383 Kb
   atom   table      32768 atoms      1804 atoms     30964 atoms

Times              since start      since last

   user   time       0.005 sec       0.003 sec
   system time       0.004 sec       0.002 sec
   cpu    time       0.009 sec       0.005 sec
   real   time      58.540 sec      31.716 sec

That's from running it by hand... it seems that I will hit the limit at some point... looks like I need to return a dynamically allocated string but if I cannot find out how to do that without the proper memory management then I still have problems!

I will experiment...


reply via email to

[Prev in Thread] Current Thread [Next in Thread]