bug#28308: Build failure on FreeBSD/aarch64

bug#28308: Build failure on FreeBSD/aarch64

[Gergely Czuczy]

[-- Attachment #1: Type: text/plain, Size: 3048 bytes --]

Hello,

Emacs was broken on FreeBSD/aarch64 due to the sbrk issue (it got 
obsoleted on the platform), however the latest git checkout seems to 
build so far, up to a point, where it segfaults. So, the issue with it 
is not sbrk. Here are the build logs:

mv -f emacs bootstrap-emacs
gmake -C ../lisp compile-first EMACS="../src/bootstrap-emacs"
gmake[4]: Entering directory '/usr/ports/editors/emacs-devel/work/emacs-f44184f/lisp'
EMACSLOADPATH= '../src/bootstrap-emacs' -batch --no-site-file --no-site-lisp --eval '(setq load-prefer-newer t)'  -f batch-byte-compile emacs-lisp/macroexp.el
Fatal error 11: Segmentation faultgmake[4]: *** [Makefile:297: emacs-lisp/macroexp.elc] Segmentation fault (core dumped)
gmake[4]: Leaving directory '/usr/ports/editors/emacs-devel/work/emacs-f44184f/lisp'
gmake[3]: *** [Makefile:739: bootstrap-emacs] Error 2
gmake[3]: Leaving directory '/usr/ports/editors/emacs-devel/work/emacs-f44184f/src'
gmake[2]: *** [Makefile:416: src] Error 2
gmake[2]: Leaving directory '/usr/ports/editors/emacs-devel/work/emacs-f44184f'


-emacs.corepine64:/usr/ports/editors/emacs-devel# lldb work/emacs-f44184f/src/bootstrap-emacs -c work/emacs-f44184f/lisp/bootstrap-
(lldb) target create "work/emacs-f44184f/src/bootstrap-emacs" --core "work/emacs-f44184f/lisp/bootstrap-emacs.core"
Core file '/usr/ports/editors/emacs-devel/work/emacs-f44184f/lisp/bootstrap-emacs.core' (aarch64) was loaded.
(lldb) bt
* thread #1, name = 'bootstrap-emacs', stop reason = signal SIGSEGV
   * frame #0: 0x0000000000158584 bootstrap-emacs`oblookup + 120
     frame #1: 0x000000000015843c bootstrap-emacs`intern_1 + 92
     frame #2: 0x00000000000fb0cc bootstrap-emacs`Fdo_auto_save + 220
     frame #3: 0x00000000000c5bd8 bootstrap-emacs`shut_down_emacs + 216
     frame #4: 0x00000000000c5a04 bootstrap-emacs`terminate_due_to_signal + 128
     frame #5: 0x00000000000df574 bootstrap-emacs`deliver_fatal_thread_signal + 128
     frame #6: 0x00000000000e0ec8 bootstrap-emacs`handle_sigsegv + 164
     frame #7: 0x00000000404cfe80 libthr.so.3`handle_signal(actp=0x0000000000539600, sig=11, info=0x0000000000539670, ucp=0x00000000005396c0) at thr_sig.c:244
     frame #8: 0x00000000404cf5a4 libthr.so.3`thr_sighandler(sig=11, info=0x0000000000539670, _ucp=0x00000000005396c0) at thr_sig.c:189
     frame #9: 0x0000fffffffff000
     frame #10: 0x0000000000040190 bootstrap-emacs`__start + 376
     frame #11: 0x00000000401c0018 ld-elf.so.1`.rtld_start at rtld_start.S:41

This was produced on -CURRENT if that matters:
FreeBSD build-pine64.bealak.harmless.hu 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r322723M: Tue Aug 22 07:25:52 CEST 2017     toor@marvin.harmless.hu:/tank/rpi3/crochet/work.pine64vanilla/obj/arm64.aarch64/tank/rpi3/src/sys/GENERIC-NODEBUG  arm64

So, I think this is a different kind of a fault, not related to sbrk, but it pretty much shouldn't do this.

Could you please guys take a look at it?

Best regards,
Gergely

PS: For the record here's the FreeBSD-sude report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221961



[-- Attachment #2: Type: text/html, Size: 4068 bytes --]

bug#28308: Build failure on FreeBSD/aarch64

[Glenn Morris]

This seems to be a duplicate of https://debbugs.gnu.org/24892 ?

bug#28308: Build failure on FreeBSD/aarch64

[Gergely Czuczy]

Could you please explain why does it like a duplicate? From my point of 
view it seems to be a completely different issue.

If you check the build failure, it's not failing because of the lack of 
sbrk(), as I've explicitly mentioned that. It's a different kind of failure.

Another difference is, that report was for emacs-25, and mine is for 
HEAD, the development branch.


On 2017. 08. 31. 18:47, Glenn Morris wrote:
> This seems to be a duplicate of https://debbugs.gnu.org/24892 ?

bug#28308: Build failure on FreeBSD/aarch64

[npostavs]

Gergely Czuczy <gergely.czuczy@harmless.hu> writes:

> EMACSLOADPATH= '../src/bootstrap-emacs' -batch --no-site-file --no-site-lisp --eval '(setq load-prefer-newer t)'  -f batch-byte-compile emacs-lisp/macroexp.el

> (lldb) bt
> * thread #1, name = 'bootstrap-emacs', stop reason = signal SIGSEGV
>   * frame #0: 0x0000000000158584 bootstrap-emacs`oblookup + 120
>     frame #1: 0x000000000015843c bootstrap-emacs`intern_1 + 92
>     frame #2: 0x00000000000fb0cc bootstrap-emacs`Fdo_auto_save + 220
>     frame #3: 0x00000000000c5bd8 bootstrap-emacs`shut_down_emacs + 216
>     frame #4: 0x00000000000c5a04 bootstrap-emacs`terminate_due_to_signal + 128
>     frame #5: 0x00000000000df574 bootstrap-emacs`deliver_fatal_thread_signal + 128
>     frame #6: 0x00000000000e0ec8 bootstrap-emacs`handle_sigsegv + 164
>     frame #7: 0x00000000404cfe80 libthr.so.3`handle_signal(actp=0x0000000000539600, sig=11, info=0x0000000000539670, ucp=0x00000000005396c0) at thr_sig.c:244
>     frame #8: 0x00000000404cf5a4 libthr.so.3`thr_sighandler(sig=11, info=0x0000000000539670, _ucp=0x00000000005396c0) at thr_sig.c:189

This looks like a segfault triggered from the segfault handler.  Can you
run the batch-byte-compile command above under the debugger and catch
the original segfault?

bug#28308: Build failure on FreeBSD/aarch64

[Gergely Czuczy]

On 2017. 09. 02. 5:13, npostavs@users.sourceforge.net wrote:
> Gergely Czuczy <gergely.czuczy@harmless.hu> writes:
>
>> EMACSLOADPATH= '../src/bootstrap-emacs' -batch --no-site-file --no-site-lisp --eval '(setq load-prefer-newer t)'  -f batch-byte-compile emacs-lisp/macroexp.el
>> (lldb) bt
>> * thread #1, name = 'bootstrap-emacs', stop reason = signal SIGSEGV
>>    * frame #0: 0x0000000000158584 bootstrap-emacs`oblookup + 120
>>      frame #1: 0x000000000015843c bootstrap-emacs`intern_1 + 92
>>      frame #2: 0x00000000000fb0cc bootstrap-emacs`Fdo_auto_save + 220
>>      frame #3: 0x00000000000c5bd8 bootstrap-emacs`shut_down_emacs + 216
>>      frame #4: 0x00000000000c5a04 bootstrap-emacs`terminate_due_to_signal + 128
>>      frame #5: 0x00000000000df574 bootstrap-emacs`deliver_fatal_thread_signal + 128
>>      frame #6: 0x00000000000e0ec8 bootstrap-emacs`handle_sigsegv + 164
>>      frame #7: 0x00000000404cfe80 libthr.so.3`handle_signal(actp=0x0000000000539600, sig=11, info=0x0000000000539670, ucp=0x00000000005396c0) at thr_sig.c:244
>>      frame #8: 0x00000000404cf5a4 libthr.so.3`thr_sighandler(sig=11, info=0x0000000000539670, _ucp=0x00000000005396c0) at thr_sig.c:189
> This looks like a segfault triggered from the segfault handler.  Can you
> run the batch-byte-compile command above under the debugger and catch
> the original segfault?
Sure, I can. However, could you please tell me the commands I need to 
run? Unfortunately I don't really have the time to do the legwork, 
however if the commands are given, I can run it and let you know of the 
results.

bug#28308: Build failure on FreeBSD/aarch64

[npostavs]

Gergely Czuczy <gergely.czuczy@harmless.hu> writes:

> On 2017. 09. 02. 5:13, npostavs@users.sourceforge.net wrote:
>> Gergely Czuczy <gergely.czuczy@harmless.hu> writes:
>>
>>> EMACSLOADPATH= '../src/bootstrap-emacs' -batch --no-site-file --no-site-lisp --eval '(setq load-prefer-newer t)'  -f batch-byte-compile emacs-lisp/macroexp.el
>>> (lldb) bt
>> This looks like a segfault triggered from the segfault handler.  Can you
>> run the batch-byte-compile command above under the debugger and catch
>> the original segfault?
> Sure, I can. However, could you please tell me the commands I need to
> run? Unfortunately I don't really have the time to do the legwork,
> however if the commands are given, I can run it and let you know of
> the results.

I think it should be (from the lisp/ directory)

    EMACSLOADPATH= lldb -- '../src/bootstrap-emacs' -batch --no-site-file --no-site-lisp --eval '(setq load-prefer-newer t)'  -f batch-byte-compile emacs-lisp/macroexp.el

then 'bt' when it segfaults.

bug#28308: Build failure on FreeBSD/aarch64

[Gergely Czuczy]

On 2017. 09. 09. 1:52, npostavs@users.sourceforge.net wrote:
> Gergely Czuczy <gergely.czuczy@harmless.hu> writes:
>
>> On 2017. 09. 02. 5:13, npostavs@users.sourceforge.net wrote:
>>> Gergely Czuczy <gergely.czuczy@harmless.hu> writes:
>>>
>>>> EMACSLOADPATH= '../src/bootstrap-emacs' -batch --no-site-file --no-site-lisp --eval '(setq load-prefer-newer t)'  -f batch-byte-compile emacs-lisp/macroexp.el
>>>> (lldb) bt
>>> This looks like a segfault triggered from the segfault handler.  Can you
>>> run the batch-byte-compile command above under the debugger and catch
>>> the original segfault?
>> Sure, I can. However, could you please tell me the commands I need to
>> run? Unfortunately I don't really have the time to do the legwork,
>> however if the commands are given, I can run it and let you know of
>> the results.
> I think it should be (from the lisp/ directory)
>
>      EMACSLOADPATH= lldb -- '../src/bootstrap-emacs' -batch --no-site-file --no-site-lisp --eval '(setq load-prefer-newer t)'  -f batch-byte-compile emacs-lisp/macroexp.el
>
> then 'bt' when it segfaults.
Thanks, here you go:
root@build-pine64:/usr/ports/editors/emacs-devel# cd 
/usr/ports/editors/emacs-devel/work/emacs-f44184f/lisp
root@build-pine64:/usr/ports/editors/emacs-devel/work/emacs-f44184f/lisp# 
EMACSLOADPATH= lldb -- '../src/bootstrap-emacs' -batch --no-site-file 
--no-site-lisp --eval '(setq load-prefer-newer t)' -f batch-byte-compile 
emacs-lisp/macroexp.el
(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) bt
error: invalid process
(lldb) r
Process 63555 launching
Process 63555 launched: '../src/bootstrap-emacs' (aarch64)
Process 63555 stopped
* thread #1, name = 'bootstrap-emacs', stop reason = signal SIGSEGV: 
invalid address (fault address: 0x4192bd70)
     frame #0: 0x000000000011e8c0 bootstrap-emacs`re_match_2_internal + 7556
bootstrap-emacs`re_match_2_internal:
->  0x11e8c0 <+7556>: str    xzr, [x9]
     0x11e8c4 <+7560>: adrp   x8, 1091
     0x11e8c8 <+7564>: ldr    x10, [x8, #0x910]
     0x11e8cc <+7568>: adrp   x11, 1077
(lldb) bt
* thread #1, name = 'bootstrap-emacs', stop reason = signal SIGSEGV: 
invalid address (fault address: 0x4192bd70)
   * frame #0: 0x000000000011e8c0 bootstrap-emacs`re_match_2_internal + 7556
     frame #1: 0x0000000000040190 bootstrap-emacs`__start + 376
     frame #2: 0x00000000401c0018 ld-elf.so.1`.rtld_start at rtld_start.S:41
(lldb)


And here's one with a debug build(-g):
root@build-pine64:/usr/ports/editors/emacs-devel# cd 
/usr/ports/editors/emacs-devel/work/emacs-f44184f/lisp
root@build-pine64:/usr/ports/editors/emacs-devel/work/emacs-f44184f/lisp# 
EMACSLOADPATH= lldb -- '../src/bootstrap-emacs' -batch --no-site-file 
--no-site-lisp --eval '(setq load-prefer-newer t)' -f batch-byte-compile 
emacs-lisp/macroexp.el
(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 69906 launching
Process 69906 launched: '../src/bootstrap-emacs' (aarch64)
Process 69906 stopped
* thread #1, name = 'bootstrap-emacs', stop reason = signal SIGSEGV: 
invalid address (fault address: 0x41aef578)
     frame #0: 0x0000000000228460 
bootstrap-emacs`xnrealloc(pa=0x0000000000000000, nitems=0, 
item_size=1101985151) 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: 0x41aef578)
   * frame #0: 0x0000000000228460 
bootstrap-emacs`xnrealloc(pa=0x0000000000000000, nitems=0, 
item_size=1101985151) 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=0x0000000041aef57f, nitems_incr_min=1683000, 
nitems_max=42949672960, item_size=281474976703896) at alloc.c:0
     frame #3: 0x0000000000168214 
bootstrap-emacs`delete_tty(terminal=0xbc7603df25a071f3) 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)

I hope it helps.

Best regards,
-czg

bug#28308: Build failure on FreeBSD/aarch64

[Eli Zaretskii]

> From: Gergely Czuczy <gergely.czuczy@harmless.hu>
> Date: Sat, 9 Sep 2017 07:01:20 +0200
> Cc: 28308@debbugs.gnu.org
> 
> Process 69906 stopped
> * thread #1, name = 'bootstrap-emacs', stop reason = signal SIGSEGV: 
> invalid address (fault address: 0x41aef578)
>      frame #0: 0x0000000000228460 
> bootstrap-emacs`xnrealloc(pa=0x0000000000000000, nitems=0, 
> item_size=1101985151) 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: 0x41aef578)
>    * frame #0: 0x0000000000228460 
> bootstrap-emacs`xnrealloc(pa=0x0000000000000000, nitems=0, 
> item_size=1101985151) 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=0x0000000041aef57f, nitems_incr_min=1683000, 
> nitems_max=42949672960, item_size=281474976703896) at alloc.c:0
>      frame #3: 0x0000000000168214 
> bootstrap-emacs`delete_tty(terminal=0xbc7603df25a071f3) 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)

