Re: A quiz: Re: Second patch attempt for PATH_MAX fix in ruby1.9.1- 1.9.3~rc1-3
Svante Signell, le Fri 14 Oct 2011 17:48:31 +0200, a écrit :
> /* Avoid consuming stack as this module may be used from signal handler */
> static char *binary_filename = NULL;
>
> It wouldn't work with alloca, maybe with malloc!
alloca wouldn't work so much indeed. malloc has to be checked with
upstream. If rb_dump_backtrace_with_lines is to be called from a *Unix*
signal handler, then it is not safe to call malloc. The only solution
is then to use a fixed-length array, i.e. the ifndef PATH_MAX define
PATH_MAX lazy solution.
> A new pointer for binary_filename is created.
>
> strncpy(binary_filename, path, len);
> binary_filename[len] = '\0';
>
> calls fill_lines():
> fill_lines(num_traces, trace, syms, 1, &lines[i], lines);
>
> alloca():Here memory for binary_filename is freed: Bad!
> Not the case if malloc is used!
Where "here"? Memory allocated by alloca() is freed on exit from the
function which called it, not when it calls other functions.
> Question: free(binary_filename); is needed here in order not to allocate
> a new pointer without disposing the old one??
Yes.
> A new pointer for binary_filename is created: Is realloc usable?
Yes, although in that case, since the content does not need to be
preserved, free+malloc will probably be faster (doesn't copy the
content).
> alloca():Here memory for binary_filename is freed: Bad!
> Not the case if malloc is used!
Yes, that's also a good reason to avoid alloca: we don't know in advance
how much is needed, and alloca doesn't permit to fix that afterwards.
Samuel
Reply to: