abrt version: 1.1.17 architecture: x86_64 Attached file: backtrace, 205035 bytes cmdline: ksh component: ksh Attached file: coredump, 8802304 bytes crash_function: nv_putval executable: /bin/ksh kernel: 2.6.35.11-83.fc14.x86_64 package: ksh-20110208-2.fc14 rating: 4 reason: Process /bin/ksh was killed by signal 11 (SIGSEGV) release: Fedora release 14 (Laughlin) time: 1301953757 uid: 500 How to reproduce ----- [joeldavis@titan-work etc]$ ksh bash: ksh: command not found... Install package 'ksh' to provide command 'ksh'? [N/y] * Running.. * Resolving dependencies.. * Waiting for authentication.. * Waiting in queue.. * Running.. * Resolving dependencies.. * Downloading packages.. * Testing changes.. * Installing packages.. * Scanning applications.. [joeldavis@titan-work etc]$ [joeldavis@titan-work etc]$ ksh $ alias echo="echo -e" $ echo "hey\n" hey $ echo -n "hey\n" hey $ exit [joeldavis@titan-work etc]$ ksh $ thing(){ > echo "fsdfdsf\n" > } $ thing() > > > thing $ thing Segmentation fault (core dumped) [joeldavis@titan-work etc]$ ksh $
Created attachment 489864 [details] File: backtrace
got the number of steps to reproduce down to three: [joeldavis@titan-work etc]$ ksh $ thing() > thing $ thing Segmentation fault (core dumped)
probably just segfaulting because of the recursion now that I think of it, the segfault seems kind of fast but this still doesn't seem like desirable behavior.
It's pretty fast, but it's a good, it just means that the shell is pretty fast :) Anyway, your guess is correct. This crash is caused by recursion, which makes it somehow special. Your code is trying to shoot itself and usually there is not too much you can do to prevent it (once you prevent it, there can be more "innovative" way how to shoot yourself). So I'll ask ksh upstream about this. Btw, bash, dash, mksh, ksh... all of them are crashing. Seems just zsh aborts with error message without crash.
$ bash -c 'thing() { thing; }; thing' Segmentation fault (core dumped) $ mksh -c 'thing() { thing; }; thing' Segmentation fault (core dumped) $ zsh -c 'thing() { thing; }; thing' thing: maximum nested function level reached $ dash -c 'thing() { thing; }; thing' Segmentation fault (core dumped)
yeah pretty much the only reason I didn't close it after I figured out what was causing that was just cause I was kind of expecting the zsh behavior where it won't do something that's categorically incorrect (i.e: single-line recursion with no arguments or only literal arguments). Ultimately I guess it's what you guys want to do with it, but I was thinking if you can reproduce it with three lines of code it probably falls within the realm of a sanity check, but then again I don't know how much work fixing a corner case like this would be, so I guess I'm just speculating about whether it's worth it. - Joel
from upstream: =================================== There is a limit (currently 1024) and when you pass that limit, ksh93 will say recursion too deep. However, it is possible to exceed the stack size on some systems before that limit is reached when leads to a core dump. =================================== There's no plan to change this behaviour.