Certain pattern causing shell to crash

Certain pattern causing shell to crash

[Raghavendra D Prabhu]

[-- Attachment #1: Type: text/plain, Size: 1004 bytes --]

Hi,

Sourcing following function in a clean shell (zsh -f) followed by which
or tab completion is causing shell to segfault

=================
view () {
         if [[ -z $1 ]]
         then
                 ranger ~/Documents
         elif [[ $1 =~ ^http:* ]]
         then
                 url=${1#*=} 
                 dest="$HOME/Documents/${1##*/}" 
                 wget -c --content-disposition -O - -q $url > $dest
                 detach mupdf -r 143 $dest
         else
                 detach mupdf -r 143 "$@"
         fi
}
======================================

After sourcing this function, something like view <tab><tab> or which
view is crashing the shell. Surprisingly, view xyz.pdf is not crashing
the shell.

The pattern causing the crash is '=~'. To reproduce, it should be run
non-interactively and with arguments (atleast this is how I was able to
do)

Also, this can be reproduced on latest zsh git.

Also I am attaching the full backtrace from the core file.


-----------------

[-- Attachment #2: backtrace --]
[-- Type: text/plain, Size: 4264 bytes --]

[New Thread 14706]
Core was generated by `zsh -f'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007f35abeb75b2 in strlen () from /lib/libc.so.6

Thread 1 (Thread 14706):
#0  0x00007f35abeb75b2 in strlen () from /lib/libc.so.6
No symbol table info available.
#1  0x0000000000498214 in taddstr (s=0x25f1e4dd <Address 0x25f1e4dd out of bounds>) at text.c:115
        sl = 0
        c = -106 '\226'
#2  0x0000000000498380 in taddlist (state=0x7fffd39791f0, num=66) at text.c:141
No locals.
#3  0x0000000000498d59 in gettext2 (state=0x7fffd39791f0) at text.c:460
        p = 0x71c79c
        end = 0xde3a10
        s = 0x0
        n = 0x74e300
        stack = 0
        code = 56857514
#4  0x00000000004984d8 in getpermtext (prog=0x6e9988, c=0x71c738, start_indent=1) at text.c:192
        s = {prog = 0x6e9988, pc = 0x71c84c, strs = 0x71c844 "ranger"}
#5  0x000000000043ebb4 in printshfuncnode (hn=0x6e9950, printflags=32) at hashtable.c:923
        f = 0x6e9950
        t = 0x0
#6  0x000000000041ce06 in bin_whence (nam=0x7f35acccb8a0 "which", argv=0x7fffd39794b0, ops=0x7fffd39794e0, func=0) at builtin.c:3181
        suf = 0x0
        hn = 0x6e9950
        pprog = 0x0
        returnval = 0
        printflags = 32
        aliasflags = 32
        csh = 1
        all = 0
        v = 0
        wd = 0
        informed = 0
        cnam = 0x400000000 <Address 0x400000000 out of bounds>
#7  0x00000000004109ce in execbuiltin (args=0x7f35acccb858, bn=0x6c4a80) at builtin.c:450
        argarr = 0x7fffd39794b0
        argv = 0x7fffd39794b0
        pp = 0x4a7b7e ""
        name = 0x7f35acccb8a0 "which"
        optstr = 0x4a7b77 "ampsw"
        flags = 8
        sense = 0
        argc = 1
        execop = -745040496
        xtr = 0
        ops = {ind = '\000' <repeats 99 times>, "\001", '\000' <repeats 27 times>, args = 0x0, argscount = 0, argsalloc = 0}
#8  0x0000000000430ed0 in execcmd (state=0x7fffd3979d00, input=0, output=0, how=18, last1=2) at exec.c:3173
        restorelist = 0x0
        removelist = 0x0
        hn = 0x6c4a80
        args = 0x7f35acccb858
        node = 0x7f35acccb7b0
        fn = 0x0
        mfds = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}
        text = 0x6d1d60 "which view"
        save = {-2, -2, -2, -2, -2, -2, -2, -2, -2, -2}
        fil = 0
        dfil = 4818371
        is_cursh = 1
        type = 6
        do_exec = 0
        i = 10
        htok = 0
        nullexec = 0
        assign = 0
        forked = 0
        is_shfunc = 0
        is_builtin = 1
        is_exec = 0
        use_defpath = 0
        cflags = 0
        checked = 1
        oautocont = -1
        redir = 0x0
        code = 70
        beg = 0x7f35acccb7f4
        varspc = 0x0
        oxtrerr = 0x7f35ac192880
        newxtrerr = 0x0
#9  0x000000000042c6ea in execpline2 (state=0x7fffd3979d00, pcode=451, how=18, input=0, output=0, last1=0) at exec.c:1632
        pid = 0
        pipes = {-745039200, 32767}
#10 0x000000000042b83b in execpline (state=0x7fffd3979d00, slcode=4098, how=18, last1=0) at exec.c:1416
        ipipe = {0, 0}
        opipe = {0, 0}
        pj = 0
        newjob = 1
        old_simple_pline = 0
        slflags = 0
        code = 451
        lastwj = 0
        lpforked = 0
#11 0x000000000042aeed in execlist (state=0x7fffd3979d00, dont_change_job=0, exiting=0) at exec.c:1199
        donedebug = 0
        donetrap = 0
        next = 0x7f35acccb800
        code = 4098
        ret = 32565
        cj = 0
        csp = 0
        ltype = 18
        old_pline_level = 0
        old_list_pipe = 0
        oldlineno = 7
        oldnoerrexit = 0
#12 0x000000000042a95f in execode (p=0x7f35acccb7b0, dont_change_job=0, exiting=0, context=0x4ac377 "toplevel") at exec.c:1020
        s = {prog = 0x7f35acccb7b0, pc = 0x7f35acccb800, strs = 0x7f35acccb804 "which"}
        zsh_eval_context_len = 16
        alen = 0
#13 0x000000000044809c in loop (toplevel=1, justonce=0) at init.c:185
        toksav = 1
        prog = 0x7f35acccb7b0
        err = 0
        non_empty = 1
#14 0x000000000044b22a in zsh_main (argc=2, argv=0x7fffd3979ee8) at init.c:1508
        t = 0x7fffd3979ef8
        runscript = 0x0
        t0 = 158
#15 0x000000000040fed4 in main (argc=2, argv=0x7fffd3979ee8) at ./main.c:93
No locals.

Re: Certain pattern causing shell to crash

[Peter Stephenson]

On Thu, 6 Jan 2011 21:38:02 +0530
Raghavendra D Prabhu <raghu.prabhu13@gmail.com> wrote:
> Sourcing following function in a clean shell (zsh -f) followed by
> which or tab completion is causing shell to segfault
> 
> =================
> view () {
>          if [[ -z $1 ]]
>          then
>                  ranger ~/Documents
>          elif [[ $1 =~ ^http:* ]]
>          then
>                  url=${1#*=} 
>                  dest="$HOME/Documents/${1##*/}" 
>                  wget -c --content-disposition -O - -q $url > $dest
>                  detach mupdf -r 143 $dest
>          else
>                  detach mupdf -r 143 "$@"
>          fi
> }
> ======================================

Yes, I can get that.  The following is about the most simple form that
still causes it to happen:

crashme() {
  if [[ $1 =~ ^http:* ]]
  then
    url=${1#*=}
  fi
}
which crashme

It appears that the code that decodes the '=~' expression (it doesn't
happen if I turn that into '=') is causing the state to go awry, so that
the code in the line after the "then" is being read wrongly.  It's got
something to do with the regular expression, too; putting that in
parentheses or otherwise quoting the "^" makes it go away, so it maybe
related to how "^" is handled in this case.  It shouldn't be too hard to
localise; it's a shame that the the wordcode is completely
impenetrable.

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: Certain pattern causing shell to crash

[Ricky Zhou]

[-- Attachment #1: Type: text/plain, Size: 1008 bytes --]

On 2011-01-06 06:22:01 PM, Peter Stephenson wrote:
> Yes, I can get that.  The following is about the most simple form that
> still causes it to happen:
> 
> crashme() {
>   if [[ $1 =~ ^http:* ]]
>   then
>     url=${1#*=}
>   fi
> }
> which crashme
> 
> It appears that the code that decodes the '=~' expression (it doesn't
> happen if I turn that into '=') is causing the state to go awry, so that
> the code in the line after the "then" is being read wrongly.  It's got
> something to do with the regular expression, too; putting that in
> parentheses or otherwise quoting the "^" makes it go away, so it maybe
> related to how "^" is handled in this case.  It shouldn't be too hard to
> localise; it's a shame that the the wordcode is completely
> impenetrable.
For what it's worth, I did a git bisect, and the segfault was introduced
in d234059b1c6493e5eefb6c28aa2b8a021d894d51.  Hopefully this can be of
use to somebody more familiar with how this code works.

Thanks,
Ricky

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: Certain pattern causing shell to crash

[Peter Stephenson]

On Thu, 6 Jan 2011 13:51:35 -0500
Ricky Zhou <ricky@rzhou.org> wrote:
> For what it's worth, I did a git bisect, and the segfault was introduced
> in d234059b1c6493e5eefb6c28aa2b8a021d894d51.  Hopefully this can be of
> use to somebody more familiar with how this code works.

(Ah, so I need to use

git diff d234059b1c6493e5eefb6c28aa2b8a021d894d51^\!

to look at it.  Obvious.)

Yes, that narrows it down a lot, thanks.

Index: Src/text.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/text.c,v
retrieving revision 1.26
diff -p -u -r1.26 text.c
--- Src/text.c	14 Sep 2010 14:46:26 -0000	1.26
+++ Src/text.c	6 Jan 2011 19:43:49 -0000
@@ -785,8 +785,7 @@ gettext2(Estate state)
 			    taddstr(" ");
 			    taddstr(ecgetstr(state, EC_NODUP, NULL));
 			    if (ctype == COND_STREQ ||
-				ctype == COND_STRNEQ ||
-				ctype == COND_REGEX)
+				ctype == COND_STRNEQ)
 				state->pc++;
 			} else {
 			    /* Unary test: `-f foo' etc. */ 
Index: Test/C02cond.ztst
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/C02cond.ztst,v
retrieving revision 1.27
diff -p -u -r1.27 C02cond.ztst
--- Test/C02cond.ztst	10 Oct 2010 00:05:25 -0000	1.27
+++ Test/C02cond.ztst	6 Jan 2011 19:43:49 -0000
@@ -306,6 +306,21 @@ F:Failures in these cases do not indicat
 2:Error message for unknown infix condition
 ?(eval):1: unknown condition: -fail
 
+  crashme() {
+    if [[ $1 =~ ^http:* ]]
+    then
+      url=${1#*=}
+    fi
+  }
+  which crashme
+0:Regression test for examining code with regular expression match
+>crashme () {
+>	if [[ $1 =~ ^http:* ]]
+>	then
+>		url=${1#*=} 
+>	fi
+>}
+
 %clean
   # This works around a bug in rm -f in some versions of Cygwin
   chmod 644 unmodish

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: Certain pattern causing shell to crash

[Mikael Magnusson]

On 6 January 2011 20:54, Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
> On Thu, 6 Jan 2011 13:51:35 -0500
> Ricky Zhou <ricky@rzhou.org> wrote:
>> For what it's worth, I did a git bisect, and the segfault was introduced
>> in d234059b1c6493e5eefb6c28aa2b8a021d894d51.  Hopefully this can be of
>> use to somebody more familiar with how this code works.
>
> (Ah, so I need to use
>
> git diff d234059b1c6493e5eefb6c28aa2b8a021d894d51^\!
>
> to look at it.  Obvious.)

fwiw, you could also have said git show d234059b1 without the funny
bit on the end.

-- 
Mikael Magnusson

Re: Certain pattern causing shell to crash

[Phil Pennock]

On 2011-01-06 at 19:54 +0000, Peter Stephenson wrote:
> On Thu, 6 Jan 2011 13:51:35 -0500
> Ricky Zhou <ricky@rzhou.org> wrote:
> > For what it's worth, I did a git bisect, and the segfault was introduced
> > in d234059b1c6493e5eefb6c28aa2b8a021d894d51.  Hopefully this can be of
> > use to somebody more familiar with how this code works.
> 
> (Ah, so I need to use
> 
> git diff d234059b1c6493e5eefb6c28aa2b8a021d894d51^\!
> 
> to look at it.  Obvious.)
> 
> Yes, that narrows it down a lot, thanks.

Oh dear, it was me fixing another problem?  I'm sorry.

So in that change, I was avoiding shoving junk into the parse tree; was
that junk protecting us somehow?   Did my original =~ feature manage
to introduce parallel code/decode bugs and the =~ code bug-fix exposed
the decode bug?

-Phil

Re: Certain pattern causing shell to crash

[Peter Stephenson]

On Fri, 7 Jan 2011 15:35:07 -0500
Phil Pennock <zsh-workers+phil.pennock@spodhuis.org> wrote:
> On 2011-01-06 at 19:54 +0000, Peter Stephenson wrote:
> > On Thu, 6 Jan 2011 13:51:35 -0500
> > Ricky Zhou <ricky@rzhou.org> wrote:
> > > For what it's worth, I did a git bisect, and the segfault was introduced
> > > in d234059b1c6493e5eefb6c28aa2b8a021d894d51.  Hopefully this can be of
> > > use to somebody more familiar with how this code works.
> > 
> > (Ah, so I need to use
> > 
> > git diff d234059b1c6493e5eefb6c28aa2b8a021d894d51^\!
> > 
> > to look at it.  Obvious.)
> > 
> > Yes, that narrows it down a lot, thanks.
> 
> Oh dear, it was me fixing another problem?  I'm sorry.
> 
> So in that change, I was avoiding shoving junk into the parse tree; was
> that junk protecting us somehow?   Did my original =~ feature manage
> to introduce parallel code/decode bugs and the =~ code bug-fix exposed
> the decode bug?

I think what happened is that = and =~ were originally implemented
similarly, then you discovered that wasn't appropriate, but missed one
of the consequences.  It's inevitable that changing the way the wordcode
is structured changes how you need to decode it to turn it back into
text, but actually keeping the two consistent is a bit obscure, so this
isn't the first time this has happened.  The code in text.c is consequent
on what happens elsewhere, not the other way round, so this latest bug
doesn't imply any major structural problem.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/