From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#47067: 28.0.50; [feature/native-comp] Crash while scrolling through dispnew.c Date: Fri, 12 Mar 2021 16:08:33 +0000 Message-ID: References: <83sg52lykn.fsf@gnu.org> <83mtv8lrmf.fsf@gnu.org> <83czw4lelg.fsf@gnu.org> <835z1wl6ao.fsf@gnu.org> Reply-To: Andrea Corallo Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18751"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 47067@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Mar 12 17:09:20 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lKkLn-0004iR-3t for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 12 Mar 2021 17:09:19 +0100 Original-Received: from localhost ([::1]:58156 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lKkLm-0002p8-3z for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 12 Mar 2021 11:09:18 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56852) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lKkLW-0001xf-3C for bug-gnu-emacs@gnu.org; Fri, 12 Mar 2021 11:09:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46623) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lKkLV-0006wG-S1 for bug-gnu-emacs@gnu.org; Fri, 12 Mar 2021 11:09:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lKkLV-0007iu-MH for bug-gnu-emacs@gnu.org; Fri, 12 Mar 2021 11:09:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 Mar 2021 16:09:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 47067 X-GNU-PR-Package: emacs Original-Received: via spool by 47067-submit@debbugs.gnu.org id=B47067.161556532029658 (code B ref 47067); Fri, 12 Mar 2021 16:09:01 +0000 Original-Received: (at 47067) by debbugs.gnu.org; 12 Mar 2021 16:08:40 +0000 Original-Received: from localhost ([127.0.0.1]:58169 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lKkL9-0007iI-NY for submit@debbugs.gnu.org; Fri, 12 Mar 2021 11:08:40 -0500 Original-Received: from mx.sdf.org ([205.166.94.24]:55129) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lKkL6-0007i8-OJ for 47067@debbugs.gnu.org; Fri, 12 Mar 2021 11:08:38 -0500 Original-Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 12CG8XDv018755 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Fri, 12 Mar 2021 16:08:34 GMT In-Reply-To: <835z1wl6ao.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 12 Mar 2021 17:50:55 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:202170 Archived-At: Eli Zaretskii writes: >> From: Andrea Corallo >> Cc: 47067@debbugs.gnu.org >> Date: Fri, 12 Mar 2021 15:27:30 +0000 >> >> Generally speaking the first step is to identify the function that is >> responsible for the bug, this is often on the top of the back-trace but >> not necessarily. In the unfortunate case I typically proceed by >> bisection. > > In my case the top of the stack looks like this: > > #0 0x01236788 in arithcompare_driver (nargs=2, args=0x28, > comparison=ARITH_LESS) at data.c:2673 > #1 0x01236860 in Flss (nargs=2, args=0x28) at data.c:2691 > #2 0x0a872285 in ?? () > #3 0x01261898 in funcall_lambda (fun=XIL(0xa00000000a0bf230), nargs=5, > arg_vector=0x826a08) at eval.c:3292 > #4 0x012601ed in Ffuncall (nargs=6, args=0x826a00) at eval.c:3013 > #5 0x0a8e0dbf in ?? () > #6 0x012601ed in Ffuncall (nargs=1, args=0x826bd8) at eval.c:3013 > #7 0x0a8ce041 in ?? () > #8 0x01261898 in funcall_lambda (fun=XIL(0xa0000000069f2a50), nargs=1, > arg_vector=0x826db8) at eval.c:3292 > #9 0x012601ed in Ffuncall (nargs=2, args=0x826db0) at eval.c:3013 > #10 0x70895b36 in F632d666f6e742d6c6f636b2d6375742d6f66662d6465636c617261746f7273_c_font_lock_cut_off_declarators_0 () > from d:\usr\eli\.emacs.d\eln-cache\28.0.50-7d88f6c1\cc-fonts-d7d8a7f5-b7c359cd.eln > #11 0x01261898 in funcall_lambda (fun=XIL(0xa0000000079249a0), nargs=1, > arg_vector=0x827050) at eval.c:3292 > #12 0x012601ed in Ffuncall (nargs=2, args=0x827048) at eval.c:3013 > > And the corresponding Lisp backtrace: > > "c-beginning-of-statement-1" (0x826a08) > "c-just-after-func-arglist-p" (0x826be0) > "c-back-over-member-initializers" (0x826db8) > "c-font-lock-cut-off-declarators" (0x827050) > "font-lock-fontify-keywords-region" (0x8273a8) > "font-lock-default-fontify-region" (0x8276b8) > > (Don't ask me why "<", i.e. Flss, doesn't appear in the Lisp > backtrace: something strange happens with backtraces here, as I will > describe in another message. I think the "??" things in the backtrace > are related.) > > How do I go about finding the function that's responsible for the > problem given the above? The problem is 100% reproducible for me. One easy option is to evaluate say `c-beginning-of-statement-1' (as first defendant) and see if afterwards it still crashes. Same one can load entire files to exclude entirely their content from the equation. >> Here the problem is that being not reproducible we are stuck in the >> first steps, reproducibility is tipically a pre for this kind of >> analysis. But again if it's a miscompilation it *must* be reproducible >> because code is not morphing so probably we are not reproducing it >> precisely? > > Here's another reproducer: > > emacs -Q > C-x C-f src/dispnew.c > C-s sleep-for > > I usually get a SIGSEGV before I even type the whole of "sleep-for". Can't reproduce this either :( That's odd. > Do you have all of the cc-*.el files natively-compiled? I do. Looks so. Thanks Andrea