I don't understand how come xpalloc got called in this context.
delete_tty on line 4463 of term,c calls delete_terminal, which only
calls xfree.  It doesn't allocate any memory (of course), let alone
with semi-bogus arguments as shown in this backtrace.

What am I missing?

bug#28308: Build failure on FreeBSD/aarch64

[npostavs]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gergely Czuczy <gergely.czuczy@harmless.hu>
>> Date: Sat, 9 Sep 2017 07:01:20 +0200
>> Cc: 28308@debbugs.gnu.org
>> 
>> * thread #1, name = 'bootstrap-emacs', stop reason = signal SIGSEGV: 
>> invalid address (fault address: 0x41aef578)
>>    * frame #0: 0x0000000000228460 
>> bootstrap-emacs`xnrealloc(pa=0x0000000000000000, nitems=0, 
>> item_size=1101985151) 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=0x0000000041aef57f, nitems_incr_min=1683000, 
>> nitems_max=42949672960, item_size=281474976703896) at alloc.c:0
>>      frame #3: 0x0000000000168214 
>> bootstrap-emacs`delete_tty(terminal=0xbc7603df25a071f3) 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)
>
> I don't understand how come xpalloc got called in this context.
> delete_tty on line 4463 of term,c calls delete_terminal, which only
> calls xfree.  It doesn't allocate any memory (of course), let alone
> with semi-bogus arguments as shown in this backtrace.

