unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Gergely Czuczy <gergely.czuczy@harmless.hu>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 28308@debbugs.gnu.org, npostavs@users.sourceforge.net
Subject: bug#28308: Build failure on FreeBSD/aarch64
Date: Tue, 12 Sep 2017 17:13:55 +0200	[thread overview]
Message-ID: <a30e2d4e-2711-ba92-c718-626014380704@harmless.hu> (raw)
In-Reply-To: <83efrcq7y2.fsf@gnu.org>

On 2017. 09. 12. 16:59, Eli Zaretskii wrote:
>> Cc: npostavs@users.sourceforge.net, 28308@debbugs.gnu.org
>> From: Gergely Czuczy <gergely.czuczy@harmless.hu>
>> Date: Mon, 11 Sep 2017 22:33:45 +0200
>>
>> It's still in the delete_ttye function, however, 4463 is a call to
>> delete_terminal, and not to xpalloc. It's interesting why's that frame
>> #2, because lldb also returns the same as we can see in the source:
>> (lldb) frame select 3
>> frame #3: 0x0000000000168214
>> bootstrap-emacs`delete_tty(terminal=0x4f67ed32e8e06446) at term.c:4463
>>      4460      before delete_terminal.  */
>>      4461   reset_sys_modes (tty);
>>      4462
>> -> 4463   delete_terminal (terminal);
>>      4464
>>      4465   xfree (tty->name);
>>      4466   xfree (tty->type);
>>
>> However, disassembly gave something interesting:
>> ** 4463   delete_terminal (terminal);
>>      4464
>>
>>       0x16820c <+224>: bl     0xd40b4 ; coordinates_in_window + 5312 at
>> window.c:1274
>>       0x168210 <+228>: bl     0x22e1f8 ; xpalloc + 16084 at alloc.c:992
>>
>> -> 4465   xfree (tty->name);
>>
>> ->  0x168214 <+232>: bl 0x35b294                  ;
>> text_property_stickiness + 628 at textprop.c:1845
>>       0x168218 <+236>: ldurb  w8, [x29, #-0x2c]
>>       0x16821c <+240>: tbz    w8, #0x0, 0x16823c ; <+272> at term.c
>>
>> The pointer is at the xfree call. However, I the disassembly was too
>> long, I couldn't get anything useful out of it.
> Can you step through that code, starting at the delete_tty, stepping
> into the functions, and showing the source lines?  I don't see how the
> code you are showing could possibly be correct.
>
> Thanks.
Here it is:

root@build-pine64:/usr/ports/editors/emacs-devel/work/emacs-f44184f/lisp# 
EMACSLOADPATH= lldb -- '../src/bootstrap-emacs' -batch l-no-site-file 
--no-site-lisp --eval '(setq load-prefer-newer t)' -f batch-byte-compile 
emacs-lisp/macroexp.eleval '(set
(lldb) target create "../src/bootstrap-emacs"
Current executable set to '../src/bootstrap-emacs' (aarch64).
(lldb) settings set -- target.run-args  "-batch" "--no-site-file" 
"--no-site-lisp" "--eval" "(setq load-prefer-newer t)" "-f" 
"batch-byte-compile" "emacs-lisp/macroexp.el"
(lldb) r
Process 3150 launching
Process 3150 launched: '../src/bootstrap-emacs' (aarch64)
Process 3150 stopped
* thread #1, name = 'bootstrap-emacs', stop reason = signal SIGSEGV: 
invalid address (fault address: 0x41b17978)
     frame #0: 0x0000000000228460 
bootstrap-emacs`xnrealloc(pa=0x0000000000000000, nitems=0, 
item_size=1102150015) at alloc.c:939
    936  {
    937    eassert (0 <= nitems && 0 < item_size);
    938    ptrdiff_t nbytes;
-> 939    if (INT_MULTIPLY_WRAPV (nitems, item_size, &nbytes) || 
SIZE_MAX < nbytes)
    940      memory_full (SIZE_MAX);
    941    return xrealloc (pa, nbytes);
    942  }
(lldb) thread list
Process 3150 stopped
* thread #1: tid = 101190, 0x0000000000228460 
bootstrap-emacs`xnrealloc(pa=0x0000000000000000, nitems=0, 
item_size=1102150015) at alloc.c:939, name = 'bootstrap-emacs', stop 
reason = signal SIGSEGV: invalid address (fault address: 0x41b17978)
(lldb) bt
* thread #1, name = 'bootstrap-emacs', stop reason = signal SIGSEGV: 
invalid address (fault address: 0x41b17978)
   * frame #0: 0x0000000000228460 
bootstrap-emacs`xnrealloc(pa=0x0000000000000000, nitems=0, 
item_size=1102150015) at alloc.c:939
     frame #1: 0x0000000000228204 
bootstrap-emacs`xnrealloc(pa=0x000000000019ae38, nitems=42949672960, 
item_size=281474976703880) at alloc.c:939
     frame #2: 0x000000000022e208 
bootstrap-emacs`xpalloc(pa=0x0000000000000000, 
nitems=0x0000000041b1797f, nitems_incr_min=1683000, 
nitems_max=42949672960, item_size=281474976703880) at alloc.c:0
     frame #3: 0x0000000000168214 
