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: Mon, 11 Sep 2017 22:33:45 +0200 [thread overview]
Message-ID: <90dd40c6-6837-aac5-fda6-f637bcfcc15b@harmless.hu> (raw)
In-Reply-To: <83bmmhrw84.fsf@gnu.org>
On 2017. 09. 11. 19:17, Eli Zaretskii wrote:
>> Cc: npostavs@users.sourceforge.net, 28308@debbugs.gnu.org
>> From: Gergely Czuczy <gergely.czuczy@harmless.hu>
>> Date: Mon, 11 Sep 2017 19:12:12 +0200
>>
>>> That's a call to delete_terminal, which doesn't appear in your
>>> backtrace, and doesn't call xpalloc, either. So thanks, but I'm still
>>> confused. Are you sure this is an unoptimized build? Is it possible
>>> that we are looking at LLDB bug?
>> It's the lldb debug, right. And I'm sure it's an unoptimized build, I've
>> went back and checked the build flags:
>> cc -Demacs -I. -I. -I../lib -I../lib
>> -I/usr/local/include/libxml2 -MMD -MF deps/.d -MP
>> -Wno-switch -Wno-pointer-sign -Wno-string-plus-int
>> -Wno-unknown-attributes -Wno-initializer-overrides
>> -Wno-tautological-compare
>> -Wno-tautological-constant-out-of-range-compare -O0 -g
>> -fno-strict-aliasing -Wl,-znocombreloc (...)
>>
>> If that helps, I can create a qemu VM with this fbsd build, and give you
>> the image.
> Would it be possible for you to install GDB, and then repeat the same
> experiment under GDB?
It was relatively fast, however it appears to be the same:
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.elk/emacs-f4
(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 98283 launching
Process 98283 launched: '../src/bootstrap-emacs' (aarch64)
Process 98283 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) 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=281474976703896) at alloc.c:939
frame #2: 0x000000000022e208
bootstrap-emacs`xpalloc(pa=0x0000000000000000,
nitems=0x0000000041b1797f, nitems_incr_min=1683000,
nitems_max=42949672960, item_size=281474976703896) at alloc.c:0
frame #3: 0x0000000000168214
bootstrap-emacs`delete_tty(terminal=0x4f67ed32e8e06446) 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)
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.
And here's the core file: http://czg.harmless.hu/tmp/bootstrap-emacs.core.gz
You can download and analyze it with lldb, it was in the root of the
source tree, if that matters. I guess that way you can just open it with
lldb yourself, and dig into it.
next prev parent reply other threads:[~2017-09-11 20:33 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 [this message]
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
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=90dd40c6-6837-aac5-fda6-f637bcfcc15b@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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.