Hi,
FX reminded me that execvp() is not guaranteed to be
async-signal-safe, hence we must use execve(). So instead during
library initialization try to find addr2line.
Regtested on x86_64-unknown-linux-gnu, Ok for trunk?
2011-05-29 Janne Blomqvist j...@gcc.gnu.org
PR libfortran/48931
On Sun, May 22, 2011 at 23:21, FX fxcoud...@gmail.com wrote:
Dear Janne,
Sorry I'm a bit late on this, but since async-signal-safe code is so hard to
get right (at least for me), I wanted to help review your new code. It's very
nice to have this instead of my initial ugly implementation,
Ah, good catch! That's a bit of a bummer though, since the nice thing
about execvp() is that it searches the path for the executable, so
it'll work even if the user has addr2line installed somewhere else
than /usr/bin. For execve(), one needs to provide an absolute path.
Yes, I know. Sorry :)
On May 24 2011, FX wrote:
One solution could be to search the PATH for addr2line during library
initialization (where we don't need to be async-signal-safe), and then
store it somewhere and use it in show_backtrace().
That's one way. Another way is just to store a copy of the PATH during
Dear Janne,
Sorry I'm a bit late on this, but since async-signal-safe code is so hard to
get right (at least for me), I wanted to help review your new code. It's very
nice to have this instead of my initial ugly implementation, and I have only
spotted on issue: AFAICT, execvp() is not safe to
On Sun, May 15, 2011 at 02:12:58PM +0300, Janne Blomqvist wrote:
so, here is take 3 (sigh). Compared to take 2, it no longer uses
stdio, since opening a stdio FILE stream probably malloc()'s a buffer,
which is not async-signal-safe.
Regtested on x86_64-unknown-linux-gnu, Ok for trunk?
PING
On Sun, May 15, 2011 at 14:12, Janne Blomqvist
blomqvist.ja...@gmail.com wrote:
Hi,
so, here is take 3 (sigh). Compared to take 2, it no longer uses
stdio, since opening a stdio FILE stream probably malloc()'s a buffer,
which is not async-signal-safe.
Regtested on
On 05/14/2011 09:40 PM, Janne Blomqvist wrote:
Hi,
the current version of showing the backtrace is not async-signal-safe
as it uses backtrace_symbols() which, in turn, uses malloc(). The
attached patch changes the backtrace printing functionality to instead
use backtrace_symbols_fd() and
On 05/17/2011 07:50 PM, Toon Moene wrote:
On 05/14/2011 09:40 PM, Janne Blomqvist wrote:
Hi,
the current version of showing the backtrace is not async-signal-safe
as it uses backtrace_symbols() which, in turn, uses malloc(). The
attached patch changes the backtrace printing functionality to
On Sat, May 14, 2011 at 22:40, Janne Blomqvist
blomqvist.ja...@gmail.com wrote:
Hi
the current version of showing the backtrace is not async-signal-safe
as it uses backtrace_symbols() which, in turn, uses malloc(). The
attached patch changes the backtrace printing functionality to instead
Hi,
so, here is take 3 (sigh). Compared to take 2, it no longer uses
stdio, since opening a stdio FILE stream probably malloc()'s a buffer,
which is not async-signal-safe.
Regtested on x86_64-unknown-linux-gnu, Ok for trunk?
2011-05-15 Janne Blomqvist j...@gcc.gnu.org
PR
Hi,
the current version of showing the backtrace is not async-signal-safe
as it uses backtrace_symbols() which, in turn, uses malloc(). The
attached patch changes the backtrace printing functionality to instead
use backtrace_symbols_fd() and pipes.
Also, it does some other work on backtrace
12 matches
Mail list logo
