From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Richard Copley Newsgroups: gmane.emacs.bugs Subject: bug#37575: 27.0.50; Segfault on redisplay Date: Thu, 3 Oct 2019 19:38:04 +0100 Message-ID: References: <83r23v8am4.fsf@gnu.org> <83lfu17oeb.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000075fe82059405e459" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="89658"; mail-complaints-to="usenet@blaine.gmane.org" To: Eli Zaretskii , 37575@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Oct 03 20:39:33 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iG60i-000NDp-QN for geb-bug-gnu-emacs@m.gmane.org; Thu, 03 Oct 2019 20:39:32 +0200 Original-Received: from localhost ([::1]:39324 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iG60h-0008Fs-67 for geb-bug-gnu-emacs@m.gmane.org; Thu, 03 Oct 2019 14:39:31 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43921) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iG60J-0008FR-FA for bug-gnu-emacs@gnu.org; Thu, 03 Oct 2019 14:39:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iG60F-0000bM-Nc for bug-gnu-emacs@gnu.org; Thu, 03 Oct 2019 14:39:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60564) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iG60F-0000aq-E6 for bug-gnu-emacs@gnu.org; Thu, 03 Oct 2019 14:39:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iG60D-0007lh-Ky for bug-gnu-emacs@gnu.org; Thu, 03 Oct 2019 14:39:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Richard Copley Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 03 Oct 2019 18:39:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37575 X-GNU-PR-Package: emacs Original-Received: via spool by 37575-submit@debbugs.gnu.org id=B37575.157012792029829 (code B ref 37575); Thu, 03 Oct 2019 18:39:01 +0000 Original-Received: (at 37575) by debbugs.gnu.org; 3 Oct 2019 18:38:40 +0000 Original-Received: from localhost ([127.0.0.1]:41152 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iG5zr-0007l3-JB for submit@debbugs.gnu.org; Thu, 03 Oct 2019 14:38:39 -0400 Original-Received: from mail-oi1-f170.google.com ([209.85.167.170]:42950) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iG5zq-0007kp-3G for 37575@debbugs.gnu.org; Thu, 03 Oct 2019 14:38:38 -0400 Original-Received: by mail-oi1-f170.google.com with SMTP id i185so3525190oif.9 for <37575@debbugs.gnu.org>; Thu, 03 Oct 2019 11:38:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=84xAF6T87tVewN5rv/BkJxssJpdUa/7fnD2eMxHOsqk=; b=oc17x9gfq5oFwu4ZLxCAolyMwtTBs5CgnHmzS6qCJVNqcX5DV1+V7q9UyOamWdonNM gw8oLfesBM6gKxxhVY0Sr4h7aR+wgR6edI9TCZVlIK55f8JTdLoi+qGATGkSRrZBvbnb ovPKWlE1BUIVvoSt05wrv120bz6587ihnUsMob242V1AmcfFITvn8QFYhAMS/fg88z5g VwKFgA2dVtRewy4jiJId9gmnLSgCG6vuiEdH2uTLd329aN8BPmmBYB60a9x9fOAhaW47 arjPSOpc+FBNKz2v3H7ciOwbopRfh5mlLShMPQXGOODRhxNDs0+zp5kO3KMpXsuCYBgL oQhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=84xAF6T87tVewN5rv/BkJxssJpdUa/7fnD2eMxHOsqk=; b=LeIWRg09bwzk3fr6uWptIbGsLjdObHmj3f97BlHIf2mq48SdSjjrmgKpYfhPkFuOsf fVep9PEzSo9qPl2RtK4O6ke9fXF6bpnMd18P7gCBd6dIwmc/FEBULVcpEXX/XPK2PWLZ MNN8ANAarWuiW/xMvp8pSbpbWMk3IWkVqDG8lrMZZlinL+ubOWMM5Mny230HpZ2MtVP/ 923Q1XcQPqGUJ/aS4ESEppvZIH0iD2WFKj3kAoKJtlRGdjTwD6KUBxC4afBAeiXuhRnr CQn1FxBGukXS+S4texCjUb5LYbD77sO/J84rgV9R/FBth82w6/shsoTcxP2k8nnvXrF1 ErDg== X-Gm-Message-State: APjAAAUXB55yFhyl9szsCG93iq+kGFoZXf90mxNmuItzyz2yN844Dv12 mTmUUoqJKpz10Q1ZP/vq5VVu7ImOE9Ddgma9h+o= X-Google-Smtp-Source: APXvYqxr7kf99rjjgGiFOGAID5L+P2pg7a6TKlhW8c7qfnPpYi+cqujjet7ZtnK6kQga5dLgkv8qnK7GLg4QswEl9ZY= X-Received: by 2002:aca:c5cb:: with SMTP id v194mr3795414oif.106.1570127912237; Thu, 03 Oct 2019 11:38:32 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:168272 Archived-At: --00000000000075fe82059405e459 Content-Type: text/plain; charset="UTF-8" On Thu, 3 Oct 2019 at 19:04, Richard Copley wrote: > On Thu, 3 Oct 2019 at 18:03, Eli Zaretskii wrote: > > chkstk is the function that probes the stack for whether it crossed >> the guard page at the end of the stack (a.k.a "stack overflow"). It >> is invoked internally by alloca (except that there's no alloca >> anywhere in sight near the code that allegedly blew up), and when >> allocating stack-based data. > > > The chktsk call is in ntdll!RtlRaiseException. > >From "objdump -Mintel -d -C -l c:\windows\system32\ntdll.dll": 0x0000000180051f77 : callq 0x1800a34c0 [...] 0x00000001800520a4 : callq 0x1800a35d0 However, note that it is chkstk that >> ended up in the exception handler, which is at least weird. IME, this >> more often than not happens when the code longjmp's on the wrong >> stack, which is why I asked about other threads. >> > > We're nowhere near any longjmp. > > > And given that chkstk is a leaf function, how do you deduce anything >> from its presence, except that there is >> > some flaw in GDB's backtrace generation or in its debug information for >> ntdll.dll? >> >> I deduce that because there should be no reason for chkstk itself to >> crash. >> > It's the debug information that is incorrect. In the ntdll.dll on my system, chkstk itself is 77 bytes long. (As you would expect, this function's control flow is extremely simple to follow.) But 3392 bytes, containing several blocks of code which are not reached from chkstk, are attributed to chkstk in the debug information. None of those code blocks crashed. One of them invoked the exception handler. This is a straightforward backtrace, modulo the deficiencies that an experienced low-level programmer learns to expect. It says that dereferencing d raised an access violation. --00000000000075fe82059405e459 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, 3 Oct 2019 at 19:04, Richard Copley <rcopley@gmail.com> wrote:
On Thu, 3 Oct 2019 at 18:03, Eli Z= aretskii <eliz@gnu.org= > wrote:

