Description of problem: During work on my bash library, I ran this with an extremely unstable version (basically first shot just after rewriting printing backend): FFOOD_DEBUG=true ffmanage which was supposed to print usage info. After some debug info it ceased to react and shortly after that I was able to interrupt it (using C-c). On next attempt, I waited little longer before interrupting, but script did not quit. I tried to "hold" C-c for while, which resulted in the segfault. Regarding the script and library, I was just in process of overhauling the whole printing mechanism, so I was expecting anything could happen. My guess is some kind of infinite recursion. I will add comment once I find out and probably create reproducer. Version-Release number of selected component: bash-4.2.47-2.fc20 Additional info: reporter: libreport-2.2.2 backtrace_rating: 4 cmdline: /bin/bash /usr/local/bin/ffmanage crash_function: __mbrtowc executable: /usr/bin/bash kernel: 3.15.4-200.fc20.x86_64 runlevel: N 5 type: CCpp uid: 0 Truncated backtrace: Thread no. 1 (10 frames) #0 __mbrtowc at mbrtowc.c:64 #1 mbrlen at /usr/include/wchar.h:402 #2 mbschr at mbschr.c:62 #3 string_extract at subst.c:737 #4 parameter_brace_expand at subst.c:6961 #5 param_expand at subst.c:7656 #6 expand_word_internal at subst.c:8144 #7 shell_expand_word_list at subst.c:9251 #8 expand_word_list_internal at subst.c:9368 #9 expand_words at subst.c:8990
Created attachment 917530 [details] File: backtrace
Created attachment 917531 [details] File: cgroup
Created attachment 917532 [details] File: core_backtrace
Created attachment 917533 [details] File: dso_list
Created attachment 917534 [details] File: environ
Created attachment 917535 [details] File: exploitable
Created attachment 917536 [details] File: limits
Created attachment 917537 [details] File: maps
Created attachment 917538 [details] File: open_fds
Created attachment 917539 [details] File: proc_pid_status
Created attachment 917540 [details] File: var_log_messages
Looking at the backtrace, I think this is another bugzilla where bash got killed by infinite recursion. Please try: ulimit -s unlimited FUNCNEST=256 FFOOD_DEBUG=true ffmanage Unless it crashes again, not having FUNCNEST set by default is the correct intended behaviour, which may result in a SIGSEGV on resource depletion(doesn't even have to be the stack).
(In reply to Ondrej Oprala from comment #12) Yes, it's infinite recursion. In fact, you can reproduce the crash with as little as: fn() { fn } fn > Please try: > ulimit -s unlimited > FUNCNEST=256 FFOOD_DEBUG=true ffmanage With unlimited stack size, the script seems to go on and on forever (or until some resource depletion which could be after a very long time). > Unless it crashes again, not having FUNCNEST set by default is the correct > intended behaviour, which may result in a SIGSEGV on resource > depletion(doesn't even have to be the stack). I'm not sure I understand. Do you mean that it's OK to segfault when stack limit is reached (vs. rerporting error and exitting gracefully)? In that case, you can close this as NOTABUG. (Other thing I found out is that FUNCNEST does not seem to have any effect; even set at 1, bash happily recurses forever ... that is another bug, am I right?)
(In reply to Alois Mahdal from comment #13) > (In reply to Ondrej Oprala from comment #12) > > Yes, it's infinite recursion. In fact, you can reproduce the crash with as > little as: > > fn() { > fn > } > fn > > > > Please try: > > ulimit -s unlimited > > FUNCNEST=256 FFOOD_DEBUG=true ffmanage > > With unlimited stack size, the script seems to go on and on forever (or > until some resource depletion which could be after a very long time). Yes, that's expected. > > > Unless it crashes again, not having FUNCNEST set by default is the correct > > intended behaviour, which may result in a SIGSEGV on resource > > depletion(doesn't even have to be the stack). > > I'm not sure I understand. Do you mean that it's OK to segfault when stack > limit is reached (vs. rerporting error and exitting gracefully)? In that > case, you can close this as NOTABUG. Basically, yes. The mechanism similar to FUNCNEST is what all the shells use. The difference between bash and e.g. zsh/ksh is that bash has no default value for FUNCNEST and allows recursing "infinitely" by default. > > (Other thing I found out is that FUNCNEST does not seem to have any effect; > even set at 1, bash happily recurses forever ... that is another bug, am I > right?) Interesting. I am unable to reproduce that. However yes, that would be another bug. Closing this bz.
Cleaning up my attic... (In reply to Ondrej Oprala from comment #14) [...] > > (Other thing I found out is that FUNCNEST does not seem to have any effect; > > even set at 1, bash happily recurses forever ... that is another bug, am I > > right?) > > Interesting. I am unable to reproduce that. However yes, that would be > another bug. Filed as bug 1274553.