Frame #2 "at alloc.c:0" seems a bit fishy too.  Stack corruption?  Or is
it possible optimizations are interfering with the debug info?  Gergely,
could you try rebuiding with -O0 in addition to -g?

bug#28308: Build failure on FreeBSD/aarch64

[Gergely Czuczy]

On 2017. 09. 11. 8:07, npostavs@users.sourceforge.net wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Gergely Czuczy <gergely.czuczy@harmless.hu>
>>> Date: Sat, 9 Sep 2017 07:01:20 +0200
>>> Cc: 28308@debbugs.gnu.org
>>>
>>> * thread #1, name = 'bootstrap-emacs', stop reason = signal SIGSEGV:
>>> invalid address (fault address: 0x41aef578)
>>>     * frame #0: 0x0000000000228460
>>> bootstrap-emacs`xnrealloc(pa=0x0000000000000000, nitems=0,
>>> item_size=1101985151) 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=0x0000000041aef57f, nitems_incr_min=1683000,
>>> nitems_max=42949672960, item_size=281474976703896) at alloc.c:0
>>>       frame #3: 0x0000000000168214
>>> bootstrap-emacs`delete_tty(terminal=0xbc7603df25a071f3) 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)
>> I don't understand how come xpalloc got called in this context.
>> delete_tty on line 4463 of term,c calls delete_terminal, which only
>> calls xfree.  It doesn't allocate any memory (of course), let alone
>> with semi-bogus arguments as shown in this backtrace.
> Frame #2 "at alloc.c:0" seems a bit fishy too.  Stack corruption?  Or is
> it possible optimizations are interfering with the debug info?  Gergely,
> could you try rebuiding with -O0 in addition to -g?
I've rebuilt it with CFLAGS="-O0 -g", but it seems to be the same in 
this regards:
root@build-pine64:/usr/ports/editors/emacs-devel# cd 
/usr/ports/editors/emacs-devel/work/emacs-f44184f/lisp
root@build-pine64:/usr/ports/editors/emacs-devel/work/emacs-f44184f/lisp# 
EMACSLOADPATH= lldb -- '../src/bootstrap-emacs' -batch --no-site-file 
--no-site-lisp --eval '(setq load-prefer-newer t)' -f batch-byte-compile 
emacs-lisp/macroexp.el
(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 88583 launching
Process 88583 launched: '../src/bootstrap-emacs' (aarch64)
Process 88583 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=0x3276551740f23ac5) 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)

bug#28308: Build failure on FreeBSD/aarch64

[Eli Zaretskii]

> Cc: 28308@debbugs.gnu.org
> From: Gergely Czuczy <gergely.czuczy@harmless.hu>
> Date: Mon, 11 Sep 2017 09:26:20 +0200
> 
> I've rebuilt it with CFLAGS="-O0 -g", but it seems to be the same in 
> this regards:
> root@build-pine64:/usr/ports/editors/emacs-devel# cd 
> /usr/ports/editors/emacs-devel/work/emacs-f44184f/lisp
> root@build-pine64:/usr/ports/editors/emacs-devel/work/emacs-f44184f/lisp# 
> EMACSLOADPATH= lldb -- '../src/bootstrap-emacs' -batch --no-site-file 
> --no-site-lisp --eval '(setq load-prefer-newer t)' -f batch-byte-compile 
> emacs-lisp/macroexp.el
> (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 88583 launching
> Process 88583 launched: '../src/bootstrap-emacs' (aarch64)
> Process 88583 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=0x3276551740f23ac5) 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)

I don't understand how can this be.  Can you go to frame #3, in
delete_tty, and show what line of C code there allegedly calls
xpalloc?

bug#28308: Build failure on FreeBSD/aarch64

[Gergely Czuczy]

