Re: weird segfault with ksh

[Paul Eggert]

Which ksh patch rev is your Solaris 2.6 host running?  The latest is
106361-15, dated 2003-02-07.

Solaris 7 ksh's latest patch is 108162-08, dated 2003-02-26, and it
doesn't seem to fix any bugs in this area, so I'd expect it would have
similar problems.  Since you haven't observed the bug with Solaris 8,
I checked Solaris 8 ksh patch 110662-22, dated 2006-03-15: it fixes
the following possibly-relevant Sun bugs:

4402737 ksh* Getting core dump if lines are over 30
6277643 ksh is insufficiently careful with alignment
5056943 Fix for BugID#4753777 introduced new ksh bug
4753777 ksh core dumped
4902634 ksh(1) dumped a core in a different place of BugID#4753777

One common problem area occurred if you have a low limit on the number
of open file descriptors (ulimit -n).  If it was less than 64, the
buggy ksh got very sick.  I'd guess it should be 256 to be safe.
Also, reportedly if you invoked the buggy ksh with a file descriptor
open in the range 64-and-up, it might dump core in a phase-of-the-moon
way.

There is also this bug, but it is marked "closed", which suggests that
it wasn't really a bug:

4327781 ksh dumps core by SIGSEGV in scan_all() on Solaris 2.6


> Adding a `set -x' early in the configure script make the bug go
> Heisenberg.

What happens with "truss -f" without "set -x"?


> http://lists.gnu.org/archive/html/libtool/2006-05/msg00087.html ,

The symptoms of this bug -- unlink("/tmp/sh...") gone bad -- are
reminiscent of of Sun bugs 2133735, 2133736, 2133737, 6264121, each of
which have the synopsis "ksh: here-document (/tmp/sh* file) is
unlinked too early when started in background".  However these are new
bugs, not yet fixed, so I'd expect to see them in Solaris 8 and up as
well.


Sun stopped issuing patches for Solaris 2.6 on 2003-07-23, so there's
not much that users can do about this, other than switch to Bash.
Similarly for Solaris 7 ksh -- patches stopped on 2005-08-15.

It looks like pre-Solaris-8 ksh is pretty buggy.  Perhaps we just
ought to warn people not to use it.  Or we can filter it out somehow,
without using a test case, by using 'uname'.