chkstk is the function that probes the stack for whether it crossed
the guard page at the end of the stack (a.k.a "stack overflow").= =C2=A0 It
is invoked internally by alloca (except that there's no alloca
anywhere in sight near the code that allegedly blew up), and when
allocating stack-based data.

The chktsk cal= l is in=20 ntdll!RtlRaiseException.

= >From "objdump -Mintel -d -C -l c:\windows\system32\ntdll.dll":

=C2=A0=C2=A0 0x0000000180051f77 <ntdll!RtlRaiseExc= eption+615>: callq =C2=A00x1800a34c0 <ntdll!__chkstk>
[...]
=C2=A0=C2=A0= 0x00000001800520a4 <ntdll!RtlRaiseException+916>: callq =C2=A00x1800= a35d0 <ntdll!__chkstk+272>
=

=C2=A0 However, note that it is chkstk that
ended up in the exception handler, which is at least weird.=C2=A0 IME, this=
more often than not happens when the code longjmp's on the wrong
stack, which is why I asked about other threads.

We're nowhere near any longjmp.
<= br>
> And given that chkstk is a leaf function, how do you deduce anything f= rom its presence, except that there is
> some flaw in GDB's backtrace generation or in its debug informatio= n for ntdll.dll?

I deduce that because there should be no reason for chkstk itself to
crash.

It's the debug information that is incorrect. In the ntdll.dll on = my system, chkstk itself is 77 bytes long. (As you would expect, this funct= ion's control flow is extremely simple to follow.) But 3392 bytes, cont= aining several blocks of code which are not reached from chkstk, are attrib= uted to chkstk in the debug information. None of those code blocks crashed.= One of them invoked the exception handler.

= This is a straightforward backtrace, modulo the deficiencies that an expe= rienced low-level programmer learns to expect.=C2=A0 It says that dereferen= cing d raised an access violation.

--00000000000075fe82059405e459--