On Sun, May 29, 2011 at 01:17:05PM +0300, Janne Blomqvist wrote:
>
> 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?
>
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
PR libfortran/48931
* libgfo
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
ini
> 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 Sun, May 22, 2011 at 23:21, FX 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, and I have only
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 u
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
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 x86_64-unknown-linux-gnu, Ok for trunk?
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 i
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 pipes.
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
PR libfortran/48931
* co
On Sat, May 14, 2011 at 22:40, 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_
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 print
13 matches
Mail list logo
