From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) by sourceware.org (Postfix) with ESMTPS id 6CDC83858402 for ; Mon, 13 Sep 2021 21:04:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6CDC83858402 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=SystematicSw.ab.ca Authentication-Results: sourceware.org; spf=none smtp.mailfrom=systematicsw.ab.ca Received: from shw-obgw-4002a.ext.cloudfilter.net ([10.228.9.250]) by cmsmtp with ESMTP id PlmUmKUuWczbLPt7smkE5k; Mon, 13 Sep 2021 21:04:28 +0000 Received: from [192.168.1.105] ([68.147.0.90]) by cmsmtp with ESMTP id Pt7smkDSNxCNkPt7smmwuN; Mon, 13 Sep 2021 21:04:28 +0000 X-Authority-Analysis: v=2.4 cv=Xe/qcK15 c=1 sm=1 tr=0 ts=613fbcdc a=T+ovY1NZ+FAi/xYICV7Bgg==:117 a=T+ovY1NZ+FAi/xYICV7Bgg==:17 a=IkcTkHD0fZMA:10 a=E8FxouwvlsCS3ahzTVUA:9 a=QEXdDO2ut3YA:10 Reply-To: cygwin-apps@cygwin.com To: cygwin-apps@cygwin.com References: <7ac49a0d-14c0-96b6-7ae3-d57a891eb55a@SystematicSw.ab.ca> <87lf41oajk.fsf@Rainer.invalid> <1e8575d4-d652-0983-c199-3d224256417c@SystematicSw.ab.ca> <87fsu8cpoj.fsf@Rainer.invalid> From: Brian Inglis Organization: Systematic Software Subject: Re: bison cygport test segv under Cygwin 64 at fatal-signal.c:318 Message-ID: <677dddc0-b18a-c1e4-eb59-e604a3d03b40@SystematicSw.ab.ca> Date: Mon, 13 Sep 2021 15:04:27 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <87fsu8cpoj.fsf@Rainer.invalid> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-CA Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4xfNEG6CRkDGgzxvXn69SOtpNeawC+m216zyGLpVdDFreMfwMhA0GzuaAHlPvdXO28fuvCAn8k5TqsMcRhYSDx/K0Dre6ZDMyEEP4bUPfIJdrO6+d0TU23 KxrGIdmHHo7PvJ6OtDqV0UTNX0e8y4moT7dLFI653YtfU4K2npoMS1TDa7PH9zjDgv44sQuDLPeT0q6+n6ATzBYZtgJ267Ohu4U= X-Spam-Status: No, score=-1161.6 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, KAM_NUMSUBJECT, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: cygwin-apps@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin package maintainer discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2021 21:04:31 -0000 On 2021-09-13 12:10, Achim Gratz wrote: > Brian Inglis writes: >>>> Thread 1 "bison" hit Breakpoint 10, block_fatal_signals () at >>>> /usr/src/debug/bison-3.8.1-1/lib/fatal-signal.c:318 >>>> 318 if (mt) gl_lock_lock (fatal_signals_block_lock); >>>> Continuing. >>>> >>>> Thread 1 "bison" received signal SIGSEGV, Segmentation fault. >>>> 0x0000000100000000 in ?? () >>>> #0 0x0000000100000000 in ?? () >>>> Backtrace stopped: previous frame identical to this frame (corrupt stack?) >> >>> Well, since you already know where the SEGV hits: what is the diff to the >>> working 3.7.6 version? The sources for this get generated, so you need >>> to check the build directories. >> >> Worse, as neither gnulib/ nor lib/ sources are included in the repo, >> except for their .gitignore files, and only /lib in the tarball, I can >> only compare the 1.5MB of diffs on 36000 lines, which also span >> internal versions 3.7.90 and 3.7.91, and hope that I can spot >> something relevant! > > You only need to look at lib/fatal-signal.c and how that differs > between the working and non-working build as a first step. If there's > nothing obvious there, you need to look at the call chain that's > involved in the crash, of course. There no changes near there, only later ensuring the lock is released on malloc failure, but I am surprised that something so obvious still needs dealt with! Thanks for the hints and tips, I really appreciate and need them, as I have had little experience dealing with GNU packages complex infrastructure except where issues are obvious, and the resulting lack of traceability. I think I need to dig out the build commands and generate that module as -E expanded source, maybe the whole tree, as it still looks as if the gnulib macros expanding pthread_in_use to glthread_in_use manage to get that defined elsewhere as int 1! -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]