August 1999 - XEmacs-Beta - XEmacs Mailing List Archives

[line start cache] Re: XEmacs 21.1.4 crash (relatively often) on Solaris 2.7 sparc 25 years, 3 months

Jan Vroonhof

> Jan> P.S. Can you trigger the abort in this patch? > > An update: > > I've been running with your patched version for a while, and have > triggered the "cur_elt >= 0" assertion again a couple of times, but > have not triggered your assertion. Ah, %$#＠%!#$. There is one ! too many in this patch. Here is what I meant Index: redisplay.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs-20/src/redisplay.c,v retrieving revision 1.57 diff -u -u -r1.57 redisplay.c --- redisplay.c 1999/05/12 14:29:13 1.57 +++ redisplay.c 1999/08/12 19:37:53 ＠＠ -6245,6 +6245,19 ＠＠ lsc.end = dl->end_bufpos; lsc.height = dl->ascent + dl->descent; + { + struct buffer *buf = XBUFFER(w->buffer); + /* Paranaoid line start cache check */ + if (! (lsc.start <= BUF_BEGV(buf) || + BUF_FETCH_CHAR(buf,lsc.start - 1) == (Emchar) '\n')) + { + fprintf(stderr,"Wrong stuff in line start cache!\n" + "Supposedly begins at: %10s", + (char *)BUF_BYTE_ADDRESS(buf,lsc.start)); + assert(0); + } + } + Dynarr_add (internal_cache, lsc); } } However there is no need to run that. For me it crashes displaying the splash screen. The reason: a wrapped line. (Sorry if this gets technical) The problem is that \ when a line is wrap \ ped like this Then there are 3 display lines and the second 2 don't actually start at a new line in the buffer, just in the display. Previous line_start_cache rediplay crashes have all been of the type where code actually assumed that the line_start_cache actually contained lines starting at "\n", and we have fixed the triggers for that. It seems now that we better check these assumptions. i'm too tired now to have a real look. Gunnar Do you remember where that problem occured, was it also at asssert(cur_elt>=0)? Jan BTW Hamish, does the reproduction recipe at the end of http://www.xemacs.org/list-archives/xemacs-beta/9903/msg00475.html "work" for you?

1 participants
0 comments

Re: C-x C-f foo.jpg in XEmacs 21.1.3/21.2.19 25 years, 3 months

Jan Vroonhof

Kyle Jones <kyle_jones(a)wonderworks.com> writes: > The automatic image display goop was removed from format-alist > because it broke the world. Before 21.2 is released, someone > should put this stuff on auto-mode-alist. Alternatively the processing of format-alist should be moved from insert-file-contents to find-file. I like the fact the format-alist stuff is cookie based. In addition I think my insert-file-contents-literary as filename handler method patch should be integrated in 21.2 (It is awaiting review of the EFS part by Michael). Then certain MUA/NUA authors should be reeducated not to roll their own. Jan

1 participants
0 comments

new glibc2.1 [RH6.0] #include necessity 25 years, 3 months

Karl Kleinpaste

I built a new system last evening. RedHat's 6.0 Linux release contains glibc2.1. (5.x had 2.0.) The glibc freaks have chosen, for some reason which is thoroughly opaque to me, to instantiate a new subdirectory under /usr/include, /usr/include/db1, in which they have abandoned ndbm.h. As you might imagine, configure fails to find it. I first found this problem when building kth-krb and arla for this system (kth-krb's build dies a horrible death without ndbm.h), and cut off XEmacs' configure before it could express any more confusion when I saw this roll up the screen. Insuring that one has set CPATH=/usr/include/db1 during both configure and make will induce XEmacs to build as one expects. Or I suppose you could add --cflags=-I/usr/include/db1. And in fact the diff between my old RH5.1 Installation file and the new one under RH6.0 is trivial, regarding only the kernel name from uname(1), the directory where I'm building, and the fact that the latest XFree release has done away with the "/usr/X11" symlink. I don't know if configure can be coerced into adding an appropriate check to cover this automatically, or if this should merely go into the PROBLEMS file. BTW, "gcc -v" in RH6.0 says: "Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)" I haven't run XEmacs hard in the new environment yet (and this is for a home machine, where I build without error-checking) but it seems to run fine so far. --karl

