[PATCH-V4] xserver: Optional backtrace handler
Mark Kettenis
mark.kettenis at xs4all.nl
Thu Oct 13 02:37:10 PDT 2011
> From: Jeremy Huddleston <jeremyhu at apple.com>
> Date: Wed, 12 Oct 2011 19:28:00 -0700
>
> On Oct 12, 2011, at 6:12 PM, Alan Coopersmith wrote:
>
> > On 10/12/11 10:50 AM, Keith Packard wrote:
> >> 2. I'd love to figure out how to fork at the time of the error; this
> >> would encourage people to actually use this option regularly.
> >>
> >> posix threads makes the usual libc fork() function take the malloc
> >> mutex across its operations, but I wonder if syscall(SYS_fork) is
> >> portable enough to be used instead?
> >
> > As discussed on IRC, no, syscall() is not portable, but the libc
> > fork() issue seems to be a linux problem, as SUSv2/Unix98
> > documents fork() as safe to use in a signal handler, but glibc
> > does not. posix_spawn() may also be a more portable option.
> >
> > The existing Solaris xorg_backtrace_pstack() in Xorg's os/backtrace.c has
> > been forking in the signal handler for a couple years now - ideally we'd
> > be able to mostly share the code across platforms, but I've not looked into
> > that.
>
> If fork(2) in glibc isn't signal handler safe, are you sure
> posix_spawn(3) is in glibc?
posix_spawn(3) isn't really portable since it is part of the optional
ADVANCED REALTIME extensions to POSIX.
More information about the xorg-devel
mailing list