bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#17269: 24.3.90; assertion failure at buf_charpos_to_bytepos (marker.


From: Nicolas Richard
Subject: bug#17269: 24.3.90; assertion failure at buf_charpos_to_bytepos (marker.c)
Date: Tue, 15 Apr 2014 18:11:59 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.1

Le 15/04/2014 17:53, Eli Zaretskii a écrit :
>> From: Nicolas Richard <address@hidden>
>> Date: Tue, 15 Apr 2014 16:28:32 +0200
>> 
>> I got this today (I was running without --enable-checking until today).
>> 
>> I still have that session open in case you want more info.
>> 
>> Also, as a side note, in the current buffer (in which I'm reporting the
>> bug), I see problems like <end> going five to 5 to 10 lines below
>> current position. Apparently, it happens after I use C-k (kill-line). It
>> goes way when setting (setq cache-long-line-scans nil). I guess the
>> crash and this problem are related ?
> 
> It's related, but can you reproduce this in "emacs -Q"?

Not yet, but it seems to be triggered by the bug report because it just 
happened again. I'll look at it later. I have to run now.

> 
>> I'm running emacs-24 branch at commit
>> ef5b917 * savannah/emacs-24 Fix relative links to parent directories in shr
>> *but* I also have applied Paul Eggert's patch mentionned in bug#17172
> 
> Not sure what this means, Paul made several commits during the last 2
> days.  Can you be more specific (or even state the bzr revision
> number)?

>From the comment you left there, I guess you found it. I'm referring to 
>http://permalink.gmane.org/gmane.emacs.bugs/88024.

>> Breakpoint 1, terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at 
>> emacs.c:351
>> 351    signal (sig, SIG_DFL);
>> #0  terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at 
>> emacs.c:351
>> #1  0x081f581f in die (msg=0x83079dc "BUF_BEG (b) <= charpos && charpos <= 
>> BUF_Z (b)", file=0x83079d0 "marker.c", line=145) at alloc.c:6826
>> #2  0x081bc08d in buf_charpos_to_bytepos (b=0x9b42080, charpos=14233) at 
>> marker.c:145
>> #3  0x081d7c59 in find_newline (start=14230, start_byte=14230, end=14231, 
>> end_byte=14231, count=1, shortage=0xbfffdcd4, bytepos=0x0, allow_quit=true) 
>> at search.c:780
>> #4  0x081d845f in find_before_next_newline (from=14224, to=0, cnt=1, 
>> bytepos=0x0) at search.c:1006
>> #5  0x082019e6 in Fline_end_position (n=4) at editfns.c:813
>> #6  0x081ceff0 in Fend_of_line (n=4) at cmds.c:199
> 
> What is the value of BUF_Z(b) in frame #2?

(gdb) f 2
#2  0x081bc08d in buf_charpos_to_bytepos (b=0x9b42080, charpos=14233) at 
marker.c:145
145       eassert (BUF_BEG (b) <= charpos && charpos <= BUF_Z (b));
(gdb) p BUF_Z(b)
$1 = 14231
(gdb) xpr
Lisp_Float
Cannot access memory at address 0x3790

Perhaps I'm using the wrong command ?

> Also, what is the major mode in the buffer in question?

Could you tell me how to find out with gdb ?

-- 
Nicolas.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]