GNU bug report logs -
#58232
29.0.50; alloc.c:879: assertion failed: 0 < item_size && 0 < nitems_incr_min && 0 <= n0 && -1 <= nitems_max
Previous Next
Reported by: Visuwesh <visuweshm <at> gmail.com>
Date: Sat, 1 Oct 2022 16:34:02 UTC
Severity: normal
Found in version 29.0.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 58232 in the body.
You can then email your comments to 58232 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58232
; Package
emacs
.
(Sat, 01 Oct 2022 16:34:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Visuwesh <visuweshm <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sat, 01 Oct 2022 16:34:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[ Not sure if emacs-devel was preferred for assertion violations. ]
With a build with checking enabled, I get the following message when I
launch Emacs.
% emacs -Q
alloc.c:879: Emacs fatal error: assertion failed: 0 < item_size && 0 < nitems_incr_min && 0 <= n0 && -1 <= nitems_max
Aborted
However, if I attach gdb to Emacs and launch it, it starts just fine.
IME, this goes away when I restart my laptop. In case it matters,
`free -h' output is below
% free -h
total used free shared buff/cache available
Mem: 3.7Gi 1.2Gi 1.0Gi 160Mi 1.5Gi 2.1Gi
Swap: 4.0Gi 513Mi 3.5Gi
In GNU Emacs 29.0.50 (build 37, x86_64-pc-linux-gnu, X toolkit, cairo
version 1.16.0, Xaw scroll bars) of 2022-10-01 built on astatine
Repository revision: fe54ad672e88477fc07c7590baf9d7935104b84a
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
System Description: Debian GNU/Linux bookworm/sid
Configured using:
'configure --with-x-toolkit=lucid --without-xaw3d
--enable-checking=yes,glyphs --enable-check-lisp-object-type
'CFLAGS=-O0 -g3''
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY PDUMPER
PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11
XDBE XIM XINPUT2 XPM LUCID ZLIB
Important settings:
value of $LC_MONETARY: ta_IN.UTF-8
value of $LC_NUMERIC: ta_IN.UTF-8
value of $LANG: en_GB.UTF-8
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils rmc iso-transl tooltip eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
faces cus-face macroexp files window text-properties overlay sha1 md5
base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo x-toolkit
xinput2 x multi-tty make-network-process emacs)
Memory information:
((conses 16 37349 7657)
(symbols 48 5305 0)
(strings 32 14225 1461)
(string-bytes 1 379975)
(vectors 16 9272)
(vector-slots 8 147636 13287)
(floats 8 23 25)
(intervals 56 240 0)
(buffers 1000 10))
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58232
; Package
emacs
.
(Sat, 01 Oct 2022 17:49:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 58232 <at> debbugs.gnu.org (full text, mbox):
> From: Visuwesh <visuweshm <at> gmail.com>
> Date: Sat, 01 Oct 2022 22:03:05 +0530
>
> [ Not sure if emacs-devel was preferred for assertion violations. ]
No, the bug tracker is the right place.
> With a build with checking enabled, I get the following message when I
> launch Emacs.
>
> % emacs -Q
> alloc.c:879: Emacs fatal error: assertion failed: 0 < item_size && 0 < nitems_incr_min && 0 <= n0 && -1 <= nitems_max
> Aborted
>
> However, if I attach gdb to Emacs and launch it, it starts just fine.
Can you enable core files and produce a core dump? Then it can be
debugged with GDB, and we could see the backtrace.
I cannot reproduce this, needless to say.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58232
; Package
emacs
.
(Sun, 02 Oct 2022 04:31:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 58232 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
[சனி அக்டோபர் 01, 2022] Eli Zaretskii wrote:
>> With a build with checking enabled, I get the following message when I
>> launch Emacs.
>>
>> % emacs -Q
>> alloc.c:879: Emacs fatal error: assertion failed: 0 < item_size && 0 < nitems_incr_min && 0 <= n0 && -1 <= nitems_max
>> Aborted
>>
>> However, if I attach gdb to Emacs and launch it, it starts just fine.
>
> Can you enable core files and produce a core dump? Then it can be
> debugged with GDB, and we could see the backtrace.
I attached the core dump to this mail. In case GMail mangles it, then
you can get it from http://ix.io/4c3V. Since gdb's list command showed
somewhere around SECCOMP_USABLE, I checked if Emacs was built with
seccomp with the following C program
#if defined HAVE_LINUX_SECCOMP_H && defined HAVE_LINUX_FILTER_H \
&& HAVE_DECL_SECCOMP_SET_MODE_FILTER \
&& HAVE_DECL_SECCOMP_FILTER_FLAG_TSYNC
# define SECCOMP_USABLE 1
#else
# define SECCOMP_USABLE 0
#endif
#include <stdio.h>
int
main(){
printf("%d\n", SECCOMP_USABLE);
}
and it printed 0.
[core (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58232
; Package
emacs
.
(Sun, 02 Oct 2022 06:16:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 58232 <at> debbugs.gnu.org (full text, mbox):
> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: 58232 <at> debbugs.gnu.org
> Date: Sun, 02 Oct 2022 10:00:22 +0530
>
> >> However, if I attach gdb to Emacs and launch it, it starts just fine.
> >
> > Can you enable core files and produce a core dump? Then it can be
> > debugged with GDB, and we could see the backtrace.
>
> I attached the core dump to this mail.
The core file can only be debugged on your system, so posting it is
not useful. You start GDB like this:
$ gdb /path/to/emacs/src/emacs core
(where "core" should be replaced with the actual absolute file name of
the core file), and then you can type "bt" at GDB prompt to show the
backtrace from the abort site.
Note that the above will only be possible as long as you have the
original emacs binary which dumped core. IOW, if you rebuild Emacs,
be sure to preserve the binary which aborted, or else GDB will refuse
to debug that.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58232
; Package
emacs
.
(Sun, 02 Oct 2022 06:57:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 58232 <at> debbugs.gnu.org (full text, mbox):
[ஞாயிறு அக்டோபர் 02, 2022] Eli Zaretskii wrote:
> The core file can only be debugged on your system, so posting it is
> not useful. You start GDB like this:
>
> $ gdb /path/to/emacs/src/emacs core
>
> (where "core" should be replaced with the actual absolute file name of
> the core file), and then you can type "bt" at GDB prompt to show the
> backtrace from the abort site.
Reading symbols from src/emacs...
BFD: warning: /home/viz/lib/ports/emacs/core has a segment extending past end of file
[New LWP 1524]
warning: Error reading shared library list entry at 0x6237303032326633
Failed to read a valid object file image from memory.
Core was generated by `emacs -Q'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007f772b28957c in ?? ()
(gdb) bt
#0 0x00007f772b28957c in ?? ()
Backtrace stopped: Cannot access memory at address 0x7fffa3849170
I'm observing something weird here. If I say "emacs -Q", then I get an
abort however if I say "src/emacs -Q", Emacs launches just fine.
"emacs" in my PATH refers to "src/emacs"...
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58232
; Package
emacs
.
(Sun, 02 Oct 2022 07:03:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 58232 <at> debbugs.gnu.org (full text, mbox):
> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: 58232 <at> debbugs.gnu.org
> Date: Sun, 02 Oct 2022 12:26:12 +0530
>
> [ஞாயிறு அக்டோபர் 02, 2022] Eli Zaretskii wrote:
>
> > The core file can only be debugged on your system, so posting it is
> > not useful. You start GDB like this:
> >
> > $ gdb /path/to/emacs/src/emacs core
> >
> > (where "core" should be replaced with the actual absolute file name of
> > the core file), and then you can type "bt" at GDB prompt to show the
> > backtrace from the abort site.
>
> Reading symbols from src/emacs...
> BFD: warning: /home/viz/lib/ports/emacs/core has a segment extending past end of file
> [New LWP 1524]
>
> warning: Error reading shared library list entry at 0x6237303032326633
> Failed to read a valid object file image from memory.
> Core was generated by `emacs -Q'.
> Program terminated with signal SIGABRT, Aborted.
> #0 0x00007f772b28957c in ?? ()
> (gdb) bt
> #0 0x00007f772b28957c in ?? ()
> Backtrace stopped: Cannot access memory at address 0x7fffa3849170
Is your Emacs compiled with debug info (-g3) and unstripped (no -s)?
Also, did you set up core file size limit to "unlimited"?
> I'm observing something weird here. If I say "emacs -Q", then I get an
> abort however if I say "src/emacs -Q", Emacs launches just fine.
> "emacs" in my PATH refers to "src/emacs"...
Yes, weird.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58232
; Package
emacs
.
(Sun, 02 Oct 2022 08:39:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 58232 <at> debbugs.gnu.org (full text, mbox):
[Sunday October 02, 2022] Eli Zaretskii wrote:
> Is your Emacs compiled with debug info (-g3) and unstripped (no -s)?
Yes, and yes. My configure flag is the one that is in etc/DEBUG, and
`file' reports that my binary is unstripped.
> Also, did you set up core file size limit to "unlimited"?
Looks like I messed up this part. Here's `bt' when core dump limit is
unlimited,
Reading symbols from emacs...
[New LWP 6962]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `emacs -Q'.
Program terminated with signal SIGABRT, Aborted.
(gdb) bt
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo <at> entry=6, no_tid=no_tid <at> entry=0) at ./nptl/pthread_kill.c:44
#1 0x00007f854d4895df in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#2 0x00007f854d43da02 in __GI_raise (sig=6) at ../sysdeps/posix/raise.c:26
#3 0x000055a416dac32d in terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:458
#4 0x000055a416e6712d in die (msg=0x55a41702d090 "0 < item_size && 0 < nitems_incr_min && 0 <= n0 && -1 <= nitems_max", file=0x55a41702d06b "alloc.c", line=879) at alloc.c:7672
#5 0x000055a416e5a9be in xpalloc (pa=0x0, nitems=0x7fffc2172868, nitems_incr_min=-87, nitems_max=-1, item_size=1) at alloc.c:879
#6 0x000055a416dad158 in load_pdump (argc=2, argv=0x7fffc2172b98) at emacs.c:935
#7 0x000055a416dade3a in main (argc=2, argv=0x7fffc2172b98) at emacs.c:1359
(gdb)
>> I'm observing something weird here. If I say "emacs -Q", then I get an
>> abort however if I say "src/emacs -Q", Emacs launches just fine.
>> "emacs" in my PATH refers to "src/emacs"...
>
> Yes, weird.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58232
; Package
emacs
.
(Sun, 02 Oct 2022 09:01:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 58232 <at> debbugs.gnu.org (full text, mbox):
> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: 58232 <at> debbugs.gnu.org
> Date: Sun, 02 Oct 2022 14:07:54 +0530
>
> Reading symbols from emacs...
> [New LWP 6962]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Core was generated by `emacs -Q'.
> Program terminated with signal SIGABRT, Aborted.
> (gdb) bt
> #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo <at> entry=6, no_tid=no_tid <at> entry=0) at ./nptl/pthread_kill.c:44
> #1 0x00007f854d4895df in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
> #2 0x00007f854d43da02 in __GI_raise (sig=6) at ../sysdeps/posix/raise.c:26
> #3 0x000055a416dac32d in terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:458
> #4 0x000055a416e6712d in die (msg=0x55a41702d090 "0 < item_size && 0 < nitems_incr_min && 0 <= n0 && -1 <= nitems_max", file=0x55a41702d06b "alloc.c", line=879) at alloc.c:7672
> #5 0x000055a416e5a9be in xpalloc (pa=0x0, nitems=0x7fffc2172868, nitems_incr_min=-87, nitems_max=-1, item_size=1) at alloc.c:879
> #6 0x000055a416dad158 in load_pdump (argc=2, argv=0x7fffc2172b98) at emacs.c:935
> #7 0x000055a416dade3a in main (argc=2, argv=0x7fffc2172b98) at emacs.c:1359
> (gdb)
Please show the values of some variables in frame #6. Like this:
(gdb) frame 6
(gdb) p needed
(gdb) p bufsize
(gdb) p exenamelen
(gdb) p emacs_executable
(gdb) p suffix
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58232
; Package
emacs
.
(Sun, 02 Oct 2022 09:18:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 58232 <at> debbugs.gnu.org (full text, mbox):
[Sunday October 02, 2022] Eli Zaretskii wrote:
>> From: Visuwesh <visuweshm <at> gmail.com>
>> Cc: 58232 <at> debbugs.gnu.org
>> Date: Sun, 02 Oct 2022 14:07:54 +0530
>>
>> Reading symbols from emacs...
>> [New LWP 6962]
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>> Core was generated by `emacs -Q'.
>> Program terminated with signal SIGABRT, Aborted.
>> (gdb) bt
>> #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo <at> entry=6, no_tid=no_tid <at> entry=0) at ./nptl/pthread_kill.c:44
>> #1 0x00007f854d4895df in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
>> #2 0x00007f854d43da02 in __GI_raise (sig=6) at ../sysdeps/posix/raise.c:26
>> #3 0x000055a416dac32d in terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:458
>> #4 0x000055a416e6712d in die (msg=0x55a41702d090 "0 < item_size && 0 < nitems_incr_min && 0 <= n0 && -1 <= nitems_max", file=0x55a41702d06b "alloc.c", line=879) at alloc.c:7672
>> #5 0x000055a416e5a9be in xpalloc (pa=0x0, nitems=0x7fffc2172868, nitems_incr_min=-87, nitems_max=-1, item_size=1) at alloc.c:879
>> #6 0x000055a416dad158 in load_pdump (argc=2, argv=0x7fffc2172b98) at emacs.c:935
>> #7 0x000055a416dade3a in main (argc=2, argv=0x7fffc2172b98) at emacs.c:1359
>> (gdb)
>
> Please show the values of some variables in frame #6. Like this:
>
> (gdb) frame 6
> (gdb) p needed
> (gdb) p bufsize
> (gdb) p exenamelen
> (gdb) p emacs_executable
> (gdb) p suffix
(gdb) frame 6
#6 0x000055a416dad158 in load_pdump (argc=2, argv=0x7fffc2172b98) at emacs.c:935
935 dump_file = xpalloc (NULL, &bufsize, needed - bufsize, -1, 1);
(gdb) p needed
$1 = 41
(gdb) p bufsize
$2 = 128
(gdb) p exenamelen
$3 = 35
(gdb) p emacs_executable
$4 = 0x55a41793af20 "/home/viz/lib/ports/emacs/src/emacs"
(gdb) p suffix
$5 = 0x55a41701a648 ".pdmp"
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58232
; Package
emacs
.
(Sun, 02 Oct 2022 09:43:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 58232 <at> debbugs.gnu.org (full text, mbox):
> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: 58232 <at> debbugs.gnu.org
> Date: Sun, 02 Oct 2022 14:47:33 +0530
>
> (gdb) frame 6
> #6 0x000055a416dad158 in load_pdump (argc=2, argv=0x7fffc2172b98) at emacs.c:935
> 935 dump_file = xpalloc (NULL, &bufsize, needed - bufsize, -1, 1);
> (gdb) p needed
> $1 = 41
> (gdb) p bufsize
> $2 = 128
> (gdb) p exenamelen
> $3 = 35
> (gdb) p emacs_executable
> $4 = 0x55a41793af20 "/home/viz/lib/ports/emacs/src/emacs"
> (gdb) p suffix
> $5 = 0x55a41701a648 ".pdmp"
Ouch! Please try the patch below.
diff --git a/src/emacs.c b/src/emacs.c
index 91bf0a9..00c381a 100644
--- a/src/emacs.c
+++ b/src/emacs.c
@@ -932,7 +932,7 @@ load_pdump (int argc, char **argv)
exenamelen = prefix_length;
}
ptrdiff_t needed = exenamelen + strlen (suffix) + 1;
- dump_file = xpalloc (NULL, &bufsize, needed - bufsize, -1, 1);
+ dump_file = xpalloc (NULL, &bufsize, max (1, needed - bufsize), -1, 1);
memcpy (dump_file, emacs_executable, exenamelen);
strcpy (dump_file + exenamelen, suffix);
result = pdumper_load (dump_file, emacs_executable);
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58232
; Package
emacs
.
(Sun, 02 Oct 2022 09:49:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 58232 <at> debbugs.gnu.org (full text, mbox):
[Sunday October 02, 2022] Eli Zaretskii wrote:
> Ouch! Please try the patch below.
The patch works, thanks!
> diff --git a/src/emacs.c b/src/emacs.c
> index 91bf0a9..00c381a 100644
> --- a/src/emacs.c
> +++ b/src/emacs.c
> @@ -932,7 +932,7 @@ load_pdump (int argc, char **argv)
> exenamelen = prefix_length;
> }
> ptrdiff_t needed = exenamelen + strlen (suffix) + 1;
> - dump_file = xpalloc (NULL, &bufsize, needed - bufsize, -1, 1);
> + dump_file = xpalloc (NULL, &bufsize, max (1, needed - bufsize), -1, 1);
> memcpy (dump_file, emacs_executable, exenamelen);
> strcpy (dump_file + exenamelen, suffix);
> result = pdumper_load (dump_file, emacs_executable);
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Sun, 02 Oct 2022 10:00:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Visuwesh <visuweshm <at> gmail.com>
:
bug acknowledged by developer.
(Sun, 02 Oct 2022 10:00:02 GMT)
Full text and
rfc822 format available.
Message #40 received at 58232-done <at> debbugs.gnu.org (full text, mbox):
> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: 58232 <at> debbugs.gnu.org
> Date: Sun, 02 Oct 2022 15:17:52 +0530
>
> [Sunday October 02, 2022] Eli Zaretskii wrote:
>
> > Ouch! Please try the patch below.
>
> The patch works, thanks!
Thanks, installed on the emacs-28 release branch.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 30 Oct 2022 11:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 256 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.