intervals.c:1190: Emacs fatal error: assertion failed: amt == 0

intervals.c:1190: Emacs fatal error: assertion failed: amt == 0

[Werner LEMBERG]

[f28166dc9a56111606be8ac50ad38179a66ea636 from today]

This bug is reproducible: I'm using 'mew' as my e-mail reader, and one
of the inbox messages (already delivered as one file per message to a
mew folder) causes the failure while the overview of e-mails gets
(re)generated.


    Werner


======================================================================


#0  0x000000000063ee5f in terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:371
#1  0x00000000007544e4 in die (msg=0xa086b8 "amt == 0", file=0xa08447 "intervals.c", line=1190) at alloc.c:7307
#2  0x0000000000889d9b in delete_interval (i=0x43) at intervals.c:1190
#3  0x000000000088dbbe in set_intervals_multibyte_1 (i=0x28410c8, multi_flag=true, start=110, start_byte=174, end=141, end_byte=218) at intervals.c:2382
#4  0x000000000088db26 in set_intervals_multibyte_1 (i=0x2841138, multi_flag=true, start=97, start_byte=135, end=141, end_byte=218) at intervals.c:2368
#5  0x000000000088db26 in set_intervals_multibyte_1 (i=0x2841020, multi_flag=true, start=1, start_byte=1, end=141, end_byte=218) at intervals.c:2368
#6  0x000000000088da32 in set_intervals_multibyte_1 (i=0x2841058, multi_flag=true, start=1, start_byte=1, end=1106, end_byte=1263) at intervals.c:2348
#7  0x000000000088dc7c in set_intervals_multibyte (multi_flag=true) at intervals.c:2403
#8  0x000000000069f741 in Fset_buffer_multibyte (flag=XIL(0x30)) at buffer.c:2730
#9  0x00000000007ad26b in funcall_subr (subr=0x1170380 <Sset_buffer_multibyte>, numargs=1, args=0x7fffffffac80) at eval.c:2867
#10 0x00000000007acd5f in Ffuncall (nargs=2, args=0x7fffffffac78) at eval.c:2794
#11 0x000000000082dc26 in exec_byte_code (bytestr=XIL(0x2047da4), vector=XIL(0x2047265), maxdepth=make_fixnum(5), args_template=XIL(0), nargs=0, args=0x0)
    at bytecode.c:633
#12 0x00000000007adf1e in funcall_lambda (fun=XIL(0x20474b5), nargs=2, arg_vector=0x2047265) at eval.c:3067
#13 0x00000000007acda3 in Ffuncall (nargs=3, args=0x7fffffffb398) at eval.c:2796
#14 0x000000000082dc26 in exec_byte_code (bytestr=XIL(0x1fb1044), vector=XIL(0x1f4c5d5), maxdepth=make_fixnum(7), args_template=XIL(0), nargs=0, args=0x0)
    at bytecode.c:633
#15 0x00000000007adf1e in funcall_lambda (fun=XIL(0x1f3c955), nargs=2, arg_vector=0x1f4c5d5) at eval.c:3067
#16 0x00000000007acda3 in Ffuncall (nargs=3, args=0x7fffffffb910) at eval.c:2796
#17 0x00000000007abfcd in Fapply (nargs=2, args=0x7fffffffb9e0) at eval.c:2424
#18 0x00000000007ac64a in apply1 (fn=XIL(0xdc1ef0), arg=XIL(0x2358383)) at eval.c:2640
#19 0x00000000008461e6 in read_process_output_call (fun_and_args=XIL(0x2358373)) at process.c:5988
#20 0x00000000007a8f63 in internal_condition_case_1
    (bfun=0x846161 <read_process_output_call>, arg=XIL(0x2358373), handlers=XIL(0x90), hfun=0x8461e8 <read_process_output_error_handler>) at eval.c:1379
#21 0x0000000000846a6d in read_and_dispose_of_process_output
    (p=0x28b5220, chars=0x7fffffffbae0 "Folder: +inbox\nFilename: 633\nSubject: =?utf-8?B?5Y+j572p55Sf5Lqn5Y6C5a6277yM5Y+v6Zu25ZSu77yM5Y+v?=\n =?utf-8?B?5om55Y+R77yM5Lu35qC85YWs6YGT?=\nDate: 1 Apr 2020 20:03:36 +0800\nFrom: =?utf-8?Q?=E5=8F=A3=E"..., nbytes=1555, coding=0x2183800) at process.c:6209
