From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29709 invoked by alias); 27 Jul 2013 20:33:52 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 31590 Received: (qmail 14489 invoked from network); 27 Jul 2013 20:33:37 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at brasslantern.com does not designate permitted sender hosts) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=QqoTbOjH4HghomZT8D2m5tZJR15e8cuzesfbUMgE2JI=; b=bIN4o8fjzHyApxaiRNKK3UxHVKADqzD5yRcJbSH2FhK+kDWTtirbMZGR6q7+Y2EYaa K0S0qXMYFVRtrI0c0NDbpBcUyz6pL6anlA0PB/PM5qWaD8t9+tplwR0tnwSxbOPI67XC 78NmCcqwsVSr/zV1606KBIg+ARKNVbAiqzmyy0udZ2Rz6A5daJsf/tli39P1U4fXGnPw 9vg+etDNCVh7xOXlcLdzILz2xhh/gTjoczVg6hnQ0gwFNo75H+aJiZgt2pbKf/sgw7L8 qtyunsxi4ky+NhADbUB3NAF71odEO86WDg/CKT8QhSg3g7LBWZdedSqXNWuXCVOY84c7 CijQ== MIME-Version: 1.0 X-Received: by 10.152.28.6 with SMTP id x6mr23557862lag.41.1374957206696; Sat, 27 Jul 2013 13:33:26 -0700 (PDT) In-Reply-To: <20130726102052.GB1752@goeswhere.com> References: <20130726102052.GB1752@goeswhere.com> Date: Sat, 27 Jul 2013 13:33:26 -0700 Message-ID: Subject: Re: Segfault completing: for f in 1; do <[here] x From: Bart Schaefer To: Zsh hackers list Content-Type: multipart/alternative; boundary=089e0160ba40e3012004e2842b28 X-Gm-Message-State: ALoCoQkilBEgOtofwwm+0H2/4LuZ2dx0gfiTp/zF7qgCgQiEgCnDGRqwW0T016+8XloGYsnxKIl5 --089e0160ba40e3012004e2842b28 Content-Type: text/plain; charset=ISO-8859-1 (This may come through twice, I'm having some DNS problems so one copy is stuck in the sendmail queue.) On Fri, Jul 26, 2013 at 3:20 AM, wrote: > > I'm getting a segfault when trying to complete after the "<" in: > for f in 1; do < x > Hmm. Line numbers below refer to zle_tricky.c. Both of the cases you backtraced indicate that get_comp_string() has run off the end of [it's internal copy of] the input line. Stepping through in the debugger, it correctly determines that it's in a "for" loop, which is recorded by the mysteriously-named variable "ins", but then that information is discarded at line 1243 when the ";" is found. This in turn means that "do" is not treated as a keyword on the next pass around the loop at line 1224. Thus it is believed the command word has been found, and tt0 is assigned NULLTOK. Next the "<" token is found, but because "do" appeared to be the command word, redirpos is NOT incremented at line 1216. It's actually a bit more complicated than this because wordpos is incremented at line 1353 even when the word is a separator, so I think the test on 1215 is valid only for very simple command lines. In any case the NULLTOK branch at 1257 is now taken, which is correctly identifying that the word under the cursor has been reached, which happens to be the dummy string "x" that was added at line 1136 (or in the second example, the word "pom"). The dummy x is removed and the result is recorded as the word to be completed (either the empty string or "pom"). Here's where things get weird. Because the end of the input line has not yet been reached, the loop starts again even though the word to be completed has been found. (This isn't by itself wrong, we have to fill in the whole $words array even though CURRENT is going to point into the middle of it.) The two examples diverge at this point because of the number of words that follow the "<". Because the relative positions of the command word and the redirection have become confused ("do" not recognized), the code ends up arriving in the "Check if we are in an array subscript" block at line 1476. In the first example no value has ever been assigned to the local variable "s", so itype_end() derefs a null pointer and segfaults. In the second example two more passes are done to reach the word "-O". At this point, zlemetacs_qsub == 36 and wb == 33, so the "for" loop at line 1485 spins forever trying to step forward three characters in a two-character string. The infinite loop could be fixed by breaking when *tt == 0 in the loop condition or when nclen == 0 at line 1495, and probably that should get fixed just for sanity, but it doesn't help with the underlying problem. That's as far as I've had time to get today. If someone else wants to pick up from here, have at it. --089e0160ba40e3012004e2842b28--