Re: Memory issues with Tcl_CreateCommand

On Sep 21, 2:47 pm, Prashant <prashant.tha...@xxxxxxxxx> wrote:
On Sep 21, 4:58 pm, Alexandre Ferrieux <alexandre.ferri...@xxxxxxxxx>
wrote:





On Sep 21, 11:47 am, Prashant <prashant.tha...@xxxxxxxxx> wrote:

On Sep 21, 2:25 pm, Mark Janssen <mpc.jans...@xxxxxxxxx> wrote:

On Sep 21, 11:05 am, Prashant <prashant.tha...@xxxxxxxxx> wrote:

Hi,
  We have run into memory issues while trying to call a command
implemented on C side (using Tcl_CreateCommand i.e.).  With the
increase in number of arguments passed to the registered command,
memory consumption shoots up considerably and the same is not released
even after execution is complete.

 Steps:
  1. Tcl_CreateCommand (.., process_data, C_Process_Data, ...);
  2. eval process_data $huge_string_as_data ; #memory consumption
shoots up
  3. unset huge_string_as_data; # allocated memory is not released.

regards,
Prashant

Intial guess is mismanagement of reference counts in the C command,
but without seeing more details it's impossible to know. Can you
provide the implementation of the C command?

 I have actually commented out the whole code inside the C part just
to make sure that internal code is not causing the memory to jump.

int C_Process_Data(ClientData client_data , Tcl_Interp *interp, int
argc, char **argv) {
  return TCL_OK;

Hi,

Beware that your 'eval' at toplevel makes $huge_string_as_data be
handled as a literal, whose lifetime may not be so optimized as other
values.
Do you observe a similar leak without the eval ? Same question with
tcl_interactive set to 0 (I've observed extraneous refcounts on
literals in the interactive case).

  Without eval memory consumption doesn't shoot as dramatically.
  Having said that I do believe there's some leak which manifests
itself if data is huge. i.e. on C side argc is a huge value.

Oh, just noticed it was about argc and not just total size.
Indeed the leak is easily reproduced in pure script:

set big [lrepeat 10000000 a];set y [llength $big]
proc foo args {llength $args}
eval foo $big
unset big

Looking at the refcounts I see no leaks.
Now after a short talk with Miguel, it turns out that huge arglists
cause internal evaluation stack growth, which currently is not easily
reclaimed.

If you had a compelling case for doing this, I'd suggest you to open a
bugreport. However I see no good reason, so I'll just propose to shun
the [eval] and pass lists as single arguments instead.

-Alex
.

Relevant Pages

  • Re: memory leak using system.windows.forms.timer
    ... subroutine, memory leaks. ...     Private Sub CheckComputers() ... subroutine with a static number I still leak memory. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Memory issues with Tcl_CreateCommand
    ... increase in number of arguments passed to the registered command, ... memory consumption shoots up considerably and the same is not released ...   return TCL_OK; ... <shameless plug> you can use 8.6 HEAD with the ...
    (comp.lang.tcl)
  • Re: Memory leak in pthread_cancel with a detached thread.
    ...   pthread_t th; ... I shouldn't have any memory leak. ... There should be no leak, but that is not connected to the fact that the ... libraries to allocate memory that valgrind has to assume freed by the ...
    (comp.unix.programmer)
  • Re: Memory issues with Tcl_CreateCommand
    ... increase in number of arguments passed to the registered command, ... memory consumption shoots up considerably and the same is not released ...   return TCL_OK; ... Do you observe a similar leak without the eval? ...
    (comp.lang.tcl)
  • Re: Memory issues with Tcl_CreateCommand
    ... increase in number of arguments passed to the registered command, ... memory consumption shoots up considerably and the same is not released ...   return TCL_OK; ...
    (comp.lang.tcl)