On 2017. 09. 11. 16:45, Eli Zaretskii wrote:
>> Cc: 28308@debbugs.gnu.org
>> From: Gergely Czuczy <gergely.czuczy@harmless.hu>
>> Date: Mon, 11 Sep 2017 09:26:20 +0200
>>
>> I've rebuilt it with CFLAGS="-O0 -g", but it seems to be the same in
>> this regards:
>> root@build-pine64:/usr/ports/editors/emacs-devel# cd
>> /usr/ports/editors/emacs-devel/work/emacs-f44184f/lisp
>> root@build-pine64:/usr/ports/editors/emacs-devel/work/emacs-f44184f/lisp#
>> EMACSLOADPATH= lldb -- '../src/bootstrap-emacs' -batch --no-site-file
>> --no-site-lisp --eval '(setq load-prefer-newer t)' -f batch-byte-compile
>> emacs-lisp/macroexp.el
>> (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 88583 launching
>> Process 88583 launched: '../src/bootstrap-emacs' (aarch64)
>> Process 88583 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=0x3276551740f23ac5) 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)
> I don't understand how can this be.  Can you go to frame #3, in
> delete_tty, and show what line of C code there allegedly calls
> xpalloc?
Sure, here it is:
https://github.com/emacs-mirror/emacs/blob/f44184f/src/term.c#L4463

bug#28308: Build failure on FreeBSD/aarch64

[Eli Zaretskii]

> Cc: npostavs@users.sourceforge.net, 28308@debbugs.gnu.org
> From: Gergely Czuczy <gergely.czuczy@harmless.hu>
> Date: Mon, 11 Sep 2017 17:10:39 +0200
> 
> >> 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=0x3276551740f23ac5) 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)
> > I don't understand how can this be.  Can you go to frame #3, in
> > delete_tty, and show what line of C code there allegedly calls
> > xpalloc?
> Sure, here it is:
> https://github.com/emacs-mirror/emacs/blob/f44184f/src/term.c#L4463

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?

bug#28308: Build failure on FreeBSD/aarch64

[Gergely Czuczy]

On 2017. 09. 11. 17:31, Eli Zaretskii wrote:
>> Cc: npostavs@users.sourceforge.net, 28308@debbugs.gnu.org
>> From: Gergely Czuczy <gergely.czuczy@harmless.hu>
>> Date: Mon, 11 Sep 2017 17:10:39 +0200
>>
>>>> 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=0x3276551740f23ac5) 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)
>>> I don't understand how can this be.  Can you go to frame #3, in
>>> delete_tty, and show what line of C code there allegedly calls
>>> xpalloc?
>> Sure, here it is:
>> https://github.com/emacs-mirror/emacs/blob/f44184f/src/term.c#L4463
> 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.

bug#28308: Build failure on FreeBSD/aarch64

[Eli Zaretskii]

> 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?

bug#28308: Build failure on FreeBSD/aarch64

[Gergely Czuczy]

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?
Unfortunately that won't work:
# make install
===>  gdb-8.0_1 is only for amd64 armv6 i386 mips powerpc powerpc64, while
you are running aarch64.

However, I've found that clang is able to tune the debug info for lldb 
with -glldb. Let me try that. It might take a bit of time, and it's 10pm 
here, so might get back with that tomorrow.

bug#28308: Build failure on FreeBSD/aarch64

[Gergely Czuczy]

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

[npostavs]

Gergely Czuczy <gergely.czuczy@harmless.hu> writes:

> 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.

That would require an aarch64 lldb and bootstrap-emacs executable,
right?

bug#28308: Build failure on FreeBSD/aarch64

[Gergely Czuczy]

On 2017. 09. 12. 7:22, npostavs@users.sourceforge.net wrote:
> Gergely Czuczy <gergely.czuczy@harmless.hu> writes:
>
>> 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.
> That would require an aarch64 lldb and bootstrap-emacs executable,
> right?

No, doesn't seem to be the case. It's a differench arch (amd64 vs 
aarch64), and also a different version of llvm/clang (4 vs 5):

gczuczy@dirk:/tank/rpi3/ports/editors/emacs-devel/work/emacs-f44184f$ 
uname -a
FreeBSD dirk.czg.harmless.lan 11.0-STABLE FreeBSD 11.0-STABLE #0 
r314769: Mon Mar  6 22:29:23 CET 2017 
toor@dirk.czg.harmless.lan:/usr/obj/usr/src/sys/DIRK  amd64
gczuczy@dirk:/tank/rpi3/ports/editors/emacs-devel/work/emacs-f44184f$ 
lldb ./src/bootstrap-emacs -c lisp/bootstrap-emacs.core
(lldb) target create "./src/bootstrap-emacs" --core 
"lisp/bootstrap-emacs.core"
Core file 
'/tank/rpi3/ports/editors/emacs-devel/work/emacs-f44184f/lisp/bootstrap-emacs.core' 
(aarch64) was loaded.
(lldb) bt
* thread #1: tid = 101217, 0x00000000002e5604 
bootstrap-emacs`Fterpri(printcharfun=1092903309, ensure=107564) + 2468 
at print.c:597, name = 'bootstrap-emacs', stop reason = signal SIGSEGV
   * frame #0: 0x00000000002e5604 
bootstrap-emacs`Fterpri(printcharfun=1092903309, ensure=107564) + 2468 
at print.c:597
     frame #1: 0x00000000002e4f18 
bootstrap-emacs`Fterpri(printcharfun=107550, ensure=14) + 696 at print.c:583
     frame #2: 0x00000000002e4e70 
bootstrap-emacs`Fterpri(printcharfun=1092903309, ensure=0) + 528 at 
print.c:0
     frame #3: 0x00000000001d8340 bootstrap-emacs`read_minibuf(map=0, 
initial=1934144, prompt=7376448, expflag=false, histvar=14, 
histpos=1092903309, defalt=0, allow_props=false, 
inherit_input_method=false) + 3696 at minibuf.c:657
     frame #4: 0x00000000001da310 
bootstrap-emacs`Fall_completions(string=0, collection=1093123072, 
predicate=-17179869184, hide_spaces=8597311552) + 368 at minibuf.c:1509
     frame #5: 0x000000000016737c 
bootstrap-emacs`save_and_enable_current_matrix(f=0x0000000b0016b8ec) + 
272 at term.c:2960
     frame #6: 0x0000000000167048 
bootstrap-emacs`tty_menu_search_pane(menu=0x000000000019da18, 
pane=65535) + 156 at term.c:2760
     frame #7: 0x000000000019d948 
bootstrap-emacs`Fkey_description(keys=1694024, prefix=7377232) + 15236 
at keymap.c:2005
     frame #8: 0x000000000019d9f8 
bootstrap-emacs`Fkey_description(keys=1969711475, 
prefix=14199589052049779) + 15412 at keymap.c:2005
     frame #9: 0x000000000019ae58 
bootstrap-emacs`Fkey_description(keys=1683032, prefix=7377328) + 4244 at 
keymap.c:2003
     frame #10: 0x000000000019da98 
