* Redisplay crash
@ 2005-01-03 19:32 Romain Francoise
2005-01-04 1:05 ` Kenichi Handa
0 siblings, 1 reply; 13+ messages in thread
From: Romain Francoise @ 2005-01-03 19:32 UTC (permalink / raw)
Running Emacs CVS from a few hours ago, I get a segmentation fault every
time I try to enter a group in Gnus (using emacs -nw, I didn't try in
X11). It's very reproducible. I last updated before that in October
2004 so the bug might not be recent.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1485880672 (LWP 8907)]
0xa7883051 in mallopt () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0 0xa7883051 in mallopt () from /lib/tls/i686/cmov/libc.so.6
#1 0xa7881d65 in realloc () from /lib/tls/i686/cmov/libc.so.6
#2 0x081685ab in emacs_blocked_realloc (ptr=0x958d590, size=388)
at alloc.c:1279
#3 0xa7881c9c in realloc () from /lib/tls/i686/cmov/libc.so.6
#4 0x08168123 in xrealloc (block=0x6d353358, size=25) at alloc.c:758
#5 0x080e0e53 in encode_terminal_code (src=0xa76f0f08, src_len=156816800,
coding=0x8323200) at term.c:904
#6 0x080e2c9c in write_glyphs (string=0xa76f0ea8, len=43) at term.c:970
#7 0x080888b8 in update_frame_line (f=0x8341060, vpos=1) at dispnew.c:5656
#8 0x08088c88 in update_frame (f=0x8341060, force_p=0, inhibit_hairy_id_p=0)
at dispnew.c:5154
#9 0x080aa922 in redisplay_internal (preserve_echo_area=1832203096)
at xdisp.c:10288
#10 0x08124535 in read_char (commandflag=1, nmaps=4, maps=0xafffed70,
prev_event=137568273, used_mouse_menu=0xafffedb8) at keyboard.c:2537
#11 0x081271c5 in read_key_sequence (keybuf=0xafffeed0, bufsize=30,
prompt=137568273, dont_downcase_last=0, can_return_switch_frame=1,
fix_current_buffer=1) at keyboard.c:8818
#12 0x08128bb7 in command_loop_1 () at keyboard.c:1531
#13 0x0817e2ba in internal_condition_case (bfun=0x8128a10 <command_loop_1>,
handlers=137629265, hfun=0x8122590 <cmd_error>) at eval.c:1385
#14 0x0811caa6 in command_loop_2 () at keyboard.c:1312
#15 0x0817e1ba in internal_catch (tag=1832203096,
func=0x811ca80 <command_loop_2>, arg=137568273) at eval.c:1144
#16 0x0811c887 in command_loop () at keyboard.c:1291
#17 0x0811c920 in recursive_edit_1 () at keyboard.c:984
#18 0x0811ca3a in Frecursive_edit () at keyboard.c:1045
#19 0x0811bd03 in main (argc=2, argv=0xaffff4d4) at emacs.c:1763
(gdb)
--
Romain Francoise <romain@orebokech.com> | I'm going out for a little
it's a miracle -- http://orebokech.com/ | drive, and it may be the last
| time you see me alive.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Redisplay crash
2005-01-03 19:32 Redisplay crash Romain Francoise
@ 2005-01-04 1:05 ` Kenichi Handa
2005-01-04 20:46 ` Romain Francoise
0 siblings, 1 reply; 13+ messages in thread
From: Kenichi Handa @ 2005-01-04 1:05 UTC (permalink / raw)
Cc: emacs-devel
In article <87llbal35x.fsf@orebokech.com>, Romain Francoise <romain@orebokech.com> writes:
> Running Emacs CVS from a few hours ago, I get a segmentation fault every
> time I try to enter a group in Gnus (using emacs -nw, I didn't try in
> X11). It's very reproducible. I last updated before that in October
> 2004 so the bug might not be recent.
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1485880672 (LWP 8907)]
> 0xa7883051 in mallopt () from /lib/tls/i686/cmov/libc.so.6
> (gdb) bt
> #0 0xa7883051 in mallopt () from /lib/tls/i686/cmov/libc.so.6
> #1 0xa7881d65 in realloc () from /lib/tls/i686/cmov/libc.so.6
> #2 0x081685ab in emacs_blocked_realloc (ptr=0x958d590, size=388)
> at alloc.c:1279
> #3 0xa7881c9c in realloc () from /lib/tls/i686/cmov/libc.so.6
> #4 0x08168123 in xrealloc (block=0x6d353358, size=25) at alloc.c:758
> #5 0x080e0e53 in encode_terminal_code (src=0xa76f0f08, src_len=156816800,
> coding=0x8323200) at term.c:904
> #6 0x080e2c9c in write_glyphs (string=0xa76f0ea8, len=43) at term.c:970
I can't reproduce this bug, but I seems that my change to
encode_terminal_code on 2004-11-30 is the cause. At least
the argument `src_len' of encode_terminal_code has strange
value in your backtrace. Could you try to find out why it
has that value by debugger?
---
Ken'ichi HANDA
handa@m17n.org
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Redisplay crash
2005-01-04 1:05 ` Kenichi Handa
@ 2005-01-04 20:46 ` Romain Francoise
2005-01-05 20:49 ` Romain Francoise
0 siblings, 1 reply; 13+ messages in thread
From: Romain Francoise @ 2005-01-04 20:46 UTC (permalink / raw)
Cc: emacs-devel
Kenichi Handa <handa@m17n.org> writes:
> I can't reproduce this bug, but I seems that my change to
> encode_terminal_code on 2004-11-30 is the cause.
Indeed if I revert term.c to revision 1.156, the problem goes away.
> At least the argument `src_len' of encode_terminal_code has strange
> value in your backtrace. Could you try to find out why it has that
> value by debugger?
I tried but that value must come from stack corruption or some other
strangeness since in my tests, it always has reasonable values.. and
when the segfault occurs, it has the value 3 (in the one case I used to
reproduce the bug: entering gnu.emacs.gnus).
I will investigate further, any clues are welcome.
Also, I may be wrong, but it looks like the memory allocated in
encode_terminal_code is never freed. Or is it GC'ed?
--
Romain Francoise <romain@orebokech.com> | There's no stronger wind than
it's a miracle -- http://orebokech.com/ | the one that blows down a
| lonesome railroad line.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Redisplay crash
2005-01-04 20:46 ` Romain Francoise
@ 2005-01-05 20:49 ` Romain Francoise
2005-01-05 21:49 ` Romain Francoise
2005-01-06 0:56 ` Kenichi Handa
0 siblings, 2 replies; 13+ messages in thread
From: Romain Francoise @ 2005-01-05 20:49 UTC (permalink / raw)
Cc: handa
Romain Francoise <romain@orebokech.com> writes:
> I will investigate further, any clues are welcome.
After further investigation... the problem lies on line 872 of term.c, I
think the size computation is backwards. In my tests, this code makes
the buffer shrink to something like 16 bytes. The following bcopy call
then writes way more than that, overflowing the buffer and overwriting
the libc memory block pointers and thus making the next call to xrealloc
(needed because the size was set to something too small for what we have
to decode) fail.
That test is probably meant to check if we have to grow the buffer, not
shrink it, so reversing it appears to be what was intended. At least it
fixes the crash for me, I've been running with that patch for some time
with success so far. What do you think?
2005-01-05 Romain Francoise <romain@orebokech.com>
* term.c (encode_terminal_code): Fix buffer size computation.
Index: term.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/term.c,v
retrieving revision 1.159
diff -c -r1.159 term.c
*** term.c 12 Dec 2004 03:31:00 -0000 1.159
--- term.c 5 Jan 2005 20:38:47 -0000
***************
*** 1,5 ****
/* Terminal control module for terminals described by TERMCAP
! Copyright (C) 1985, 86, 87, 93, 94, 95, 98, 2000, 2001, 2002
Free Software Foundation, Inc.
This file is part of GNU Emacs.
--- 1,5 ----
/* Terminal control module for terminals described by TERMCAP
! Copyright (C) 1985, 86, 87, 93, 94, 95, 98, 2000, 2001, 2002, 2005
Free Software Foundation, Inc.
This file is part of GNU Emacs.
***************
*** 869,875 ****
if (! STRING_MULTIBYTE (string))
string = string_to_multibyte (string);
nbytes = buf - encode_terminal_buf;
! if (nbytes + SBYTES (string) < encode_terminal_bufsize)
{
encode_terminal_bufsize = nbytes + SBYTES (string);
encode_terminal_buf = xrealloc (encode_terminal_buf,
--- 869,875 ----
if (! STRING_MULTIBYTE (string))
string = string_to_multibyte (string);
nbytes = buf - encode_terminal_buf;
! if (encode_terminal_bufsize < nbytes + SBYTES (string))
{
encode_terminal_bufsize = nbytes + SBYTES (string);
encode_terminal_buf = xrealloc (encode_terminal_buf,
--
Romain Francoise <romain@orebokech.com> | I just thought I'd go out
it's a miracle -- http://orebokech.com/ | with a little bit more style.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Redisplay crash
2005-01-05 20:49 ` Romain Francoise
@ 2005-01-05 21:49 ` Romain Francoise
2005-01-06 0:56 ` Kenichi Handa
1 sibling, 0 replies; 13+ messages in thread
From: Romain Francoise @ 2005-01-05 21:49 UTC (permalink / raw)
Romain Francoise <romain@orebokech.com> writes:
> The following bcopy call then writes way more than that, overflowing
> the buffer and overwriting the libc memory block pointers and thus
> making the next call to xrealloc (needed because the size was set to
> something too small for what we have to decode) fail.
Forget that, it's probably not the bcopy call that's doing it since it
doesn't write more than SBYTES (string) bytes. But the pointers *do*
get hosed one way or another...
--
Romain Francoise <romain@orebokech.com> | Why did you kill that poor
it's a miracle -- http://orebokech.com/ | old man, melody? She said,
| "He was never good to me"
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Redisplay crash
2005-01-05 20:49 ` Romain Francoise
2005-01-05 21:49 ` Romain Francoise
@ 2005-01-06 0:56 ` Kenichi Handa
1 sibling, 0 replies; 13+ messages in thread
From: Kenichi Handa @ 2005-01-06 0:56 UTC (permalink / raw)
Cc: emacs-devel
In article <878y77mwif.fsf@orebokech.com>, Romain Francoise <romain@orebokech.com> writes:
> After further investigation... the problem lies on line 872 of term.c, I
> think the size computation is backwards.
Ahhhh! Right. Thank you for finding that silly bug.
> 2005-01-05 Romain Francoise <romain@orebokech.com>
> * term.c (encode_terminal_code): Fix buffer size computation.
I've just installed your fix.
---
Ken'ichi HANDA
handa@m17n.org
^ permalink raw reply [flat|nested] 13+ messages in thread
* Compilation to native
@ 2004-03-10 16:25 Matthew Mundell
2004-03-20 21:52 ` Matthew Mundell
0 siblings, 1 reply; 13+ messages in thread
From: Matthew Mundell @ 2004-03-10 16:25 UTC (permalink / raw)
>From etc/TODO:
* Investigate using GNU Lightning or similar system for incremental
compilation of selected bytecode functions to subrs. Converting CCL
programs to native code is probably the first thing to try, though.
Is there any work towards this?
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Compilation to native
2004-03-10 16:25 Compilation to native Matthew Mundell
@ 2004-03-20 21:52 ` Matthew Mundell
2004-03-21 19:21 ` Richard Stallman
0 siblings, 1 reply; 13+ messages in thread
From: Matthew Mundell @ 2004-03-20 21:52 UTC (permalink / raw)
Matthew Mundell <matt@mundell.ukfsn.org> writes:
> >From etc/TODO:
>
> * Investigate using GNU Lightning or similar system for incremental
> compilation of selected bytecode functions to subrs. Converting CCL
> programs to native code is probably the first thing to try, though.
>
> Is there any work towards this?
Well, I have a start at generating native code from byte code at run
time, and invoking the code produced. It uses the GNU Lightning
macros. The generation is done in a modified copy of Fbyte_code,
called Fnative_compile_byte_code, by generating the code for each byte
code operation instead of performing the operation.
Enough is implemented to run the example function from the "Speed of
Byte-Code" node in the Elisp manual. The function is:
(defun silly-loop (n)
"Return time before and after N iterations of a loop."
(let ((t1 (current-time-string)))
(while (> (setq n (1- n))
0))
(list t1 (current-time-string))))
Here is a set of results:
(silly-loop 100000000)
=> ("Sat Feb 28 10:04:39 2004" "Sat Feb 28 10:05:30 2004") ; 51 secs
(byte-compile 'silly-loop)
(silly-loop 100000000)
=> ("Sat Feb 28 10:06:37 2004" "Sat Feb 28 10:06:53 2004") ; 16 secs
(native-compile 'silly-loop)
(silly-loop 100000000)
=> ("Sat Feb 28 10:17:13 2004" "Sat Feb 28 10:17:22 2004") ; 9 secs
The changes come to more than 25000 characters, so they're here:
http://www.mundell.ukfsn.org/native/bytecode.c.diff
http://www.mundell.ukfsn.org/native/eval.c.diff
http://www.mundell.ukfsn.org/native/lisp.h.diff
Alternatively, the full files are available:
http://www.mundell.ukfsn.org/native/bytecode.c
http://www.mundell.ukfsn.org/native/eval.c
http://www.mundell.ukfsn.org/native/lisp.h
Either way, this file is also required:
http://www.mundell.ukfsn.org/native/native.el
The changes require NO_UNION_TYPE to be set, USE_LSB_TAG to be clear,
and EMACS_INT to be an int. For now a fixed amount of memory is
allocated for the generated code.
Is this effort good enough to continue?
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Compilation to native
2004-03-20 21:52 ` Matthew Mundell
@ 2004-03-21 19:21 ` Richard Stallman
2004-03-22 16:54 ` Juri Linkov
0 siblings, 1 reply; 13+ messages in thread
From: Richard Stallman @ 2004-03-21 19:21 UTC (permalink / raw)
Cc: emacs-devel
(byte-compile 'silly-loop)
(silly-loop 100000000)
=> ("Sat Feb 28 10:06:37 2004" "Sat Feb 28 10:06:53 2004") ; 16 secs
(native-compile 'silly-loop)
(silly-loop 100000000)
=> ("Sat Feb 28 10:17:13 2004" "Sat Feb 28 10:17:22 2004") ; 9 secs
I don't think that a speedup of less than a factor of 2 would be worth
installing something that might take substantial maintenance effort.
However, it could be that this test is a bad test and doesn't really
show the benefit of compilation. Maybe this loop spends most of the
time inside current-time-string. How about trying something purely
computational?
The changes require NO_UNION_TYPE to be set, USE_LSB_TAG to be clear,
and EMACS_INT to be an int.
It will be necessary to remove these restrictions to make it ready to
install. However, there's no harm working initially on this case
and handling other cases later.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Compilation to native
2004-03-21 19:21 ` Richard Stallman
@ 2004-03-22 16:54 ` Juri Linkov
2004-03-23 17:47 ` Richard Stallman
0 siblings, 1 reply; 13+ messages in thread
From: Juri Linkov @ 2004-03-22 16:54 UTC (permalink / raw)
Cc: Matthew Mundell
Richard Stallman <rms@gnu.org> writes:
> I don't think that a speedup of less than a factor of 2 would be worth
> installing something that might take substantial maintenance effort.
Hmm, I expected more speedup given that it compiles to machine code.
Anyhow, while jit compilation of Emacs bytecode to native code would
be a far-reaching goal, the most urgent issue is with CCL programs.
Currently, CCL programs are unbearable slow. For example, opening
a 10MB UTF-8 file on a fast machine takes 5 min, while opening it
without conversion is performed instantly.
I thought about a different approach: predefined CCL programs
could be statically converted into C code and compiled by a C
compiler into Emacs core.
--
Juri Linkov
http://www.jurta.org/emacs/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Compilation to native
2004-03-22 16:54 ` Juri Linkov
@ 2004-03-23 17:47 ` Richard Stallman
2004-04-07 11:57 ` Kenichi Handa
0 siblings, 1 reply; 13+ messages in thread
From: Richard Stallman @ 2004-03-23 17:47 UTC (permalink / raw)
Cc: matt, emacs-devel
I thought about a different approach: predefined CCL programs
could be statically converted into C code and compiled by a C
compiler into Emacs core.
It is worth a try. On the other hand, I have to wonder
if the CCL interpreter could be faster.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Compilation to native
2004-03-23 17:47 ` Richard Stallman
@ 2004-04-07 11:57 ` Kenichi Handa
2004-04-07 12:45 ` David Kastrup
0 siblings, 1 reply; 13+ messages in thread
From: Kenichi Handa @ 2004-04-07 11:57 UTC (permalink / raw)
Cc: juri, matt, emacs-devel
In article <E1B5q0C-00039m-FD@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:
> I thought about a different approach: predefined CCL programs
> could be statically converted into C code and compiled by a C
> compiler into Emacs core.
> It is worth a try. On the other hand, I have to wonder
> if the CCL interpreter could be faster.
I think there's not much room of improvement in the CCL
interpreter (i.e. the function ccl_driver).
In addtion, in emacs-unicode, CCL is, by default, used only
for Ethiopic font encoding, and it can easily be changed not
to use CCL.
So, I think it's not that worth working on CCL interpreter.
---
Ken'ichi HANDA
handa@m17n.org
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Compilation to native
2004-04-07 11:57 ` Kenichi Handa
@ 2004-04-07 12:45 ` David Kastrup
2004-04-07 13:12 ` Kenichi Handa
0 siblings, 1 reply; 13+ messages in thread
From: David Kastrup @ 2004-04-07 12:45 UTC (permalink / raw)
Cc: juri, matt, rms, emacs-devel
Kenichi Handa <handa@m17n.org> writes:
> In article <E1B5q0C-00039m-FD@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:
>
> > I thought about a different approach: predefined CCL programs
> > could be statically converted into C code and compiled by a C
> > compiler into Emacs core.
>
> > It is worth a try. On the other hand, I have to wonder
> > if the CCL interpreter could be faster.
>
> I think there's not much room of improvement in the CCL
> interpreter (i.e. the function ccl_driver).
>
> In addtion, in emacs-unicode, CCL is, by default, used only
> for Ethiopic font encoding, and it can easily be changed not
> to use CCL.
>
> So, I think it's not that worth working on CCL interpreter.
If we have a development plan to switch to emacs-unicode soon. We
really need to get a grip about what should be in the next feature
release.
If the unicode and bidi branches are considerable usable, what are we
waiting for?
We are in the situation that currently for many purposes one has to
tell people "try using CVS". People get more and more to rely on it
for daily work. This situation is unhealthy. If things like
emacs-unicode and emacs-bidi are expected to cause longer-lasting
trouble, then we should crank out something like a full-featured 21.5
or so just before merging them. If the merge phase leads to longer
problems, we at least have a somewhat stable release to refer people
to while we are sorting the problems out.
If, on the other hand, users and developers of the unicode and bidi
branches are confident enough that under _normal_ use (i.e., if one
does not use bidi texts) stability should not be affected much, then
I'd say "what the heck, give it to us". Maintaining separate branches
for longer always leads to merging headaches.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Compilation to native
2004-04-07 12:45 ` David Kastrup
@ 2004-04-07 13:12 ` Kenichi Handa
2004-04-07 23:52 ` Alex Schroeder
0 siblings, 1 reply; 13+ messages in thread
From: Kenichi Handa @ 2004-04-07 13:12 UTC (permalink / raw)
Cc: juri, matt, rms, emacs-devel
In article <x5lll8554h.fsf@lola.goethe.zz>, David Kastrup <dak@gnu.org> writes:
> Kenichi Handa <handa@m17n.org> writes:
>> In article <E1B5q0C-00039m-FD@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:
>>
>> > I thought about a different approach: predefined CCL programs
>> > could be statically converted into C code and compiled by a C
>> > compiler into Emacs core.
>>
>> > It is worth a try. On the other hand, I have to wonder
>> > if the CCL interpreter could be faster.
>>
>> I think there's not much room of improvement in the CCL
>> interpreter (i.e. the function ccl_driver).
>>
>> In addtion, in emacs-unicode, CCL is, by default, used only
>> for Ethiopic font encoding, and it can easily be changed not
>> to use CCL.
>>
>> So, I think it's not that worth working on CCL interpreter.
> If we have a development plan to switch to emacs-unicode soon. We
> really need to get a grip about what should be in the next feature
> release.
> If the unicode and bidi branches are considerable usable, what are we
> waiting for?
I think Unicode branch is fairly usable in normal use. At
least it's stable enough for my daily work. But if it is
used with third party packages, I think some of them must be
adjusted for emacs-unicode.
Bidi branch is far from usable. I created that branch
mainly for that the other people can contribute. It's very
difficult to find a time to work on it for me.
> We are in the situation that currently for many purposes one has to
> tell people "try using CVS". People get more and more to rely on it
> for daily work. This situation is unhealthy. If things like
> emacs-unicode and emacs-bidi are expected to cause longer-lasting
> trouble, then we should crank out something like a full-featured 21.5
> or so just before merging them. If the merge phase leads to longer
> problems, we at least have a somewhat stable release to refer people
> to while we are sorting the problems out.
> If, on the other hand, users and developers of the unicode and bidi
> branches are confident enough that under _normal_ use (i.e., if one
> does not use bidi texts) stability should not be affected much, then
> I'd say "what the heck, give it to us". Maintaining separate branches
> for longer always leads to merging headaches.
I fully agree.
When I synchronized emacs-unicode branch to HEAD a half year
ago, it took about 10 days concentrated work. I think it
will need the same amount of work to merge emacs-unicode to
HEAD. If Richard says "go ahead", I'll manage to make that
time.
---
Ken'ichi HANDA
handa@m17n.org
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Compilation to native
2004-04-07 13:12 ` Kenichi Handa
@ 2004-04-07 23:52 ` Alex Schroeder
2004-04-08 2:35 ` It is time for a feature freeze (it is NOW or never) Kim F. Storm
0 siblings, 1 reply; 13+ messages in thread
From: Alex Schroeder @ 2004-04-07 23:52 UTC (permalink / raw)
Cc: juri, matt, dak, rms, emacs-devel
Kenichi Handa <handa@m17n.org> writes:
> I think Unicode branch is fairly usable in normal use. At
> least it's stable enough for my daily work. But if it is
> used with third party packages, I think some of them must be
> adjusted for emacs-unicode.
I used HEAD for several months, and have since switched to the unicode
branch for several months. I still experience a crash or two a month,
which is bad, but I cannot say I noticed any difference between the
two.
As for third party packages, I'm using the unicode branch with Gnus
and ERC (IRC client) for heavy duty work every day, so clearly I think
the Unicode branch is ready for merging, feature freeze, testing, and
release as soon as possible.
I must confess, however, that I have hoped all this time that the bidi
branch would be merged into the unicode branch, and that we'd release
the stuff as Emacs 22... Even fickle Arabic and Hebrew support is
better than no support at all... And for all it's worth, I've used
the bidi branch for IRC as well! :)
Alex.
--
.O. http://www.emacswiki.org/alex/
..O Schroeder's fourth law:
OOO None of your friends and coworkers share your taste in music.
^ permalink raw reply [flat|nested] 13+ messages in thread
* It is time for a feature freeze (it is NOW or never).
2004-04-07 23:52 ` Alex Schroeder
@ 2004-04-08 2:35 ` Kim F. Storm
2004-04-08 2:05 ` Miles Bader
0 siblings, 1 reply; 13+ messages in thread
From: Kim F. Storm @ 2004-04-08 2:35 UTC (permalink / raw)
Cc: emacs-devel
Alex Schroeder <alex@emacswiki.org> writes:
> Kenichi Handa <handa@m17n.org> writes:
>
> > I think Unicode branch is fairly usable in normal use. At
> > least it's stable enough for my daily work. But if it is
> > used with third party packages, I think some of them must be
> > adjusted for emacs-unicode.
>
> I used HEAD for several months, and have since switched to the unicode
> branch for several months. I still experience a crash or two a month,
> which is bad, but I cannot say I noticed any difference between the
> two.
>
> I must confess, however, that I have hoped all this time that the bidi
> branch would be merged into the unicode branch, and that we'd release
> the stuff as Emacs 22... Even fickle Arabic and Hebrew support is
> better than no support at all... And for all it's worth, I've used
> the bidi branch for IRC as well! :)
I also think that unicode and bidi belongs in 22.1 => which is why
they should NOT be merged at this time.
I suggest that we make a complete feature freeze on HEAD for 21.4 NOW !!!
Thus, we allow just bug fixes, and minor adjustments to new features
(in case current interface/implementation is sub-optimal or unclean).
Eg. if there are still some issues with the new compile.el, do
whatever is necessary to fix them.
New packages that we have already decided to add may also still go in.
And of course, we should get the remaining documentation tasks done
(getting new stuff in NEWS into the manuals).
Besides that, our efforts should concentrate on ironing out the (few?)
remaning unsolved reports about crashes in CVS head.
We should aim at doing the first pre-test in approx. 1 month (no later
than June 1st).
WHY?
Current HEAD is rock-solid for normal use, and I don't think it will
can be much better in that respect (but we should try!). I suppose we
have all used it in our daily work for [too] many months already, and
so have numerous anonymous users who need - or just like - the new
features of 21.4.
Also, people (notably Luc) have spent quite some time proof-reading
the current documentation on HEAD, so docs are also in a pretty
consistent state.
Consequently, we should be able to have an expedited pre-test phase,
as many parts of the code has already received extensive testing by a
much broader audience than any previous pre-test versions of emacs.
If we don't do it now, and start merging unicode and bidi to HEAD, I
fear that a 22.1 release is at least 1 year further into the future --
and that CVS HEAD will go through a phase of lesser stable code than
we have been used to for quite some time (I'm not judging the quality
of the code on those branches, it's just that it hasn't been tested to
the same extent as HEAD, so we should expect problems).
It's time!!!
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: It is time for a feature freeze (it is NOW or never).
2004-04-08 2:35 ` It is time for a feature freeze (it is NOW or never) Kim F. Storm
@ 2004-04-08 2:05 ` Miles Bader
2004-04-08 2:34 ` Kenichi Handa
0 siblings, 1 reply; 13+ messages in thread
From: Miles Bader @ 2004-04-08 2:05 UTC (permalink / raw)
Cc: rms, emacs-devel
On Thu, Apr 08, 2004 at 04:35:15AM +0200, Kim F. Storm wrote:
> Current HEAD is rock-solid for normal use, and I don't think it will
> can be much better in that respect (but we should try!).
This may be a false warning for HEAD (I run my own branch which has a fair
number of redisplay changes), but just in case:
I've had several crashes recently related to i-search faces, and haven't been
able to track down the cause; it appears that the face cache ids are being
used even after the face cache has been cleared.
-Miles
--
`Suppose Korea goes to the World Cup final against Japan and wins,' Moon said.
`All the past could be forgiven.' [NYT]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: It is time for a feature freeze (it is NOW or never).
2004-04-08 2:05 ` Miles Bader
@ 2004-04-08 2:34 ` Kenichi Handa
2004-04-08 16:30 ` Redisplay crash Stefan Monnier
0 siblings, 1 reply; 13+ messages in thread
From: Kenichi Handa @ 2004-04-08 2:34 UTC (permalink / raw)
Cc: emacs-devel, rms, storm
In article <20040408020537.GA22508@fencepost>, Miles Bader <miles@gnu.org> writes:
> On Thu, Apr 08, 2004 at 04:35:15AM +0200, Kim F. Storm wrote:
>> Current HEAD is rock-solid for normal use, and I don't think it will
>> can be much better in that respect (but we should try!).
> This may be a false warning for HEAD (I run my own branch which has a fair
> number of redisplay changes), but just in case:
> I've had several crashes recently related to i-search faces, and haven't been
> able to track down the cause; it appears that the face cache ids are being
> used even after the face cache has been cleared.
In emacs-unicode, I also met the similar bug. Emacs crashed
at the end of get_glyph_face_and_encoding. In this
function, FACE_FROM_ID (f, glyph->face_id) returned NULL,
thus, the macro call PREPARE_FACE_FOR_DISPLAY at the end led
to the crash. Though, this happens very very rarely.
As emacs-unicode-2 was branched after a big change in
display code, it's possible that we are seeing the same bug.
---
Ken'ichi HANDA
handa@m17n.org
^ permalink raw reply [flat|nested] 13+ messages in thread
* Redisplay crash
2004-04-08 2:34 ` Kenichi Handa
@ 2004-04-08 16:30 ` Stefan Monnier
2004-04-09 1:57 ` Kenichi Handa
2004-04-09 22:44 ` Richard Stallman
0 siblings, 2 replies; 13+ messages in thread
From: Stefan Monnier @ 2004-04-08 16:30 UTC (permalink / raw)
Cc: emacs-devel, rms, storm, miles
>>> Current HEAD is rock-solid for normal use, and I don't think it will
>>> can be much better in that respect (but we should try!).
>> This may be a false warning for HEAD (I run my own branch which has a fair
>> number of redisplay changes), but just in case:
>> I've had several crashes recently related to i-search faces, and haven't been
>> able to track down the cause; it appears that the face cache ids are being
>> used even after the face cache has been cleared.
> In emacs-unicode, I also met the similar bug. Emacs crashed
> at the end of get_glyph_face_and_encoding. In this
> function, FACE_FROM_ID (f, glyph->face_id) returned NULL,
> thus, the macro call PREPARE_FACE_FOR_DISPLAY at the end led
> to the crash. Though, this happens very very rarely.
I've had such problems in the past.
There was a discussion about it with Gerd which led to
2002-08-27 Gerd Moellmann <gerd.moellmann@t-online.de>
* xdisp.c (redisplay_updating_p): Variable removed.
(inhibit_free_realized_faces, Qinhibit_free_realized_faces):
New variables.
(init_iterator): Don't free realized faces if
inhibit_free_realized_faces is set.
(redisplay_internal): Bind Qinhibit_free_realized_faces to nil.
(syms_of_xdisp): DEFVAR_BOOL inhibit-free-realized-faces,
initialize Qinhibit_free_realized_faces.
* dispextern.h (PRODUCE_GLYPHS): Set inhibit_free_realized_faces
when iterator is adding glyphs to a glyph matrix.
I can't find trace of this discussion, tho.
I've always had the impression that the above patch didn't really fix the
problem, tho it made it less frequent, so maybe it only hid the problem
more than fix it, I don't know. In any case I figure maybe you'd like
to know.
Stefan
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Redisplay crash
2004-04-08 16:30 ` Redisplay crash Stefan Monnier
@ 2004-04-09 1:57 ` Kenichi Handa
2004-04-13 10:00 ` Piet van Oostrum
2004-04-18 21:47 ` Richard Stallman
2004-04-09 22:44 ` Richard Stallman
1 sibling, 2 replies; 13+ messages in thread
From: Kenichi Handa @ 2004-04-09 1:57 UTC (permalink / raw)
Cc: emacs-devel, rms, storm, miles
In article <87r7uyfoz9.fsf-monnier+emacs@alfajor.local>, Stefan Monnier <monnier@iro.umontreal.ca> writes:
> There was a discussion about it with Gerd which led to
> 2002-08-27 Gerd Moellmann <gerd.moellmann@t-online.de>
> * xdisp.c (redisplay_updating_p): Variable removed.
> (inhibit_free_realized_faces, Qinhibit_free_realized_faces):
> New variables.
> (init_iterator): Don't free realized faces if
> inhibit_free_realized_faces is set.
> (redisplay_internal): Bind Qinhibit_free_realized_faces to nil.
> (syms_of_xdisp): DEFVAR_BOOL inhibit-free-realized-faces,
> initialize Qinhibit_free_realized_faces.
> * dispextern.h (PRODUCE_GLYPHS): Set inhibit_free_realized_faces
> when iterator is adding glyphs to a glyph matrix.
> I can't find trace of this discussion, tho.
> I've always had the impression that the above patch didn't really fix the
> problem, tho it made it less frequent, so maybe it only hid the problem
> more than fix it, I don't know. In any case I figure maybe you'd like
> to know.
Thank you for the info. I found at least one way to crash
Emacs constantly.
At first, evaluate this in *scratch* buffer.
(put-text-property 2 3 'display '(when (clear-face-cache t)))
Then, type C-h h C-x C-k (i.e. view HELLO file and kill that
buffer).
Then, Emacs crashes in get_next_display_element at:
/* Adjust face id for a multibyte character. There are no
multibyte character in unibyte text. */
if (it->multibyte_p
&& success_p
&& FRAME_WINDOW_P (it->f))
{
struct face *face = FACE_FROM_ID (it->f, it->face_id);
here-> it->face_id = FACE_FOR_CHAR (it->f, face, it->c);
}
because FACE_FROM_ID returns NULL.
But, it seems that this is a different bug.
---
Ken'ichi HANDA
handa@m17n.org
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Redisplay crash
2004-04-09 1:57 ` Kenichi Handa
@ 2004-04-13 10:00 ` Piet van Oostrum
2004-04-18 21:47 ` Richard Stallman
1 sibling, 0 replies; 13+ messages in thread
From: Piet van Oostrum @ 2004-04-13 10:00 UTC (permalink / raw)
>>>>> Kenichi Handa <handa@m17n.org> (KH) wrote:
KH> Thank you for the info. I found at least one way to crash
KH> Emacs constantly.
KH> At first, evaluate this in *scratch* buffer.
KH> (put-text-property 2 3 'display '(when (clear-face-cache t)))
KH> Then, type C-h h C-x C-k (i.e. view HELLO file and kill that
KH> buffer).
For me, on Mac OS X, the first step alone will already crash emacs.
This is the backtrace:
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x00021054 in get_next_display_element (it=0xbfffd430) at xdisp.c:4948
4948 it->face_id = FACE_FOR_CHAR (it->f, face, it->c);
(gdb) bt
#0 0x00021054 in get_next_display_element (it=0xbfffd430) at xdisp.c:4948
#1 0x00021970 in next_element_from_buffer (it=0xbfffd430) at xdisp.c:5436
#2 0x00020cc0 in get_next_display_element (it=0xbfffd430) at xdisp.c:4787
#3 0x00031520 in display_line (it=0xbfffd430) at xdisp.c:14411
#4 0x0002d6c4 in try_window (window=10719952, pos={charpos = 1, bytepos = 1}) at xdisp.c:12140
#5 0x0002c820 in redisplay_window (window=-2110188656, just_this_one_p=0) at xdisp.c:11783
#6 0x00029978 in redisplay_window_0 (window=10719952) at xdisp.c:10538
#7 0x000e0cc0 in internal_condition_case_1 (bfun=0x2993c <redisplay_window_0>, arg=-2110188656, handlers=-1604078312, hfun=0x29908 <redisplay_window_error>) at eval.c:1374
#8 0x000298e0 in redisplay_windows (window=0) at xdisp.c:10517
#9 0x000298c0 in redisplay_windows (window=0) at xdisp.c:10511
#10 0x00028f20 in redisplay_internal (preserve_echo_area=10719952) at xdisp.c:10102
#11 0x0007e24c in read_char (commandflag=1, nmaps=3, maps=0xbfffecc0, prev_event=595592192, used_mouse_menu=0xbfffedc4) at keyboard.c:2472
#12 0x0008686c in read_key_sequence (keybuf=0x34b6f4, bufsize=3505968, prompt=-2110188656, dont_downcase_last=-1821406164, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:8770
#13 0x0007c01c in command_loop_1 () at keyboard.c:1476
#14 0x000e0b54 in internal_condition_case (bfun=0x7bb60 <command_loop_1>, handlers=595637240, hfun=0x7b560 <cmd_error>) at eval.c:1333
#15 0x0007b988 in command_loop_2 () at keyboard.c:1264
#16 0x000e05bc in internal_catch (tag=10719952, func=0x7b948 <command_loop_2>, arg=595592192) at eval.c:1094
#17 0x0007b8e0 in command_loop () at keyboard.c:1243
#18 0x0007b2fc in recursive_edit_1 () at keyboard.c:959
#19 0x0007b484 in Frecursive_edit () at keyboard.c:1015
#20 0x00079fac in main (argc=3510216, argv=0x3565ac) at emacs.c:1692
(gdb) quit
--
Piet van Oostrum <piet@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP]
Private email: P.van.Oostrum@hccnet.nl
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Redisplay crash
2004-04-09 1:57 ` Kenichi Handa
2004-04-13 10:00 ` Piet van Oostrum
@ 2004-04-18 21:47 ` Richard Stallman
1 sibling, 0 replies; 13+ messages in thread
From: Richard Stallman @ 2004-04-18 21:47 UTC (permalink / raw)
Cc: miles, storm, monnier, emacs-devel
(put-text-property 2 3 'display '(when (clear-face-cache t)))
Then, type C-h h C-x C-k (i.e. view HELLO file and kill that
buffer).
Then, Emacs crashes in get_next_display_element at:
Has anyone investigated this bug?
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Redisplay crash
2004-04-08 16:30 ` Redisplay crash Stefan Monnier
2004-04-09 1:57 ` Kenichi Handa
@ 2004-04-09 22:44 ` Richard Stallman
2004-04-10 18:36 ` Kim F. Storm
1 sibling, 1 reply; 13+ messages in thread
From: Richard Stallman @ 2004-04-09 22:44 UTC (permalink / raw)
Cc: miles, emacs-devel, storm, handa
I've had such problems in the past.
There was a discussion about it with Gerd which led to
2002-08-27 Gerd Moellmann <gerd.moellmann@t-online.de>
Perhaps we need to record history information about occurrences
within redisplay, so that after it crashes we can investigate
what happened without needing to find a reproducible test case.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Redisplay crash
2004-04-09 22:44 ` Richard Stallman
@ 2004-04-10 18:36 ` Kim F. Storm
2004-04-12 3:52 ` Richard Stallman
0 siblings, 1 reply; 13+ messages in thread
From: Kim F. Storm @ 2004-04-10 18:36 UTC (permalink / raw)
Cc: emacs-devel
Richard Stallman <rms@gnu.org> writes:
> I've had such problems in the past.
> There was a discussion about it with Gerd which led to
>
> 2002-08-27 Gerd Moellmann <gerd.moellmann@t-online.de>
>
> Perhaps we need to record history information about occurrences
> within redisplay, so that after it crashes we can investigate
> what happened without needing to find a reproducible test case.
I don't think it will be worth the efforts.
There is just so much going on during redisplay, that it is almost
impossible to know what and how much information to put into the
history. I have used various methods of collecting history during
redisplay to track down display errors, even when doing a targeted
information collection, it is very difficult to actually use that
history to find bugs.
It is always better to have a specific test case and debug the code to
find the cause of the error.
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Redisplay crash
2004-04-10 18:36 ` Kim F. Storm
@ 2004-04-12 3:52 ` Richard Stallman
0 siblings, 0 replies; 13+ messages in thread
From: Richard Stallman @ 2004-04-12 3:52 UTC (permalink / raw)
Cc: emacs-devel
> Perhaps we need to record history information about occurrences
> within redisplay, so that after it crashes we can investigate
> what happened without needing to find a reproducible test case.
I don't think it will be worth the efforts.
It is always better to have a specific test case and debug the code to
find the cause of the error.
It is surely better to have a specific test case; the problem is
that sometimes we don't have one and nobody can find one.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2005-01-06 0:56 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-01-03 19:32 Redisplay crash Romain Francoise
2005-01-04 1:05 ` Kenichi Handa
2005-01-04 20:46 ` Romain Francoise
2005-01-05 20:49 ` Romain Francoise
2005-01-05 21:49 ` Romain Francoise
2005-01-06 0:56 ` Kenichi Handa
-- strict thread matches above, loose matches on Subject: below --
2004-03-10 16:25 Compilation to native Matthew Mundell
2004-03-20 21:52 ` Matthew Mundell
2004-03-21 19:21 ` Richard Stallman
2004-03-22 16:54 ` Juri Linkov
2004-03-23 17:47 ` Richard Stallman
2004-04-07 11:57 ` Kenichi Handa
2004-04-07 12:45 ` David Kastrup
2004-04-07 13:12 ` Kenichi Handa
2004-04-07 23:52 ` Alex Schroeder
2004-04-08 2:35 ` It is time for a feature freeze (it is NOW or never) Kim F. Storm
2004-04-08 2:05 ` Miles Bader
2004-04-08 2:34 ` Kenichi Handa
2004-04-08 16:30 ` Redisplay crash Stefan Monnier
2004-04-09 1:57 ` Kenichi Handa
2004-04-13 10:00 ` Piet van Oostrum
2004-04-18 21:47 ` Richard Stallman
2004-04-09 22:44 ` Richard Stallman
2004-04-10 18:36 ` Kim F. Storm
2004-04-12 3:52 ` Richard Stallman
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.