Bug 1118978 - [abrt] bash: __mbrtowc(): bash killed by SIGSEGV
Summary: [abrt] bash: __mbrtowc(): bash killed by SIGSEGV
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: bash
Version: 20
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ondrej Oprala
QA Contact: Fedora Extras Quality Assurance
URL: https://retrace.fedoraproject.org/faf...
Whiteboard: abrt_hash:13705af0af84c221a4a44ae3664...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-12 16:06 UTC by Alois Mahdal
Modified: 2016-02-01 02:10 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-07-21 10:13:06 UTC


Attachments (Terms of Use)
File: backtrace (243.81 KB, text/plain)
2014-07-12 16:06 UTC, Alois Mahdal
no flags Details
File: cgroup (178 bytes, text/plain)
2014-07-12 16:06 UTC, Alois Mahdal
no flags Details
File: core_backtrace (289.01 KB, text/plain)
2014-07-12 16:06 UTC, Alois Mahdal
no flags Details
File: dso_list (580 bytes, text/plain)
2014-07-12 16:06 UTC, Alois Mahdal
no flags Details
File: environ (2.29 KB, text/plain)
2014-07-12 16:06 UTC, Alois Mahdal
no flags Details
File: exploitable (82 bytes, text/plain)
2014-07-12 16:06 UTC, Alois Mahdal
no flags Details
File: limits (1.29 KB, text/plain)
2014-07-12 16:06 UTC, Alois Mahdal
no flags Details
File: maps (2.49 KB, text/plain)
2014-07-12 16:06 UTC, Alois Mahdal
no flags Details
File: open_fds (138 bytes, text/plain)
2014-07-12 16:06 UTC, Alois Mahdal
no flags Details
File: proc_pid_status (904 bytes, text/plain)
2014-07-12 16:06 UTC, Alois Mahdal
no flags Details
File: var_log_messages (36.55 KB, text/plain)
2014-07-12 16:06 UTC, Alois Mahdal
no flags Details

Description Alois Mahdal 2014-07-12 16:06:19 UTC
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

Comment 1 Alois Mahdal 2014-07-12 16:06:23 UTC
Created attachment 917530 [details]
File: backtrace

Comment 2 Alois Mahdal 2014-07-12 16:06:24 UTC
Created attachment 917531 [details]
File: cgroup

Comment 3 Alois Mahdal 2014-07-12 16:06:27 UTC
Created attachment 917532 [details]
File: core_backtrace

Comment 4 Alois Mahdal 2014-07-12 16:06:29 UTC
Created attachment 917533 [details]
File: dso_list

Comment 5 Alois Mahdal 2014-07-12 16:06:30 UTC
Created attachment 917534 [details]
File: environ

Comment 6 Alois Mahdal 2014-07-12 16:06:31 UTC
Created attachment 917535 [details]
File: exploitable

Comment 7 Alois Mahdal 2014-07-12 16:06:32 UTC
Created attachment 917536 [details]
File: limits

Comment 8 Alois Mahdal 2014-07-12 16:06:33 UTC
Created attachment 917537 [details]
File: maps

Comment 9 Alois Mahdal 2014-07-12 16:06:35 UTC
Created attachment 917538 [details]
File: open_fds

Comment 10 Alois Mahdal 2014-07-12 16:06:36 UTC
Created attachment 917539 [details]
File: proc_pid_status

Comment 11 Alois Mahdal 2014-07-12 16:06:38 UTC
Created attachment 917540 [details]
File: var_log_messages

Comment 12 Ondrej Oprala 2014-07-14 14:22:43 UTC
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).

Comment 13 Alois Mahdal 2014-07-14 17:02:06 UTC
(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?)

Comment 14 Ondrej Oprala 2014-07-21 10:13:06 UTC
(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.

Comment 15 Alois Mahdal 2015-10-23 01:38:41 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.