1 participants
0 comments

Re: Another 21.2.19 crash 25 years, 3 months

Jan Vroonhof

Raymond Toy <toy(a)rtp.ericsson.se> writes: > I don't recall exactly what I was doing, even though it happened just > a minute ago. Some general editing and switching between two buffers > when Boom! xemacs crashes. Here is an untested (but obvious) fix: 1999-08-12 Jan Vroonhof <vroonhof(a)math.ethz.ch> * eval.c (run_hook_with_args_in_buffer): GCPRO globals. Index: eval.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/eval.c,v retrieving revision 1.27.2.2 diff -u -u -r1.27.2.2 eval.c --- eval.c 1999/06/22 18:02:51 1.27.2.2 +++ eval.c 1999/08/12 17:53:33 ＠＠ -3627,8 +3627,9 ＠＠ } else { - struct gcpro gcpro1, gcpro2; - GCPRO2 (sym, val); + struct gcpro gcpro1, gcpro2, gcpro3; + Lisp_Object globals = Qnil; + GCPRO3 (sym, val, globals); for (; CONSP (val) && ((cond == RUN_HOOKS_TO_COMPLETION) ＠＠ -3640,7 +3641,7 ＠＠ { /* t indicates this hook has a local binding; it means to run the global binding too. */ - Lisp_Object globals = Fdefault_value (sym); + globals = Fdefault_value (sym); if ((! CONSP (globals) || EQ (XCAR (globals), Qlambda)) && ! NILP (globals))

1 participants
0 comments

C-x C-f foo.jpg in XEmacs 21.1.3/21.2.19 25 years, 3 months

Marcus Thiessel

I switched from XEmacs 21.1.3 to 21.2.19 for daily use and ran into the following thing: When I try to open an image (gif, jpg etc.) the image appeared in 21.1.3 without complains. In 21.2.19 I get a 'symbols definition is void' and get a prompt for a crypt passwd. Regardless of what I type I get garbage. So I am wondering what has changed (I did not change my setup) and how to fix this. (Yes, maybe I missed something.) --Marcus

2 participants
1 comments

GCPRUG in run_hooks [was Re: Another 21.2.19 crash] 25 years, 3 months

Jan Vroonhof

