Re: Segmentation fault when -x is added and variable contains nulls
On 2/5/14 10:51 PM, Dan Jacobson wrote: > # su - nobody > No directory, logging in with HOME=/ > $ cat /tmp/r > LC_CTYPE=zh_TW.UTF-8 N=$(echo 統一|iconv -t big5 -f utf-8) sh -xc ': $N' > $ sh /tmp/r > /tmp/r: line 1: 4551 Segmentation fault LC_CTYPE=zh_TW.UTF-8 N=$(echo > 統一|iconv -t big5 -f utf-8) sh -xc ': $N' > > Something about that embedded null. > bash, version 4.3.0(1)-rc1 (i486-pc-linux-gnu) Probably. How about a stack traceback from gdb? -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Segmentation fault when -x is added and variable contains nulls
On Thu, Feb 06, 2014 at 11:51:25AM +0800, Dan Jacobson wrote: > # su - nobody > No directory, logging in with HOME=/ > $ cat /tmp/r > LC_CTYPE=zh_TW.UTF-8 N=$(echo ??|iconv -t big5 -f utf-8) sh -xc ': $N' > $ sh /tmp/r > /tmp/r: line 1: 4551 Segmentation fault LC_CTYPE=zh_TW.UTF-8 N=$(echo > ??|iconv -t big5 -f utf-8) sh -xc ': $N' > > Something about that embedded null. > bash, version 4.3.0(1)-rc1 (i486-pc-linux-gnu) Just for the record, a variable can't contain a NUL byte. I don't know what your input string is (my system can't handle this locale; I just see ?? in my mail client), nor do I know what the output of the iconv command is for that input. Let's speculate that (as implied by your Subject) there is a NUL byte somewhere in the middle of it. First thing you should do is hunt down whoever invented a locale with NUL bytes in characters, because that's just horrible. Second thing, if the iconv command truly generates characters with a NUL in them, then the variable N which is populated by reading this stream is either going to be truncated at that point, or the NUL byte will simply be skipped, depending on what your system's "sh" is. In bash: imadev:~$ N=$(printf '\x22\x23\x00\x24\x25') imadev:~$ printf %s "$N" | od -t x1 000 22 23 24 25 004 If that NUL byte was required to form the correct character in your locale, then the variable's actual contents (missing the NUL byte) may be nonsensical. That may be what's causing the seg fault. If I were you, I'd check the output of that iconv command, hex dumping it to get the exact sequence of bytes. If one of them really is a NUL byte then you can't store that sequence in a shell variable, or pass it as an argument to any command. You'll either have to store the data in files, or switch to a language that can handle strings with embedded NULs.
Re: declare -ia does not enfore integer type on initialisation
On 2/5/14 5:25 PM, Peggy Russell wrote: >>> Description: >>> declare -ia not enforced if variable is initiated using = >> >> Correct; bash applies the integer attribute after the variable assignment. >> It has been this way since arrays were introduced (well, at least as far >> back as bash-3.2; that's when I stopped looking). > > Perhaps documenting the behavior would be helpful. Maybe the last sentence > to the declare help could say, "Attributes added with -a or -A do not take > effect until subsequent assignments." Thanks, good idea. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Segmentation fault when -x is added and variable contains nulls
On Thu, Feb 6, 2014 at 3:38 PM, Chet Ramey wrote: > On 2/5/14 10:51 PM, Dan Jacobson wrote: > > # su - nobody > > No directory, logging in with HOME=/ > > $ cat /tmp/r > > LC_CTYPE=zh_TW.UTF-8 N=$(echo 統一|iconv -t big5 -f utf-8) sh -xc ': $N' > > $ sh /tmp/r > > /tmp/r: line 1: 4551 Segmentation fault LC_CTYPE=zh_TW.UTF-8 > N=$(echo 統一|iconv -t big5 -f utf-8) sh -xc ': $N' > > > > Something about that embedded null. > > bash, version 4.3.0(1)-rc1 (i486-pc-linux-gnu) > > Probably. How about a stack traceback from gdb? > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, ITS, CWRUc...@case.edu > http://cnswww.cns.cwru.edu/~chet/ > > With bash 3.2.25(1)-release $ LC_CTYPE=zh_TW.UTF-8 N=$(echo 統一|iconv -t big5 -f utf-8) sh -xc ': $N' + : $'\262\316\244@' With bash-rc1 I can reproduce it with: bash -xc $': \262\316\244@' Core was generated by `./bash -xc : $N'. Program terminated with signal 11, Segmentation fault. #0 ansic_quote (str=, flags=, rlen=0x0) at strtrans.c:282 282 *r++ = c; (gdb) bt #0 ansic_quote (str=, flags=, rlen=0x0) at strtrans.c:282 #1 0x004303af in xtrace_print_word_list (list=0xa175ce8, xtflags=) at print_cmd.c:543 #2 0x00436a0b in execute_simple_command (simple_command=0xa1750c8, pipe_in=-1, pipe_out=-1, async=0, fds_to_close=0xa175128) at execute_cmd.c:4008 #3 0x004342d5 in execute_command_internal (command=0xa175088, asynchronous=0, pipe_in=-1, pipe_out=-1, fds_to_close=0xa175128) at execute_cmd.c:784 #4 0x00475dd2 in parse_and_execute (string=, from_file=0x4b5d58 "-c", flags=) at evalstring.c:359 #5 0x0041ec14 in run_one_command (command=0x7fffbdc94b0b ": $N") at shell.c:1339 #6 0x0041fcaf in main (argc=, argv=0x7fffbdc928c8, env=0x7fffbdc928e8) at shell.c:694 (gdb) q
Re: Segmentation fault when -x is added and variable contains nulls
On Thu, Feb 6, 2014 at 4:07 PM, Pierre Gaston wrote: > > > > On Thu, Feb 6, 2014 at 3:38 PM, Chet Ramey wrote: > >> On 2/5/14 10:51 PM, Dan Jacobson wrote: >> > # su - nobody >> > No directory, logging in with HOME=/ >> > $ cat /tmp/r >> > LC_CTYPE=zh_TW.UTF-8 N=$(echo 統一|iconv -t big5 -f utf-8) sh -xc ': $N' >> > $ sh /tmp/r >> > /tmp/r: line 1: 4551 Segmentation fault LC_CTYPE=zh_TW.UTF-8 >> N=$(echo 統一|iconv -t big5 -f utf-8) sh -xc ': $N' >> > >> > Something about that embedded null. >> > bash, version 4.3.0(1)-rc1 (i486-pc-linux-gnu) >> >> Probably. How about a stack traceback from gdb? >> >> -- >> ``The lyf so short, the craft so long to lerne.'' - Chaucer >> ``Ars longa, vita brevis'' - Hippocrates >> Chet Ramey, ITS, CWRUc...@case.edu >> http://cnswww.cns.cwru.edu/~chet/ >> >> > > With bash 3.2.25(1)-release > > $ LC_CTYPE=zh_TW.UTF-8 N=$(echo 統一|iconv -t big5 -f utf-8) sh -xc ': $N' > + : $'\262\316\244@' > > With bash-rc1 I can reproduce it with: bash -xc $': \262\316\244@' > > > Core was generated by `./bash -xc : $N'. > Program terminated with signal 11, Segmentation fault. > #0 ansic_quote (str=, flags=, > rlen=0x0) at strtrans.c:282 > 282 *r++ = c; > (gdb) bt > #0 ansic_quote (str=, flags=, > rlen=0x0) at strtrans.c:282 > #1 0x004303af in xtrace_print_word_list (list=0xa175ce8, > xtflags=) at print_cmd.c:543 > #2 0x00436a0b in execute_simple_command > (simple_command=0xa1750c8, pipe_in=-1, pipe_out=-1, async=0, > fds_to_close=0xa175128) at execute_cmd.c:4008 > #3 0x004342d5 in execute_command_internal (command=0xa175088, > asynchronous=0, pipe_in=-1, pipe_out=-1, fds_to_close=0xa175128) at > execute_cmd.c:784 > #4 0x00475dd2 in parse_and_execute (string=, > from_file=0x4b5d58 "-c", flags=) at evalstring.c:359 > #5 0x0041ec14 in run_one_command (command=0x7fffbdc94b0b ": $N") > at shell.c:1339 > #6 0x0041fcaf in main (argc=, > argv=0x7fffbdc928c8, env=0x7fffbdc928e8) at shell.c:694 > (gdb) q > Sorry, I should have added my locale,en_US.UTF-8, it seems it's a problem with handling broken UTF-8 as it doesn't happen with: LC_ALL=C ./bash -xc $': \262\316\244@'
Re: Segmentation fault when -x is added and variable contains nulls
Greg Wooledge writes: > On Thu, Feb 06, 2014 at 11:51:25AM +0800, Dan Jacobson wrote: >> # su - nobody >> No directory, logging in with HOME=/ >> $ cat /tmp/r >> LC_CTYPE=zh_TW.UTF-8 N=$(echo ??|iconv -t big5 -f utf-8) sh -xc ': $N' >> $ sh /tmp/r >> /tmp/r: line 1: 4551 Segmentation fault LC_CTYPE=zh_TW.UTF-8 N=$(echo >> ??|iconv -t big5 -f utf-8) sh -xc ': $N' >> >> Something about that embedded null. >> bash, version 4.3.0(1)-rc1 (i486-pc-linux-gnu) > > Just for the record, a variable can't contain a NUL byte. I don't > know what your input string is (my system can't handle this locale; I > just see ?? in my mail client), nor do I know what the output of > the iconv command is for that input. Let's speculate that (as implied > by your Subject) there is a NUL byte somewhere in the middle of it. BIG5 is a multi-byte encoding, it doesn't have embedded NUL bytes. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: Segmentation fault when -x is added and variable contains nulls
What a clod I was, thinking @ was ^@. OK glad you guys are hot on the trail.
Re: Bad file descriptor with coproc and pipe
On 2/5/14 4:37 PM, Michal Sojka wrote: >> Bash closes file descriptors associated with coprocs in child processes, >> since they are pipes. It's even more careful when those child processes >> are part of pipelines. It's really a bad idea to have pipe file >> descriptors open in multiple processes; that prevents SIGPIPE generation >> and EOF on read when one writer exits. > > Thanks for the explanation. Then the bug is that it is not documented: > https://www.gnu.org/software/bash/manual/bashref.html#Coprocesses Thanks; this is already in the bash-4.3 version of the manual(s). Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Segmentation fault when -x is added and variable contains nulls
On 2/6/14 9:07 AM, Pierre Gaston wrote: > > With bash 3.2.25(1)-release > > $ LC_CTYPE=zh_TW.UTF-8 N=$(echo 統一|iconv -t big5 -f utf-8) sh -xc ': $N' > + : $'\262\316\244@' > > With bash-rc1 I can reproduce it with: bash -xc $': \262\316\244@' Thanks for the reproducer. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Segmentation fault when -x is added and variable contains nulls
On 2/5/14 10:51 PM, Dan Jacobson wrote:
> # su - nobody
> No directory, logging in with HOME=/
> $ cat /tmp/r
> LC_CTYPE=zh_TW.UTF-8 N=$(echo 統一|iconv -t big5 -f utf-8) sh -xc ': $N'
> $ sh /tmp/r
> /tmp/r: line 1: 4551 Segmentation fault LC_CTYPE=zh_TW.UTF-8 N=$(echo
> 統一|iconv -t big5 -f utf-8) sh -xc ': $N'
Thanks for the report. I've attached a patch that will be in bash-4.3.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
*** ../bash-4.3-rc2/lib/sh/strtrans.c 2013-03-09 14:55:18.0 -0500
--- lib/sh/strtrans.c 2014-02-06 11:10:52.0 -0500
***
*** 279,284
*r++ = c;
else
! for (b = 0; b < (int)clen; c = b ? *++s : c)
! *r++ = c;
}
--- 279,287
*r++ = c;
else
! {
! for (b = 0; b < (int)clen; b++)
! *r++ = (unsigned char)s[b];
! s += clen - 1; /* -1 because of the increment above */
! }
}
Hitting C-c C-c in Emacs' *shell* causes segmentation fault
Dear Bug-Bash gentlemen, http://debbugs.gnu.org/16665 says it seems like a bash bug. Please have a look if you are also an emacs person.
Re: Hitting C-c C-c in Emacs' *shell* causes segmentation fault
> "CR" == Chet Ramey writes: CR> OK, I'll bite. What is C-c C-c supposed to do? It looks like it just CR> spews a bunch of garbage to your screen. Is that the intent? C-c C-c runs the command comint-interrupt-subjob, which is an interactive compiled Lisp function in `comint.el'. (comint-interrupt-subjob) Interrupt the current subjob. This command also kills the pending input between the process mark and point.
Re: Hitting C-c C-c in Emacs' *shell* causes segmentation fault
On 2014-02-06 22:16:56 -0500, Chet Ramey wrote: > OK, I'll bite. What is C-c C-c supposed to do? It looks like it just > spews a bunch of garbage to your screen. Is that the intent? According to the Emacs manual[0]: > Interrupt the shell or its current subjob if any > (comint-interrupt-subjob). This command also kills any shell input > pending in the shell buffer and not yet sent. I should disclaim that I'm not an Emacs user, so it's quite possible that I am looking at the wrong part of the manual. [0]: http://www.gnu.org/software/emacs/manual/html_node/emacs/Shell-Mode.html pgpZR9n_9MoBx.pgp Description: PGP signature
Re: Hitting C-c C-c in Emacs' *shell* causes segmentation fault
On 2/6/14, 6:11 PM, Dan Jacobson wrote: > Dear Bug-Bash gentlemen, > http://debbugs.gnu.org/16665 says it seems like a bash bug. > Please have a look if you are also an emacs person. OK, I'll bite. What is C-c C-c supposed to do? It looks like it just spews a bunch of garbage to your screen. Is that the intent? -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Hitting C-c C-c in Emacs' *shell* causes segmentation fault
Chet Ramey wrote: > What is C-c C-c supposed to do? It pretty much just sends SIGINT.
