[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#28308: Build failure on FreeBSD/aarch64
From: |
Gergely Czuczy |
Subject: |
bug#28308: Build failure on FreeBSD/aarch64 |
Date: |
Mon, 11 Sep 2017 22:33:45 +0200 |
User-agent: |
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 |
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.
- bug#28308: Build failure on FreeBSD/aarch64, (continued)
- bug#28308: Build failure on FreeBSD/aarch64, Gergely Czuczy, 2017/09/09
- bug#28308: Build failure on FreeBSD/aarch64, Eli Zaretskii, 2017/09/09
- bug#28308: Build failure on FreeBSD/aarch64, npostavs, 2017/09/11
- bug#28308: Build failure on FreeBSD/aarch64, Gergely Czuczy, 2017/09/11
- bug#28308: Build failure on FreeBSD/aarch64, Eli Zaretskii, 2017/09/11
- bug#28308: Build failure on FreeBSD/aarch64, Gergely Czuczy, 2017/09/11
- bug#28308: Build failure on FreeBSD/aarch64, Eli Zaretskii, 2017/09/11
- bug#28308: Build failure on FreeBSD/aarch64, Gergely Czuczy, 2017/09/11
- bug#28308: Build failure on FreeBSD/aarch64, Eli Zaretskii, 2017/09/11
- bug#28308: Build failure on FreeBSD/aarch64, Gergely Czuczy, 2017/09/11
- bug#28308: Build failure on FreeBSD/aarch64,
Gergely Czuczy <=
- bug#28308: Build failure on FreeBSD/aarch64, npostavs, 2017/09/12
- bug#28308: Build failure on FreeBSD/aarch64, Gergely Czuczy, 2017/09/12
- bug#28308: Build failure on FreeBSD/aarch64, Eli Zaretskii, 2017/09/12
- bug#28308: Build failure on FreeBSD/aarch64, Gergely Czuczy, 2017/09/12
- bug#28308: Build failure on FreeBSD/aarch64, Gergely Czuczy, 2017/09/20
- bug#28308: Build failure on FreeBSD/aarch64, Noam Postavsky, 2017/09/20
bug#28308: Build failure on FreeBSD/aarch64, Paul Eggert, 2017/09/13