bootstrap-emacs`Fkey_description(keys=7378640, prefix=0) + 15572 at 
keymap.c:0
(lldb)

bug#28308: Build failure on FreeBSD/aarch64

[Eli Zaretskii]

> 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.

bug#28308: Build failure on FreeBSD/aarch64

[Gergely Czuczy]

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.

bug#28308: Build failure on FreeBSD/aarch64

[Gergely Czuczy]

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?
So, here's the image for the reproduction:
http://czg.harmless.hu/emacs/qemu-28308.gz
You can start it with:
qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  \
                     -accel tcg,thread=single \
                     -bios QEMU_EFI.fd -serial telnet::4444,server 
-nographic \
                     -drive if=none,file=${image},id=hd0,format=raw \
                     -device virtio-blk-device,drive=hd0 \
                     -device e1000,netdev=net0 \
                     -netdev 
tap,id=net0,ifname=tap0,script=/tank/rpi3/build/qemu-ifup.sh

adjust the $image, and the last line for the networking, it just sets 
the IP address on the host device:
ifname=$1
ifconfig ${ifname} inet 10.219.14.254/24

The root password is "foobar", has an sshd running, so you can later log 
in, tramp into it,etc.

Steps to reproduce the build failure:
cd /usr/ports/editors/emacs-devel
setenv CFLAGS "-O0 -glldb"
setenv CXXFLAGS "-O0 -glldb"
make -DTRYBROKEN DISABLE_VULNERABILITIES=yes build

The ports tree extracts the source under and does the actual build under 
work/, you will find it all there.

Also, just in case, I've checked out the emacs source from github under 
/root/emacs/, to save you some time if that's needed.

If you would like to test the build from a different checkout in ports, 
just update /usr/ports/editors/emacs-devel/Makefile:
1) update the GH_TAGNAME
2) rm distinfo
3) make makesum
4) rm -rf work
5) then you can start the build again

I hope this helps.

Best regards,
Gergely

bug#28308: Build failure on FreeBSD/aarch64

[Noam Postavsky]

On Wed, Sep 20, 2017 at 1:51 AM, Gergely Czuczy
<gergely.czuczy@harmless.hu> wrote:

> So, here's the image for the reproduction:
> http://czg.harmless.hu/emacs/qemu-28308.gz
> You can start it with:
> qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  \
>                     -accel tcg,thread=single \
>                     -bios QEMU_EFI.fd -serial telnet::4444,server -nographic
> \
>                     -drive if=none,file=${image},id=hd0,format=raw \
>                     -device virtio-blk-device,drive=hd0 \
>                     -device e1000,netdev=net0 \
>                     -netdev
> tap,id=net0,ifname=tap0,script=/tank/rpi3/build/qemu-ifup.sh
>
> adjust the $image, and the last line for the networking, it just sets the IP
> address on the host device:
> ifname=$1
> ifconfig ${ifname} inet 10.219.14.254/24

I tried this on Windows, as my GNU/Linux box is underpowered. I
couldn't get the networking stuff working, but it seems to function
without that:

setlocal
set image=qemu-28308.img
set qemu="C:\Program Files\qemu\qemu-system-aarch64.exe"

%qemu% -m 4096M -cpu cortex-a57 -M virt ^
       -accel tcg,thread=single ^
       -bios QEMU_EFI.fd -serial telnet::4444,server ^
       -drive if=none,file=%image%,id=hd0,format=raw ^
       -device virtio-blk-device,drive=hd0

QEMU_EFI.fd retrieved from here: https://wiki.freebsd.org/arm64/QEMU

I tried setting a breakpoint in main, but I still landed in
tty_menu_display. Then I tried setting a breakpoint __start, after
stepping around a little I found this:

(lldb) disassemble --pc
bootstrap-emacs`__start:
->  0x40180 <+360>: mov    w0, w21
    0x40184 <+364>: mov    x1, x20
    0x40188 <+368>: mov    x2, x19
    0x4018c <+372>: bl     0x16742c                  ;
tty_menu_display + 132 at term.c:2817
(lldb) bt
* thread #1, name = 'bootstrap-emacs', stop reason = breakpoint 2.1
  * frame #0: 0x0000000000040180 bootstrap-emacs`__start(argc=9,
argv=0x0000ffffffffead0, env=0x0000ffffffffeb20,
cleanup=<unavailable>) at crt1.c:84
    frame #1: 0x0000000040390018 ld-elf.so.1`.rtld_start at rtld_start.S:41

I think that means that tty_menu_display is getting called from
__start, which should not be possible?!

Paul's suggestion of configuring with CANNOT_DUMP=yes seems to work,
although I didn't continue past compilation macroexp.el, since it's
extremely slow.

bug#28308: Build failure on FreeBSD/aarch64

[Noam Postavsky]

