From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11529 invoked by alias); 3 Jul 2015 11:35: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: 35672 Received: (qmail 199 invoked from network); 3 Jul 2015 11:35:48 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS autolearn=ham autolearn_force=no version=3.4.0 X-AuditID: cbfec7f4-f79c56d0000012ee-b9-5596738e153c Date: Fri, 03 Jul 2015 12:35:40 +0100 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: Complicated segfault regression Message-id: <20150703123540.6266a481@pwslap01u.europe.root.pri> In-reply-to: <5595AEF8.3000508@inlv.org> References: <5595AEF8.3000508@inlv.org> Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsVy+t/xy7p9xdNCDV4vUbU42PyQyYHRY9XB D0wBjFFcNimpOZllqUX6dglcGUdmPGMp6OKruHfEoYFxB1cXIyeHhICJxPQJl5ghbDGJC/fW s3UxcnEICSxllFh0/yw7hDODSeLCqwdQzlZGifWT17CBtLAIqErsW3qKBcRmEzCUmLppNiOI LSIgLnF27XmwuLCAjsSr/fPAVvAK2Esc3/cFLM4poCGx8up6sLiQgLrEqu7tTCA2v4C+xNW/ n5ggTrKXmHnlDCNEr6DEj8n3wHqZBbQkNm9rYoWw5SU2r3kLN+fG3d3sExiFZiFpmYWkZRaS lgWMzKsYRVNLkwuKk9JzDfWKE3OLS/PS9ZLzczcxQoL2yw7GxcesDjEKcDAq8fBeOD01VIg1 say4MvcQowQHs5II7/PgaaFCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeefueh8iJJCeWJKanZpa kFoEk2Xi4JRqYGTwlkx761noY/RUlMU4JXjjjuPLk068qX0b3pN3x0G8/+wbA/eLy9Lzrz35 vith7+7X2vq6T6fbmGytyj7be1BnakiGTTNz1Z4v56wC3p+dVZuy7cT1V+Wek8Vrnk2WT1/g O4uz1HTJP2Fv48lPjJR71tYcljsrqy24uLZ882IWoRvnm1sublBiKc5INNRiLipOBADqQ2gk VgIAAA== On Thu, 2 Jul 2015 23:36:56 +0200 Martijn Dekker wrote: > Just for the hell of it I decided to make zsh 5.0.8 run a GNU > 'configure' script (in sh mode) to see how far it would come with that > incredibly convoluted code. The result was a segfault. So I tried to > find the code that triggers it. Thanks for trying to find this. Based on Bart's clue that the text representation is going wrong at some point to do with "case" , I've narrowed it down a bit further... The following file, crash4.zsh # --- begin crashing code block --- fn() { case $ac_file in *.$ac_ext | *.xcoff | *.tds | *.d | *.pdb | *.xSYM | *.bb \ | *.bbg | *.map | *.inf | *.dSYM | *.o | *.obj ) ;; *.* ) break;; * ) break;; esac } # --- end crashing code block --- when sourced produces the following output for "which fn" (I've used "-x 2", only recently made available): (N.B. there's a long line I haven't attempted to wrap myself...) fn () { case $ac_file in (*.$ac_ext | *.xcoff | *.tds | *.d | *.pdb | *.xSYM | *.bb | *.bbg | *.map | *.inf | *.dSYM | *.o | *.obj) ;; (*.*) break } which has evidently gone haywiere (though this version wasn't particularly crash prone), while the slightly further simplified crash5.zsh: # --- begin crashing code block --- fn() { case $ac_file in *.$ac_ext | *.xcoff | *.tds | *.d | *.pdb | *.xSYM | *.bb ) ;; *.* ) break;; * ) break;; esac } # --- end crashing code block --- doesn't show that effect: fn () { case $ac_file in (*.$ac_ext | *.xcoff | *.tds | *.d | *.pdb | *.xSYM | *.bb) ;; (*.*) break ;; (*) break ;; esac } So the best guess so far is it's do with memory management of the long case with the continuation line. pws