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

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

bug#12196: 24.1.50; setting cache-long-line-scans to non-nil freezes Ema


From: Michael Heerdegen
Subject: bug#12196: 24.1.50; setting cache-long-line-scans to non-nil freezes Emacs
Date: Sun, 26 Aug 2012 17:58:45 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

> Do you see a reference to bug#12196 in src/ChangeLog of that
> distribution?  If not, then my fix is not included.

Yes, I see it:

2012-08-15  Eli Zaretskii  <address@hidden>

        * region-cache.c (move_cache_gap): Update gap_len using the actual
        growth of the boundaries array.  Do not change cache_len.
        (Bug#12196)

> Does Emacs really freeze, or does it just do some prolonged operation?
> (And is your CPU really an i486?)  If you wait for a long time, does
> Emacs eventually recover and become responsive again?

No, it really freezes.  I can wait ten minutes and emacs doesn't become
responsive again.

uname says that my CPU is an i686.  To be honest, I don't know much
about hardware.  But I used the emacs-snapshot binaries nearly everyday
for many months without seeing any freezes besides these.

> If Emacs really freezes, attach a debugger to it when it does, type
> "bt" at the debugger's prompt, and post here everything the debugger
> displays in response.

Here is a backtrace:

#0  0x08167976 in buf_charpos_to_bytepos (b=0x8e72420, address@hidden) at 
marker.c:168
#1  0x08185005 in scan_buffer (address@hidden, start=32027, address@hidden, 
end=32089, 
    address@hidden, address@hidden, address@hidden, 
    address@hidden) at search.c:677
#2  0x08185777 in find_before_next_newline (from=27007, address@hidden, cnt=1) 
at search.c:945
#3  0x081a9b73 in Fline_end_position (n=<optimized out>) at editfns.c:808
#4  0x081afc83 in Ffuncall (nargs=1, args=0xbf9e4274) at eval.c:2837
#5  0x081e4c0b in exec_byte_code (bytestr=149365792, vector=202, 
maxdepth=149365792, 
    args_template=138855706, nargs=0, args=0x0) at bytecode.c:898
#6  0x081af7e7 in funcall_lambda (fun=137048477, address@hidden, 
    address@hidden) at eval.c:3069
#7  0x081afaca in Ffuncall (nargs=5, args=0xbf9e4434) at eval.c:2898
#8  0x081e4c0b in exec_byte_code (bytestr=149365792, vector=-1080146912, 
maxdepth=149365792, 
    args_template=5128, nargs=5, args=0xbf9e45d0) at bytecode.c:898
#9  0x081af6d3 in funcall_lambda (fun=140693133, address@hidden, 
    address@hidden) at eval.c:3003
#10 0x081afaca in Ffuncall (nargs=6, args=0xbf9e45cc) at eval.c:2898
#11 0x081e4c0b in exec_byte_code (bytestr=149365792, vector=0, 
maxdepth=149365792, args_template=0, 
    nargs=0, args=0xbf9e475c) at bytecode.c:898
#12 0x081af6d3 in funcall_lambda (fun=141473149, address@hidden, 
    address@hidden) at eval.c:3003
#13 0x081afaca in Ffuncall (nargs=1, args=0xbf9e4758) at eval.c:2898
#14 0x081e4c0b in exec_byte_code (bytestr=149365792, vector=-1080146088, 
maxdepth=149365792, 
    args_template=0, nargs=0, args=0xbf9e48f8) at bytecode.c:898
#15 0x081af6d3 in funcall_lambda (fun=148465485, address@hidden, 
    address@hidden) at eval.c:3003
#16 0x081afaca in Ffuncall (nargs=1, args=0xbf9e48f4) at eval.c:2898
#17 0x081e4c0b in exec_byte_code (bytestr=149365792, vector=-1080145676, 
maxdepth=149365792, 
    args_template=3076, nargs=2, args=0xbf9e4a98) at bytecode.c:898
#18 0x081af6d3 in funcall_lambda (fun=140201581, address@hidden, 
    address@hidden) at eval.c:3003
#19 0x081afaca in Ffuncall (nargs=3, args=0xbf9e4a94) at eval.c:2898
#20 0x081e4c0b in exec_byte_code (bytestr=149365792, vector=-1080145276, 
maxdepth=149365792, 
    args_template=2052, nargs=2, args=0xbf9e4c24) at bytecode.c:898
#21 0x081af6d3 in funcall_lambda (fun=141836477, address@hidden, 
    address@hidden) at eval.c:3003
#22 0x081afaca in Ffuncall (nargs=3, args=0xbf9e4c20) at eval.c:2898
#23 0x081e4c0b in exec_byte_code (bytestr=149365792, vector=0, 
maxdepth=149365792, args_template=2052, 
    nargs=2, args=0xbf9e4d94) at bytecode.c:898
#24 0x081af6d3 in funcall_lambda (fun=141773429, address@hidden, 
    address@hidden) at eval.c:3003
#25 0x081afaca in Ffuncall (address@hidden, address@hidden) at eval.c:2898
#26 0x081b0b33 in Fapply (address@hidden, address@hidden) at eval.c:2343
#27 0x081b007f in apply1 (address@hidden, address@hidden) at eval.c:2581
#28 0x081abecd in Fcall_interactively (function=140543522, 
record_flag=138855706, keys=138864797)
    at callint.c:378
#29 0x081afc62 in Ffuncall (address@hidden, address@hidden) at eval.c:2844
#30 0x081aff27 in call3 (fn=138934218, arg1=140543522, arg2=138855706, 
arg3=138855706) at eval.c:2638
#31 0x0813e6f5 in Fcommand_execute (cmd=138934218, record_flag=140543522, 
keys=138855706, 
    special=138855706) at keyboard.c:10375
#32 0x0814ac63 in command_loop_1 () at keyboard.c:1639
#33 0x081ae230 in internal_condition_case (address@hidden <command_loop_1>, 
    handlers=138889274, address@hidden <cmd_error>) at eval.c:1322
#34 0x0813f745 in command_loop_2 (address@hidden) at keyboard.c:1204
#35 0x081ae15b in internal_catch (tag=138887250, address@hidden 
<command_loop_2>, 
    arg=138855706) at eval.c:1079
#36 0x081404aa in command_loop () at keyboard.c:1183
#37 recursive_edit_1 () at keyboard.c:804
#38 0x0814079a in Frecursive_edit () at keyboard.c:868
#39 0x0805acb0 in main (argc=<optimized out>, argv=0xbf9e5644) at emacs.c:1662

> Then try to follow the advice in etc/DEBUG,
> under "If the symptom of the bug is that Emacs fails to respond", to
> establish which Emacs function, if any, is looping.

Since Christopher can also reproduce this problem, and since he surely
is a greater help here, I would prefer if you could work with him.


Thanks,

Michael.





reply via email to

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