GNU bug report logs - #39577
27.0.60; [android 32 bit arm] Assertion failed during compilation

Previous Next

Full log

Message #11 received at 39577 <at> debbugs.gnu.org (full text, mbox):

From: Henrik Grimler <hgrimler <at> kth.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39577 <at> debbugs.gnu.org
Subject: Re: bug#39577: 27.0.60; Assertion failed during compilation
Date: Thu, 13 Feb 2020 20:00:16 +0100

Hi Eli,

On Thu, Feb 13, 2020 at 04:57:26PM +0200, Eli Zaretskii wrote:
> > Date: Wed, 12 Feb 2020 08:39:58 +0100
> > From: Henrik Grimler <henrik <at> grimler.se>
> > 
> > ../configure --enable-checking=yes,glyphs \
> > --enable-check-lisp-object-type \
> > --without-makeinfo \
> > --without-selinux \
> > --prefix /data/data/com.termux/files/usr/local \
> > CFLAGS="-O0 -g3 -gdwarf-4"
> > ```
> > 
> > but building the emacs-27 branch (commit 06c302d) this fails with:
> > 
> > ```
> > [...]
> > Loading /data/data/com.termux/files/home/projects/emacs/lisp/emacs-lisp/syntax.el (source)...
> > Loading /data/data/com.termux/files/home/projects/emacs/lisp/font-lock.el (source)...
> > Loading /data/data/com.termux/files/home/projects/emacs/lisp/jit-lock.el (source)...
> > 
> > ../../src/fns.c:2856: Emacs fatal error: assertion failed: !FIXNUM_OVERFLOW_P (lisp_h_make_fixnum_n)
> 
> This would mean that the values returned by getloadavg on that system
> are preposterously large.  Can you run the offending command under a
> debugger, put a breakpoint on line 2856 of fns.c, and see what values
> you get in the load_ave[] array?
 
It seems to be preposterously small:

```
Breakpoint 2, Fload_average (use_floats=XIL(0)) at ../../src/fns.c:2856
2856                              ? make_fixnum (100.0 * load_ave[loads])
(gdb) print load_ave
$1 = {2.8900000000000001, 2.8752811112650786e-312, 2.7799999999999998}
```

This android version does not have getloadavg (so I guess
lib/getloadavg.c is used instead?)
 
> > If I remove --enable-checking=yes,glyphs it builds (I am sending this
> > bug report from that build) but gets segmentation faults every now and
> > then. Easiest way to trigger it is to scroll up and down in some file,
> > but it still happens randomly, maybe after 200 lines, maybe after 10
> > 000.
> 
> Can you show a backtrace from the segfault?

After loading gdbinit from emacs src, starting emacs and scrolling up
and down a file a couple of times it crashes with:

```
Program received signal SIGSEGV, Segmentation fault.
0xb6995228 in sigsetjmp () from /system/lib/libc.so
```

A backtrace then unfortunately only shows:

```
#0  0xb6995228 in sigsetjmp () from /system/lib/libc.so
#1  0x62e31f80 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Program received signal SIGSEGV, Segmentation fault.
backtrace_top () at ../../src/eval.c:176
176     {
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on".
Evaluation of the expression containing the function
(backtrace_top) will be abandoned.
When the function is done executing, GDB will silently stop.
```

I am fairly in-experienced with gdb, so please let me know if there is
anything else I can try.

It also seems that the segfault does not happen if running inside
tmux.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.