bootstrap-emacs`delete_tty(terminal=0xf3ce82d91358dca6) at term.c:4463
     frame #4: 0x0000000000040190 bootstrap-emacs`__start + 376
     frame #5: 0x0000000040390018 ld-elf.so.1`.rtld_start at rtld_start.S:41
(lldb) frame select 1
frame #1: 0x0000000000228204 
bootstrap-emacs`xnrealloc(pa=0x000000000019ae38, nitems=42949672960, 
item_size=281474976703880) at alloc.c:939
    936  {
    937    eassert (0 <= nitems && 0 < item_size);
    938    ptrdiff_t nbytes;
-> 939    if (INT_MULTIPLY_WRAPV (nitems, item_size, &nbytes) || 
SIZE_MAX < nbytes)
    940      memory_full (SIZE_MAX);
    941    return xrealloc (pa, nbytes);
    942  }
(lldb) frame select 2
frame #2: 0x000000000022e208 
bootstrap-emacs`xpalloc(pa=0x0000000000000000, 
nitems=0x0000000041b1797f, nitems_incr_min=1683000, 
nitems_max=42949672960, item_size=281474976703880) at alloc.c:0
    1    /* Storage allocation and gc for GNU Emacs Lisp interpreter.
    2
    3    Copyright (C) 1985-1986, 1988, 1993-1995, 1997-2017 Free Software
    4    Foundation, Inc.
    5
    6    This file is part of GNU Emacs.
    7
(lldb) frame select 3
frame #3: 0x0000000000168214 
bootstrap-emacs`delete_tty(terminal=0xf3ce82d91358dca6) at term.c:4463
    4460      before delete_terminal.  */
    4461   reset_sys_modes (tty);
    4462
-> 4463   delete_terminal (terminal);
    4464
    4465   xfree (tty->name);
    4466   xfree (tty->type);
(lldb) frame select 4
frame #4: 0x0000000000040190 bootstrap-emacs`__start + 376
bootstrap-emacs`__start:
     0x40190 <+376>: bl     0x37e7d0 ; symbol stub for: exit

bootstrap-emacs`finalizer:
     0x40194 <+0>:   stp    x20, x19, [sp, #-0x20]!
     0x40198 <+4>:   adrp   x19, 1632
     0x4019c <+8>:   adrp   x8, 1632
(lldb) frame select 5
frame #5: 0x0000000040390018 ld-elf.so.1`.rtld_start at rtld_start.S:41

In the meantime I'm preparing a qemu aarch64 VM, where this is 
reproduced, and ready to analyze it. It's in progress, however emulating 
aarch64 is not a speed champion on amd64.






  reply	other threads:[~2017-09-12 15:13 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-31 16:34 bug#28308: Build failure on FreeBSD/aarch64 Gergely Czuczy
2017-08-31 16:47 ` Glenn Morris
2017-08-31 17:02   ` Gergely Czuczy
2017-09-02  3:13 ` npostavs
2017-09-04 12:32   ` Gergely Czuczy
2017-09-08 23:52     ` npostavs
2017-09-09  5:01       ` Gergely Czuczy
2017-09-09  7:07         ` Eli Zaretskii
2017-09-11  6:07           ` npostavs
2017-09-11  7:26             ` Gergely Czuczy
2017-09-11 14:45               ` Eli Zaretskii
2017-09-11 15:10                 ` Gergely Czuczy
2017-09-11 15:31                   ` Eli Zaretskii
2017-09-11 17:12                     ` Gergely Czuczy
2017-09-11 17:17                       ` Eli Zaretskii
2017-09-11 19:57                         ` Gergely Czuczy
2017-09-11 20:33                         ` Gergely Czuczy
2017-09-12  5:22                           ` npostavs
2017-09-12  5:57                             ` Gergely Czuczy
2017-09-12 14:59                           ` Eli Zaretskii
2017-09-12 15:13                             ` Gergely Czuczy [this message]
2017-09-20  5:51                         ` Gergely Czuczy
2017-09-20 19:29                           ` Noam Postavsky
2017-10-19 23:39                             ` Noam Postavsky
2017-10-20  7:07                               ` Eli Zaretskii
2017-10-24 18:43                                 ` Noam Postavsky
2017-10-31 17:31                                   ` Noam Postavsky
2017-10-31 20:21                                     ` Eli Zaretskii
2017-11-01 16:14                                     ` Gergely Czuczy
2017-11-01 16:51                                       ` Noam Postavsky
2017-11-01 18:27                                         ` Gergely Czuczy
2017-11-01 18:52                                           ` Noam Postavsky
2017-11-02 21:03                                     ` Gergely Czuczy
2017-11-04 23:14                                       ` Noam Postavsky
2017-11-05 18:10                                         ` Gergely Czuczy
2017-11-06 23:14                                           ` Noam Postavsky
2017-09-14  0:51 ` Paul Eggert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a30e2d4e-2711-ba92-c718-626014380704@harmless.hu \
    --to=gergely.czuczy@harmless.hu \
    --cc=28308@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=npostavs@users.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).