[Note to FSF Emacs maintainers. This discusses an XEmacs bug. However, this code is identical to that in FSF Emacs 20.3. So it probably has the same bug] Raymond Toy <toy(a)rtp.ericsson.se> writes: > I have to say, b19 has been the least stable beta for me since 21.1 or > maybe even earlier. :-( He, its beta! Just be happy that there is new code to crash on. Anyway both of your crashes were real bugs. This one is even very old! In fact this bug is also in FSF 20.3 Something is in the global pre-command-hook that conses a lot I think. > #5 0xa3584 in assert_failed (file=0x2e11e0 "lisp.h", line=640, > expr=0x2e11e8 "RECORD_TYPEP (obj, &lrecord_cons) || MARKED_RECORD_P (obj)") at emacs.c:2672 > #6 0xae30c in run_hook_with_args_in_buffer (buf=0x3dc804, nargs=1, args=0xefffe060, > cond=RUN_HOOKS_TO_COMPLETION) at eval.c:3658 A typical (X)Emacs bug. A forgotten GCPRO. This the code is in run_hook_with_args_in_buffer /* t indicates this hook has a local binding; it means to run the global binding too. */ Lisp_Object globals = Fdefault_value (sym); [..] { for (; CONSP (globals) && ((cond == RUN_HOOKS_TO_COMPLETION) || (cond == RUN_HOOKS_UNTIL_SUCCESS ? NILP (ret) : !NILP (ret))); globals = XCDR (globals)) { args[0] = XCAR (globals); /* In a global value, t should not occur. If it does, we must ignore it to avoid an endless loop. */ if (!EQ (args[0], Qt)) ret = Ffuncall (nargs, args); } } } Note how 'globals' is allocated on the stack but never GCPRO'ed, but Ffuncall is called and this can garbage-collect. (The crash is in the XCDR(globals) ). Jan

1 participants
0 comments

Just wondering 25 years, 3 months

Charles G Waldman

Does anybody have any idea what ever happened to Kirill Katsnelson?

1 participants
0 comments

Re: doc-strings beginning with "*" 25 years, 3 months

Didier Verna

Charles G Waldman <cgw(a)fnal.gov> wrote: > Am I correct in assuming that this is a mistake? No. > Someone put in "*" at the beginning of the comment not realizing that it > would go into the docstring? Clever, I wouldn't have thought of this :-) > Or does the "*" at the beginning of the docstring have some meaning? Yes. From the info node of defvar: ,---- | If the first character of DOC-STRING is `*', it means that this | variable is considered a user option. This lets users set the | variable conveniently using the commands `set-variable' and | `edit-options'. `----- The usage of the star is often somewhat abusive though. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19

1 participants
0 comments

Re: System type w/gcc2.95 on RH6 (was: ridiculously long subject) 25 years, 3 months

Jan Vroonhof

Bless Terje <link(a)rito.no> writes: > ...I just built GCC 2.95 on a Red Hat 6.0 box and removed the egcs rpms. > This broke the config.guess (and thus breaks "configure") from XEmacs > 21.1.4. Somewhere in there it does a "ld --help" to extract the "supported > emulations". For some strange reason, it only finds "elf_i386" and not > "i386linux". I assume this is because ld's output format changed and the sed > filter breaks, but I don't speak sed so I'm not sure. Forcing > "i586-pc-linux" as an argument to "configure" works. Looking at the config.guess script it should _not_ find i386linux because that is a.out. Something else must be wrong. If I look at the latest config.guess at cygnus CVS then I see that they made the little test program they use to detect the architecture use ansi prototypes. i.e. the XEmacs config.guess has ==== # Determine whether the default compiler is a.out or elf cat >dummy.c <<EOF #include <features.h> main(argc, argv) int argc; char *argv[]; ==== Note the missing 'int' ==== cat >$dummy.c <<EOF #include <features.h> #ifdef __cplusplus int main (int argc, char *argv[]) { #else int main (argc, argv) int argc; char *argv[]; { #endif #ifdef __ELF__ # ifdef __GLIBC__ # if __GLIBC__ >= 2 printf ("%s-${VENDOR}-linux-gnu\n", argv[1]); # else ===== However the XEmacs version is identical to autoconf 2.13. Surely we would have know by now if every autoconf 2.13 based program stopped configuring correctly with gcc 2.95 on redhat. So I suggest you double check your gcc 2.95 install: Jan

1 participants
0 comments

doc-strings beginning with "*" 25 years, 3 months

Charles G Waldman

I've noticed that a lot of the doc-strings for functions and variables declared in C start with a "*". For example if I do C-h v bell-volume I get: `bell-volume' is a built-in integer variable. Value: 0 Documentation: *How loud to be, from 0 to 100. Looking at "sound.c" I see in vars_of_sound: DEFVAR_INT ("bell-volume", &bell_volume /* *How loud to be, from 0 to 100. */ ) Am I correct in assuming that this is a mistake? Someone put in "*" at the beginning of the comment not realizing that it would go into the docstring? Or should the DEFVAR_INT macro take care of this? Or does the "*" at the beginning of the docstring have some meaning? Inquiring minds want to know. If it's an error, it's a very common error, this occurs all over the place in the XEmacs C sources. I wonder if it's worth submitting a patch to fix these?

1 participants
0 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta August 1999