#22 0x00000000008466b7 in read_process_output (proc=XIL(0x28b5225), channel=24) at process.c:6120
#23 0x000000000084597d in wait_reading_process_output (time_limit=52, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=XIL(0), wait_proc=0x0, just_wait_proc=0)
    at process.c:5807
#24 0x0000000000433b0b in sit_for (timeout=make_fixnum(52), reading=true, display_option=1) at dispnew.c:6052
#25 0x00000000006503fe in read_char (commandflag=1, map=XIL(0x2358603), prev_event=XIL(0), used_mouse_menu=0x7fffffffd43f, end_time=0x0) at keyboard.c:2738
#26 0x000000000066203e in read_key_sequence
    (keybuf=0x7fffffffd5e0, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9549
#27 0x000000000064bec5 in command_loop_1 () at keyboard.c:1350
#28 0x00000000007a8e8c in internal_condition_case (bfun=0x64ba65 <command_loop_1>, handlers=XIL(0x90), hfun=0x64b0a4 <cmd_error>) at eval.c:1355
#29 0x000000000064b673 in command_loop_2 (ignore=XIL(0)) at keyboard.c:1091
#30 0x00000000007a83a0 in internal_catch (tag=XIL(0xd110), func=0x64b64a <command_loop_2>, arg=XIL(0)) at eval.c:1116
#31 0x000000000064b615 in command_loop () at keyboard.c:1070
#32 0x000000000064abb6 in recursive_edit_1 () at keyboard.c:714
#33 0x000000000064ad98 in Frecursive_edit () at keyboard.c:786
#34 0x000000000064152c in main (argc=1, argv=0x7fffffffdab8) at emacs.c:2035

Lisp Backtrace:
"set-buffer-multibyte" (0xffffac80)
"mew-scan-body" (0xffffb3a0)
"mew-local-filter" (0xffffb918)

Re: intervals.c:1190: Emacs fatal error: assertion failed: amt == 0

[Eli Zaretskii]

> Date: Fri, 03 Apr 2020 13:02:26 +0200 (CEST)
> From: Werner LEMBERG <wl@gnu.org>
> 
> [f28166dc9a56111606be8ac50ad38179a66ea636 from today]
> 
> This bug is reproducible: I'm using 'mew' as my e-mail reader, and one
> of the inbox messages (already delivered as one file per message to a
> mew folder) causes the failure while the overview of e-mails gets
> (re)generated.

Thanks.  Any hope of having a reproducible recipe that doesn't
involve that particular message and/or mew?

Alternatively, does reverting dc3006cf1419e5b22c35fa36d79ba029d0482df1
make this problem go away?

Re: intervals.c:1190: Emacs fatal error: assertion failed: amt == 0

[Werner LEMBERG]

[-- Attachment #1: Type: Text/Plain, Size: 1115 bytes --]


>> [f28166dc9a56111606be8ac50ad38179a66ea636 from today]
>> 
>> This bug is reproducible: I'm using 'mew' as my e-mail reader, and
>> one of the inbox messages (already delivered as one file per
>> message to a mew folder) causes the failure while the overview of
>> e-mails gets (re)generated.
> 
> Thanks.  Any hope of having a reproducible recipe that doesn't
> involve that particular message and/or mew?

Alas, no.  I'm willing to help with further analysis if you tell me
what to do.

I'm attaching the problematic e-mail; however, I decoded it with
'munpack -t' and also with a small perl script to get the header lines
in standard UTF8, and Emacs was able to read this data just fine.

For bisecting the issue, what date or commit do you suggest as the
starting point for testing?

> Alternatively, does reverting
> dc3006cf1419e5b22c35fa36d79ba029d0482df1 make this problem go away?

No, it doesn't.


    Werner


PS: If I call 'gdb ./emacs' in the build directory, which .elc files
    from Emacs are read and used?  The installed ones (from a previous
    installation), or the ones in the build tree?

[-- Attachment #2: Type: Message/Rfc822, Size: 5046 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 205 bytes --]

 
口罩生产厂家，可零售，可批发，价格公道
一箱2000个，每箱40盒，每盒50个
可按盒发货，欢迎咨询
 Q Q  : 3358399770E-mail: tel8888@hotmail.com
 

[-- Attachment #2.1.2: Type: text/html, Size: 518 bytes --]

Re: intervals.c:1190: Emacs fatal error: assertion failed: amt == 0

[Eli Zaretskii]

> Date: Fri, 03 Apr 2020 15:27:21 +0200 (CEST)
> Cc: emacs-devel@gnu.org
> From: Werner LEMBERG <wl@gnu.org>
> 
> > Thanks.  Any hope of having a reproducible recipe that doesn't
> > involve that particular message and/or mew?
> 
> Alas, no.  I'm willing to help with further analysis if you tell me
> what to do.
> 
> I'm attaching the problematic e-mail; however, I decoded it with
> 'munpack -t' and also with a small perl script to get the header lines
> in standard UTF8, and Emacs was able to read this data just fine.
> 
> For bisecting the issue, what date or commit do you suggest as the
> starting point for testing?
> 
> > Alternatively, does reverting
> > dc3006cf1419e5b22c35fa36d79ba029d0482df1 make this problem go away?
> 
> No, it doesn't.

How about 31182c1d17f6f7bc946d5e4576e025c9b975e0b5?

If that doesn't help, either, I guess start from the branch point of
emacs-27, and if that version also exhibits the problem, try Emacs
26.3.

Thanks.

Re: intervals.c:1190: Emacs fatal error: assertion failed: amt == 0

[Werner LEMBERG]

> 
> How about 31182c1d17f6f7bc946d5e4576e025c9b975e0b5?

Will check soon.

> If that doesn't help, either, I guess start from the branch point of
> emacs-27, and if that version also exhibits the problem, try Emacs
> 26.3.

Thanks.  Do I have to run 'make install' to make emacs use a
revision's elisp files?  Or can this be safely ignored, just using
'gdb ./emacs' for testing each bisecting step?


    Werner

Re: intervals.c:1190: Emacs fatal error: assertion failed: amt == 0

[Eli Zaretskii]

> Date: Sat, 04 Apr 2020 12:16:48 +0200 (CEST)
> Cc: emacs-devel@gnu.org
> From: Werner LEMBERG <wl@gnu.org>
> 
> > If that doesn't help, either, I guess start from the branch point of
> > emacs-27, and if that version also exhibits the problem, try Emacs
> > 26.3.
> 
> Thanks.  Do I have to run 'make install' to make emacs use a
> revision's elisp files?  Or can this be safely ignored, just using
> 'gdb ./emacs' for testing each bisecting step?

You can safely run Emacs uninstalled, from the src directory where the
binary was built.  It will use the Lisp files from the same tree where
the src/emacs which you invoked lives.  (Sorry I didn't answer your
previous question about this.)

Re: intervals.c:1190: Emacs fatal error: assertion failed: amt == 0

[Werner LEMBERG]

> How about 31182c1d17f6f7bc946d5e4576e025c9b975e0b5?

Nope.

> If that doesn't help, either, I guess start from the branch point of
> emacs-27, and if that version also exhibits the problem, try Emacs
> 26.3.

I went back to emacs-26.1-rc1, and it crashed in the same manner.  I
tried to go back to emacs-26.0.90, but this older emacs didn't run mew
(complaining about an unsupported image mode; I guess I would have to
adjust the build options but I was too lazy).

So it seems to be an old problem.  How to proceed?


    Werner

Re: intervals.c:1190: Emacs fatal error: assertion failed: amt == 0

[Eli Zaretskii]

> Date: Sat, 04 Apr 2020 22:56:40 +0200 (CEST)
> Cc: emacs-devel@gnu.org
> From: Werner LEMBERG <wl@gnu.org>
> 
> I went back to emacs-26.1-rc1, and it crashed in the same manner.  I
> tried to go back to emacs-26.0.90, but this older emacs didn't run mew
> (complaining about an unsupported image mode; I guess I would have to
> adjust the build options but I was too lazy).
> 
> So it seems to be an old problem.  How to proceed?

A reproducing recipe sounds like the best approach.  Unless someone
could spot the problem just by looking at the code.

Thanks.

Re: intervals.c:1190: Emacs fatal error: assertion failed: amt == 0

[Werner LEMBERG]

[-- Attachment #1: Type: Text/Plain, Size: 940 bytes --]


> A reproducing recipe sounds like the best approach.  Unless someone
> could spot the problem just by looking at the code.

OK, here it is.

1. Save your '~/Mail' order in case you have one, then do

     mkdir Mail
     cd Mail
     mkdir inbox

   in your home directory.  Uncompress and copy the attached file
   '633.gz' into the just created 'inbox' directory.

2. Install mew.  I do this directly from the git repository.

     git clone git://github.com/kazu-yamamoto/Mew.git
     cd Mew
     ./configure
     make
     make install

   Let's assume this gets installed into the default location

     /usr/local/share/emacs/site-lisp/mew

3. Start emacs in 'src' directory with

     gdb --args ./emacs -Q

4. In the '*scratch*' buffer, evaluate

     (add-to-list 'load-path "/usr/local/share/emacs/site-lisp/mew")

5. Execute

     load-library mew
     mew

And voilà.


    Werner

[-- Attachment #2: 633.gz --]
[-- Type: Application/Octet-Stream, Size: 2065 bytes --]

Re: intervals.c:1190: Emacs fatal error: assertion failed: amt == 0

[Eli Zaretskii]

> Date: Sun, 05 Apr 2020 07:42:29 +0200 (CEST)
> Cc: emacs-devel@gnu.org
> From: Werner LEMBERG <wl@gnu.org>
> 
> 1. Save your '~/Mail' order in case you have one, then do
> 
>      mkdir Mail
>      cd Mail
>      mkdir inbox
> 
>    in your home directory.  Uncompress and copy the attached file
>    '633.gz' into the just created 'inbox' directory.
> 
> 2. Install mew.  I do this directly from the git repository.
> 
>      git clone git://github.com/kazu-yamamoto/Mew.git
>      cd Mew
>      ./configure
>      make
>      make install
> 
>    Let's assume this gets installed into the default location
> 
>      /usr/local/share/emacs/site-lisp/mew
> 
> 3. Start emacs in 'src' directory with
> 
>      gdb --args ./emacs -Q
> 
> 4. In the '*scratch*' buffer, evaluate
> 
>      (add-to-list 'load-path "/usr/local/share/emacs/site-lisp/mew")
> 
> 5. Execute
> 
>      load-library mew
>      mew
> 
> And voilà.

Thanks.  An 8-year old mystery that was left unsolved strikes back.

Does the patch below fix the problem for you?  It fixes the assertion
violation on my system, but the message comes out with some raw bytes,
and its coding-system is set to ctext, which sounds wrong (should be
UTF-8, I think).  Is this normal or expected for this particular
message?

Regarding the patch: a very similar issue was discussed here:

  https://lists.gnu.org/archive/html/emacs-devel/2012-07/msg00399.html

It started happening when the assertion was changed to reject negative
values.  At that time, Andreas (CC'ed) suggested a change that would
allow us to keep the amt == 0 assertion; maybe he will have a solution
along those lines in this case as well.  If not, I will install the
below on the emacs-27 branch some time soon.

Here's the patch:

diff --git a/src/intervals.c b/src/intervals.c
index a66594c..585ef18 100644
--- a/src/intervals.c
+++ b/src/intervals.c
@@ -1187,7 +1187,7 @@ delete_interval (register INTERVAL i)
   register INTERVAL parent;
   ptrdiff_t amt = LENGTH (i);
 
-  eassert (amt == 0);		/* Only used on zero-length intervals now.  */
+  eassert (amt <= 0);	/* Only used on zero total-length intervals now.  */
 
   if (ROOT_INTERVAL_P (i))
     {

Re: intervals.c:1190: Emacs fatal error: assertion failed: amt == 0

[Werner LEMBERG]

> Does the patch below fix the problem for you?

Yes, thanks.

> It fixes the assertion violation on my system, but the message comes
> out with some raw bytes, and its coding-system is set to ctext,
> which sounds wrong (should be UTF-8, I think).  Is this normal or
> expected for this particular message?

Everything looks as expected.


    Werner

Re: intervals.c:1190: Emacs fatal error: assertion failed: amt == 0

[Eli Zaretskii]

> Date: Mon, 06 Apr 2020 08:36:22 +0200 (CEST)
> Cc: emacs-devel@gnu.org, schwab@linux-m68k.org
> From: Werner LEMBERG <wl@gnu.org>
> 
> > Does the patch below fix the problem for you?
> 
> Yes, thanks.
> 
> > It fixes the assertion violation on my system, but the message comes
> > out with some raw bytes, and its coding-system is set to ctext,
> > which sounds wrong (should be UTF-8, I think).  Is this normal or
> > expected for this particular message?
> 
> Everything looks as expected.

Great, will install if no one comes up with a better idea.

Thanks.

Re: intervals.c:1190: Emacs fatal error: assertion failed: amt == 0

[Eli Zaretskii]

> Date: Mon, 06 Apr 2020 16:24:31 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: schwab@linux-m68k.org, emacs-devel@gnu.org
> 
> > Everything looks as expected.
> 
> Great, will install if no one comes up with a better idea.

No further comments, so I've now pushed this to the emacs-27 branch.