[-- Attachment #1: Type: text/plain, Size: 539 bytes --]

Noam Postavsky <npostavs@users.sourceforge.net> writes:

> (lldb) disassemble --pc
> bootstrap-emacs`__start:
> ->  0x40180 <+360>: mov    w0, w21
>     0x40184 <+364>: mov    x1, x20
>     0x40188 <+368>: mov    x2, x19
>     0x4018c <+372>: bl     0x16742c                  ; tty_menu_display + 132 at term.c:2817

> I think that means that tty_menu_display is getting called from
> __start, which should not be possible?!

It seems that the debug info show by lldb is bogus, it shows two
locations for tty_menu_display (see attached).


[-- Attachment #2: excerpts from an lldb session --]
[-- Type: text/plain, Size: 2499 bytes --]

(lldb) expr main
(int (*)(int, char **)) $0 = 0x0000000000167474

(lldb) disassemble -s 0x167474 -e (0x167474+16)
bootstrap-emacs`main:
bootstrap-emacs[0x167474] <+0>:  str    x28, [sp, #-0x20]!
bootstrap-emacs[0x167478] <+4>:  stp    x29, x30, [sp, #0x10]
bootstrap-emacs[0x16747c] <+8>:  add    x29, sp, #0x10            ; =0x10
bootstrap-emacs[0x167480] <+12>: sub    sp, sp, #0x1f0            ; =0x1f0

(lldb) disassemble -p -b
bootstrap-emacs`tty_menu_display:
->  0x167474 <+128>: 0xf81e0ffc   str    x28, [sp, #-0x20]!
    0x167478 <+132>: 0xa9017bfd   stp    x29, x30, [sp, #0x10]
    0x16747c <+136>: 0x910043fd   add    x29, sp, #0x10            ; =0x10
    0x167480 <+140>: 0xd107c3ff   sub    sp, sp, #0x1f0            ; =0x1f0

(lldb) expr tty_menu_display
(void (*)(tty_menu *, int, int, int, int *, int, int, int, bool)) $1 = 0x00000000001573f4

(lldb) disassemble -n tty_menu_display
bootstrap-emacs`tty_menu_display:
    0x1573f4 <+0>:    sub    sp, sp, #0xa0             ; =0xa0
    0x1573f8 <+4>:    stp    x29, x30, [sp, #0x90]
    0x1573fc <+8>:    add    x29, sp, #0x90            ; =0x90
    0x157400 <+12>:   ldrb   w8, [x29, #0x10]
    0x157404 <+16>:   adrp   x9, 1497
    0x157408 <+20>:   add    x9, x9, #0x998            ; =0x998
    0x15740c <+24>:   stur   x0, [x29, #-0x8]
    0x157410 <+28>:   stur   w1, [x29, #-0xc]
[...]
    0x1577d4 <+992>:  bl     0x43498
    0x1577d8 <+996>:  ldp    x29, x30, [sp, #0x90]
    0x1577dc <+1000>: add    sp, sp, #0xa0             ; =0xa0
    0x1577e0 <+1004>: ret

bootstrap-emacs`tty_menu_display:
    0x1673f4 <+0>:    add    sp, sp, #0xa0             ; =0xa0
    0x1673f8 <+4>:    ret
    0x1673fc <+8>:    sub    sp, sp, #0x20             ; =0x20
    0x167400 <+12>:   stp    x29, x30, [sp, #0x10]
    0x167404 <+16>:   add    x29, sp, #0x10            ; =0x10
    0x167408 <+20>:   adrp   x8, 1469
    0x16740c <+24>:   add    x8, x8, #0x470            ; =0x470
    0x167410 <+28>:   stur   w0, [x29, #-0x4]
    0x167414 <+32>:   ldursw x9, [x29, #-0x4]
[...]
    0x167468 <+116>:  bl     0x2921d8                  ; Fapply + 6324 at eval.c:2364
    0x16746c <+120>:  ldp    x29, x30, [sp], #0x10
    0x167470 <+124>:  ret
->  0x167474 <+128>:  str    x28, [sp, #-0x20]!
    0x167478 <+132>:  stp    x29, x30, [sp, #0x10]
    0x16747c <+136>:  add    x29, sp, #0x10            ; =0x10
    0x167480 <+140>:  sub    sp, sp, #0x1f0            ; =0x1f0
    0x167484 <+144>:  mov    w8, wzr
    0x167488 <+148>:  adrp   x9, 1500

[-- Attachment #3: Type: text/plain, Size: 894 bytes --]


Here is a backtrace from running 'lldb -- ./bootstrap-emacs -Q -batch',
with source locations generated by 'addr2line -e ./bootstrap-emacs -f -i -p'.
 
* thread #1, name = 'bootstrap-emacs', stop reason = signal SIGSEGV: invalid address (fault address: 0x41626d78)
0x000000000022810c XFLOAT_INIT at /root/emacs/src/alloc.c:543
0x0000000000227eb0 make_float at /root/emacs/src/alloc.c:2667
0x000000000022de24 init_alloc at /root/emacs/src/alloc.c:7481
0x000000000016825c main at /root/emacs/src/emacs.c:1251
0x0000000000040190 __start at /tank/rpi3/src/lib/csu/aarch64/crt1.c:84
0x0000000040390018 ?? at ??:0

This is from revision [1: 35c893ddaf], configured with

    'CFLAGS=-O0 -glldb -DUNEXELF_DEBUG=1' '--without-all'

[1: 35c893ddaf]: 2017-09-12 11:08:00 -0400
  Move gensym to core Elisp
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=35c893ddaf21b93677850a69709b59630bb0feb7

bug#28308: Build failure on FreeBSD/aarch64

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  28308@debbugs.gnu.org
> Date: Thu, 19 Oct 2017 19:39:11 -0400
> 
> It seems that the debug info show by lldb is bogus, it shows two
> locations for tty_menu_display (see attached).

Maybe that function was inlined?

> Here is a backtrace from running 'lldb -- ./bootstrap-emacs -Q -batch',
> with source locations generated by 'addr2line -e ./bootstrap-emacs -f -i -p'.
>  
> * thread #1, name = 'bootstrap-emacs', stop reason = signal SIGSEGV: invalid address (fault address: 0x41626d78)
> 0x000000000022810c XFLOAT_INIT at /root/emacs/src/alloc.c:543
> 0x0000000000227eb0 make_float at /root/emacs/src/alloc.c:2667
> 0x000000000022de24 init_alloc at /root/emacs/src/alloc.c:7481
> 0x000000000016825c main at /root/emacs/src/emacs.c:1251
> 0x0000000000040190 __start at /tank/rpi3/src/lib/csu/aarch64/crt1.c:84
> 0x0000000040390018 ?? at ??:0

Can you disassemble XFLOAT_INIT and tell which part of it caused the
segfault, and why?  In particular, what is the relation of the
faulting address 0x41626d78 and the C source?

bug#28308: Build failure on FreeBSD/aarch64

[Noam Postavsky]

On Fri, Oct 20, 2017 at 3:07 AM, Eli Zaretskii <eliz@gnu.org> wrote:

>> * thread #1, name = 'bootstrap-emacs', stop reason = signal SIGSEGV: invalid address (fault address: 0x41626d78)
>> 0x000000000022810c XFLOAT_INIT at /root/emacs/src/alloc.c:543
>> 0x0000000000227eb0 make_float at /root/emacs/src/alloc.c:2667
>> 0x000000000022de24 init_alloc at /root/emacs/src/alloc.c:7481
>> 0x000000000016825c main at /root/emacs/src/emacs.c:1251

> Can you disassemble XFLOAT_INIT and tell which part of it caused the
> segfault, and why?  In particular, what is the relation of the
> faulting address 0x41626d78 and the C source?

The faulting address is XFLOAT(f):

static void
XFLOAT_INIT (Lisp_Object f, double n)
{
  XFLOAT (f)->u.data = n;
}

'f' is 'val' in make_float. I added a fprintf(stderr, "%p\n",
XFLOAT(val)) before the XFLOAT_INIT call, the address which was ok
with temacs triggers SIGSEGV in bootstrap-emacs.
It seems that the memory pointer to by float_block->floats becomes
invalid following the dumping process.

By the way, when I delete bootstrap-emacs and redump, the faulting
address changes (although it's always of the form 0x4XXXXXXX).

bug#28308: Build failure on FreeBSD/aarch64

[Noam Postavsky]

tags 28308 + patch
quit

On Tue, Oct 24, 2017 at 2:43 PM, Noam Postavsky
<npostavs@users.sourceforge.net> wrote:

> It seems that the memory pointer to by float_block->floats becomes
> invalid following the dumping process.

The following patch which makes FreeBSD use the hybrid malloc scheme fixes it:

diff --git a/configure.ac b/configure.ac
index d294412dc4..2e690987a6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2206,7 +2206,7 @@ AC_DEFUN
 case "$opsys" in
   ## darwin ld insists on the use of malloc routines in the System framework.
   darwin | mingw32 | nacl | sol2-10) ;;
-  cygwin) hybrid_malloc=yes
+  freebsd | cygwin) hybrid_malloc=yes
           system_malloc= ;;
   *) test "$ac_cv_func_sbrk" = yes &&
system_malloc=$emacs_cv_sanitize_address;;
 esac
diff --git a/src/gmalloc.c b/src/gmalloc.c
index baaff58050..8fd05fe845 100644
--- a/src/gmalloc.c
+++ b/src/gmalloc.c
@@ -1509,9 +1509,13 @@ gdefault_morecore (ptrdiff_t increment)
       return bss_sbrk (increment);
     }
 #endif
+#ifdef HAVE_SBRK
   result = (void *) __sbrk (increment);
   if (result == (void *) -1)
     return NULL;
+#else
+  result = NULL;
+#endif
   return result;
 }

bug#28308: Build failure on FreeBSD/aarch64

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Tue, 31 Oct 2017 13:31:46 -0400
> Cc: Gergely Czuczy <gergely.czuczy@harmless.hu>, 28308@debbugs.gnu.org
> 
> > It seems that the memory pointer to by float_block->floats becomes
> > invalid following the dumping process.
> 
> The following patch which makes FreeBSD use the hybrid malloc scheme fixes it:

Thanks.  Please let others to chime in, and if no comments emerge,
please push to the release branch.

bug#28308: Build failure on FreeBSD/aarch64

[Gergely Czuczy]

On 2017. 10. 31. 18:31, Noam Postavsky wrote:
> tags 28308 + patch
> quit
>
> On Tue, Oct 24, 2017 at 2:43 PM, Noam Postavsky
> <npostavs@users.sourceforge.net> wrote:
>
>> It seems that the memory pointer to by float_block->floats becomes
>> invalid following the dumping process.
> The following patch which makes FreeBSD use the hybrid malloc scheme fixes it:
>
> diff --git a/configure.ac b/configure.ac
> index d294412dc4..2e690987a6 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -2206,7 +2206,7 @@ AC_DEFUN
>   case "$opsys" in
>     ## darwin ld insists on the use of malloc routines in the System framework.
>     darwin | mingw32 | nacl | sol2-10) ;;
> -  cygwin) hybrid_malloc=yes
> +  freebsd | cygwin) hybrid_malloc=yes
>             system_malloc= ;;
>     *) test "$ac_cv_func_sbrk" = yes &&
> system_malloc=$emacs_cv_sanitize_address;;
>   esac
> diff --git a/src/gmalloc.c b/src/gmalloc.c
> index baaff58050..8fd05fe845 100644
> --- a/src/gmalloc.c
> +++ b/src/gmalloc.c
> @@ -1509,9 +1509,13 @@ gdefault_morecore (ptrdiff_t increment)
>         return bss_sbrk (increment);
>       }
>   #endif
> +#ifdef HAVE_SBRK
>     result = (void *) __sbrk (increment);
>     if (result == (void *) -1)
>       return NULL;
> +#else
> +  result = NULL;
> +#endif
>     return result;
>   }
Is 2e690987a6 the commit id I can try? I would like to test it.

Thanks,
-czg

bug#28308: Build failure on FreeBSD/aarch64

[Noam Postavsky]

On Wed, Nov 1, 2017 at 12:14 PM, Gergely Czuczy
<gergely.czuczy@harmless.hu> wrote:
>
> On 2017. 10. 31. 18:31, Noam Postavsky wrote:
>>
>> diff --git a/configure.ac b/configure.ac
>> index d294412dc4..2e690987a6 100644
>> --- a/configure.ac
>> +++ b/configure.ac

> Is 2e690987a6 the commit id I can try? I would like to test it.

No, that hash is for the configure.ac file only. To test the patch,
save it to a file (e.g., call it bsd-hybridmalloc.diff) and then run
'git apply bsd-hybridmalloc.diff'.

By the way, do you know about the status of Emacs on FreeBSD x86? It
seems to me that the problem and solution are not specific to aarch64.

bug#28308: Build failure on FreeBSD/aarch64

[Gergely Czuczy]

On 2017. 11. 01. 17:51, Noam Postavsky wrote:
> On Wed, Nov 1, 2017 at 12:14 PM, Gergely Czuczy
> <gergely.czuczy@harmless.hu> wrote:
>> On 2017. 10. 31. 18:31, Noam Postavsky wrote:
>>> diff --git a/configure.ac b/configure.ac
>>> index d294412dc4..2e690987a6 100644
>>> --- a/configure.ac
>>> +++ b/configure.ac
>> Is 2e690987a6 the commit id I can try? I would like to test it.
> No, that hash is for the configure.ac file only. To test the patch,
> save it to a file (e.g., call it bsd-hybridmalloc.diff) and then run
> 'git apply bsd-hybridmalloc.diff'.
>
> By the way, do you know about the status of Emacs on FreeBSD x86? It
> seems to me that the problem and solution are not specific to aarch64.
On x86 (as in 32 bit terms), I don't really know. All my systems are 
amd64 ones, and on that one, it runs fine. However, I haven't checked 
the development branch, just the release. That works fine.

But if that's any help, I can give it a shot tomorrow on amd64 as well, 
and see how it goes.

Regarding the patch, I should apply it to the latest checkout, right?

bug#28308: Build failure on FreeBSD/aarch64

[Noam Postavsky]

On Wed, Nov 1, 2017 at 2:27 PM, Gergely Czuczy
<gergely.czuczy@harmless.hu> wrote:

>> By the way, do you know about the status of Emacs on FreeBSD x86? It
>> seems to me that the problem and solution are not specific to aarch64.
>
> On x86 (as in 32 bit terms), I don't really know. All my systems are amd64
> ones, and on that one, it runs fine. However, I haven't checked the
> development branch, just the release. That works fine.

Oh, yeah, I didn't mean 32 bit specifically. Actually, reading the OP
of #24892 again, it sounds like sbrk is only removed from arm, so I
guess x86/amd64 would still have it, and could therefore use the
gmalloc-only scheme successfully.

> But if that's any help, I can give it a shot tomorrow on amd64 as well, and
> see how it goes.

If you can check my patch on amd64 as well it would be good. Although
perhaps I should change the patch to only switch to hybrid malloc if
sbrk is missing, to avoid changing working platforms, at least for
emacs-26.

> Regarding the patch, I should apply it to the latest checkout, right?

Yes, the latest emacs-26. I've only tested on top of 35c893ddaf as I
haven't worked out how to update the VM, but I don't think anything
has changed in that area recently so there should be no problem
applying it to more recent checkouts.

bug#28308: Build failure on FreeBSD/aarch64

[Gergely Czuczy]

On 2017. 10. 31. 18:31, Noam Postavsky wrote:
> tags 28308 + patch
> quit
>
> On Tue, Oct 24, 2017 at 2:43 PM, Noam Postavsky
> <npostavs@users.sourceforge.net> wrote:
>
>> It seems that the memory pointer to by float_block->floats becomes
>> invalid following the dumping process.
> The following patch which makes FreeBSD use the hybrid malloc scheme fixes it:
>
> diff --git a/configure.ac b/configure.ac
> index d294412dc4..2e690987a6 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -2206,7 +2206,7 @@ AC_DEFUN
>   case "$opsys" in
>     ## darwin ld insists on the use of malloc routines in the System framework.
>     darwin | mingw32 | nacl | sol2-10) ;;
> -  cygwin) hybrid_malloc=yes
> +  freebsd | cygwin) hybrid_malloc=yes
>             system_malloc= ;;
>     *) test "$ac_cv_func_sbrk" = yes &&
> system_malloc=$emacs_cv_sanitize_address;;
>   esac
> diff --git a/src/gmalloc.c b/src/gmalloc.c
> index baaff58050..8fd05fe845 100644
> --- a/src/gmalloc.c
> +++ b/src/gmalloc.c
> @@ -1509,9 +1509,13 @@ gdefault_morecore (ptrdiff_t increment)
>         return bss_sbrk (increment);
>       }
>   #endif
> +#ifdef HAVE_SBRK
>     result = (void *) __sbrk (increment);
>     if (result == (void *) -1)
>       return NULL;
> +#else
> +  result = NULL;
> +#endif
>     return result;
>   }
So, the amd64 and the aarch64 builds have finished:
GNU Emacs 26.0.50 (build 1, amd64-portbld-freebsd11.0) of 2017-11-02
GNU Emacs 26.0.50 (build 1, aarch64-portbld-freebsd12.0) of 2017-11-02

Both are functional.

Regarding updating the port, that's rather simple, you don't have to 
update the whole OS or anything similar.

Here's how you can do it:
cd /usr/ports/editors/emacs-devel
rm distinfo
rm -rf work
vi Makefile # adjust GH_TAGNAME with the commit id.
make fetch; make makesum

That will update the required things to build it. However, if the 
installed files have changed, plist might have to be adjusted for the 
install target, but just ignore that. If you touch the missing files, 
that's sufficient (if happens at all).

If this version will be the fix for the issue, could you please let me 
know which commit has it? I would like to let the port's maintainer 
know, so he can update the port in the master branch, fixing aarch64 
support finally.

Thank you very much for the help.

bug#28308: Build failure on FreeBSD/aarch64

[Noam Postavsky]

tags 28308 fixed
close 28308 26.1
quit

Gergely Czuczy <gergely.czuczy@harmless.hu> writes:

> On 2017. 10. 31. 18:31, Noam Postavsky wrote:

>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -2206,7 +2206,7 @@ AC_DEFUN
>>   case "$opsys" in
>>     ## darwin ld insists on the use of malloc routines in the System framework.
>>     darwin | mingw32 | nacl | sol2-10) ;;
>> -  cygwin) hybrid_malloc=yes
>> +  freebsd | cygwin) hybrid_malloc=yes
>>             system_malloc= ;;
>>     *) test "$ac_cv_func_sbrk" = yes &&
>> system_malloc=$emacs_cv_sanitize_address;;

Oops, I had some line wrapping here.

> So, the amd64 and the aarch64 builds have finished:
> GNU Emacs 26.0.50 (build 1, amd64-portbld-freebsd11.0) of 2017-11-02
> GNU Emacs 26.0.50 (build 1, aarch64-portbld-freebsd12.0) of 2017-11-02
>
> Both are functional.

Thanks for testing.  If they report as 26.0.50 rather than 26.0.90 you
may be applying to a somewhat old branch, but the dumping code has not
been updated since then so it shouldn't be a problem.

> Regarding updating the port, that's rather simple, you don't have to
> update the whole OS or anything similar.

I rather meant figuring out how to configure the network connection with
qemu.

> If this version will be the fix for the issue, could you please let me
> know which commit has it? I would like to let the port's maintainer
> know, so he can update the port in the master branch, fixing aarch64
> support finally.

I've cleaned up the gmalloc part of the patch a bit, and pushed to
emacs-26, see 918a2dda07.

[1: 918a2dda07]: 2017-11-04 18:49:28 -0400
  Use hybrid malloc for FreeBSD (Bug#28308)
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=918a2dda07ebf16601a93d0464f62c4e846d8b39

bug#28308: Build failure on FreeBSD/aarch64

[Gergely Czuczy]

On 2017. 11. 05. 0:14, Noam Postavsky wrote:
> tags 28308 fixed
> close 28308 26.1
> quit
>
> Gergely Czuczy <gergely.czuczy@harmless.hu> writes:
>
>> On 2017. 10. 31. 18:31, Noam Postavsky wrote:
>>> --- a/configure.ac
>>> +++ b/configure.ac
>>> @@ -2206,7 +2206,7 @@ AC_DEFUN
>>>    case "$opsys" in
>>>      ## darwin ld insists on the use of malloc routines in the System framework.
>>>      darwin | mingw32 | nacl | sol2-10) ;;
>>> -  cygwin) hybrid_malloc=yes
>>> +  freebsd | cygwin) hybrid_malloc=yes
>>>              system_malloc= ;;
>>>      *) test "$ac_cv_func_sbrk" = yes &&
>>> system_malloc=$emacs_cv_sanitize_address;;
> Oops, I had some line wrapping here.
>
>> So, the amd64 and the aarch64 builds have finished:
>> GNU Emacs 26.0.50 (build 1, amd64-portbld-freebsd11.0) of 2017-11-02
>> GNU Emacs 26.0.50 (build 1, aarch64-portbld-freebsd12.0) of 2017-11-02
>>
>> Both are functional.
> Thanks for testing.  If they report as 26.0.50 rather than 26.0.90 you
> may be applying to a somewhat old branch, but the dumping code has not
> been updated since then so it shouldn't be a problem.
>
>> Regarding updating the port, that's rather simple, you don't have to
>> update the whole OS or anything similar.
> I rather meant figuring out how to configure the network connection with
> qemu.
>
>> If this version will be the fix for the issue, could you please let me
>> know which commit has it? I would like to let the port's maintainer
>> know, so he can update the port in the master branch, fixing aarch64
>> support finally.
> I've cleaned up the gmalloc part of the patch a bit, and pushed to
> emacs-26, see 918a2dda07.
>
> [1: 918a2dda07]: 2017-11-04 18:49:28 -0400
>    Use hybrid malloc for FreeBSD (Bug#28308)
>    https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=918a2dda07ebf16601a93d0464f62c4e846d8b39

Thank you very much again for the help. I've notified the port 
maintainer, he'll soon update the port, and it'll work on again on aarch64.

Also, may I ask when the 26 release is planned?

bug#28308: Build failure on FreeBSD/aarch64

[Noam Postavsky]

On Sun, Nov 5, 2017 at 1:10 PM, Gergely Czuczy
<gergely.czuczy@harmless.hu> wrote:

> Also, may I ask when the 26 release is planned?

There's no firm date, as far as I know.

bug#28308: Build failure on FreeBSD/aarch64

[Paul Eggert]

What happens if you configure with

    ./configure CANNOT_DUMP=yes

along with all the other configure-time options you're using? (What are 
they, by the way?)