openssh on NeXTstep
mouring at etoh.eviladmin.org
Thu Sep 25 23:32:40 EST 2003
Right.. Right.. I didn't see it when I running cpp over the file since for
some reason my preproccessor under Linux didn't change signal() to
mysignal() in bsd-misc.c, but there should be an #undef signal before the
return(signal(..)) to ensure the real signal gets used.
I'm still puzzled why NeXT triggers this because NeXT's signal() has too
loose of sementics for what we want and it should have defaulted to using
I remember having to dig around for a tolerable replacement for NeXT
Revision 1.1 / (download) - [select for diffs] , Sun Jul 9 13:26:27 2000
UTC (3 years, 2 months ago) by djm
- (djm) More NeXT compatibility from Ben Lindstrom <mouring at pconline.com>
Including sigaction() et al. replacements
This troubles me greatly.
On Thu, 25 Sep 2003, Michael Weiser wrote:
> On Wed, 24 Sep 2003, Michael Weiser wrote:
> > recall mysignal!? Is perhaps the #define wreaking havoc with the actual
> > signal call in bsd-misc.h so that it recursively calls itself until it
> > crashes?
> Indeed it seems to be that the #define signal mysignal changes the
> signal() call in mysignal() into mysignal() and thus makes it resursive
> which looks like hanging or gives a segfault in gdb (perhaps because of a
> smaller stack there). If I add an #undef signal just before the signal
> call in bsd-misc.c sshd behaves normally. This would seem to be a bug for
> all platforms that doen't have sigaction() and use just signal. Another
> workaround might be to always employ the sigaction() emulation of
> openbsd-compat for bsd-misc, even if HAVE_SIGACTION is undefined.
> Hope that helps.
> bye, Micha
> heinz rulez!
More information about the openssh-unix-dev