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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
