bug#6621: Emacs crash when trying to report emacs crash

[Yair F]

On Tue, Jul 13, 2010 at 8:57 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Tue, 13 Jul 2010 19:15:33 +0300
>> From: Yair F <yair.f.lists@gmail.com>
>> Cc: 6621@debbugs.gnu.org
>>
>> (gdb) frame 7
>> #7  0x0809c519 in get_next_display_element (it=0xbfffc338) at xdisp.c:6051
>> 6051              it->face_id = FACE_FOR_CHAR (it->f, face, it->c,
>> pos, it->string);
>> (gdb) pit
>> cur=150[276] pos=150[276] start=128[235] end=3160 stop=3160 face=13 MB
>> ch=[4195671,2]
>> vpos=6 hpos=15 y=102 lvy=561 x=98 vx=0-640 w=0 a+d=13+4=17 max=13+4=17
>
> Strange.  Looks like the iterator indeed loaded this value 4195671
> somehow.  But it claims that the character took 2 bytes, which is
> correct for HET, but incorrect for such large values.  Perhaps
> Handa-san will have ideas.
>

I found a shorter way to reproduce the problem :
1. start with emacs -Q
2. create a buffer
3. paste the first 7 lines from the file *without the newline*
4. while at EOB press enter
Emacs is now at a strange state: the cursor does not go to a new line
as expected,
 but C-x= reports column=0. going back to point 149 make the cursor invisible

Pressing return again crashes emacs with the flowing trace:
Breakpoint 1, abort () at emacs.c:430
430       kill (getpid (), SIGABRT);
(gdb) bt
#1  0x0809cd6b in set_iterator_to_next (it=0xbfffdee4, reseat_p=1) at
xdisp.c:6254
#2  0x0809ced6 in set_iterator_to_next (it=0xbfffdee4, reseat_p=1) at
xdisp.c:6301
#3  0x080c5db2 in display_line (it=0xbfffdee4) at xdisp.c:17764
#4  0x080af796 in redisplay_internal (preserve_echo_area=0) at xdisp.c:11855
#5  0x080acac9 in redisplay () at xdisp.c:11267
#6  0x0823d4bb in read_char (commandflag=1, nmaps=2, maps=0xbfffea70,
prev_event=142115250, used_mouse_menu=0xbfffebc4, end_time=0x0) at
keyboard.c:2544
#7  0x08250b39 in read_key_sequence (keybuf=0xbfffec7c, bufsize=30,
prompt=142115250, dont_downcase_last=0, can_return_switch_frame=1,
fix_current_buffer=1) at keyboard.c:9326
#8  0x0823a9ae in command_loop_1 () at keyboard.c:1618
#9  0x08307493 in internal_condition_case (bfun=0x823a105
<command_loop_1>, handlers=142145978, hfun=0x8239812 <cmd_error>) at
eval.c:1463
#10 0x08239d08 in command_loop_2 (ignore=142115250) at keyboard.c:1341
#11 0x08306ecd in internal_catch (tag=142144098, func=0x8239ce4
<command_loop_2>, arg=142115250) at eval.c:1207
#12 0x08239cc2 in command_loop () at keyboard.c:1320
#13 0x08238f1a in recursive_edit_1 () at keyboard.c:943
#14 0x08239436 in Frecursive_edit () at keyboard.c:1005
#15 0x0823709b in main (argc=2, argv=0xbffff3d4) at emacs.c:1778

Pasting the buffer without the Dagesh (05BC) and then pressing retun
causes emacs to
react normally. I suspect some Dagesh-EOL interaction here.