December 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Give people with crashes more of a clue 24 years, 5 months

Jan Vroonhof

Yoshiki Hayashi <t90553(a)mail.ecc.u-tokyo.ac.jp> writes: > > Unfortunately, I don't have the time to hack on it right now... have to get > > back to real work and housebreaking the new puppy. :) > > I made it into real patch. PROBLEMS file is not exactly > clear about what version is OK and what version is not. > Does egcs 1.0 means from egcs-1.0 to egcs-1.0.3a? > > Also, I don't have access to systems other than Solaris 2.6 > (sparc), Debian GNU/Linux potato (i686) and RedHat Linux 5.2 > (sparc), so I cannot test on other platforms. egcs test is > not tested yet because I don't have egcs here. > > Could someone please test this patch before I send it to > xemacs-patches? You need to run autoconf after applying this > patch. Thanks. > > Index: configure.in > =================================================================== > RCS file: /usr/CVSroot/XEmacs/xemacs/configure.in,v > retrieving revision 1.111.2.51 > diff -u -r1.111.2.51 configure.in > --- configure.in 1999/11/28 18:15:39 1.111.2.51 > +++ configure.in 1999/12/03 11:36:10 > ＠＠ -1809,6 +1809,64 ＠＠ > fi > fi > > +dnl Search for GCC specific build problems we know about > +if test "$GCC" = "yes"; then > +GCC_VERSION=`gcc --version` > +case `uname -s`:`uname -m`:$GCC_VERSION in > + dnl egcs 2.90.21 (egcs-1.00 release) > + dnl egcs 2.90.29 (egcs-1.0.3 release) Here is version that checks the CC the user specified, is slightly more verbose and also checks for -O3 It works for me. Index: configure.in =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs-20/configure.in,v retrieving revision 1.135 diff -u -u -r1.135 configure.in --- configure.in 1999/11/02 04:17:06 1.135 +++ configure.in 1999/12/06 18:49:47 ＠＠ -1032,7 +1032,7 ＠＠ alpha*-*-* ) machine=alpha ;; vax-*-* ) machine=vax ;; mips-dec-* ) machine=pmax ;; - mips-sgi-* ) machine=iris4d ;; + mips-sgi-* ) machine=iris6d ;; mips*-linux ) machine=mips ;; romp-ibm-* ) machine=ibmrt ;; rs6000-ibm-aix* ) machine=ibmrs6000 ;; ＠＠ -1347,13 +1347,13 ＠＠ m68*-sgi-iris3.5* ) machine=irist opsys=iris3-5 ;; m68*-sgi-iris3.6* | m68*-sgi-iris*) machine=irist opsys=iris3-6 ;; dnl Iris 4D - mips-sgi-irix3.* ) opsys=irix3-3 ;; - mips-sgi-irix4.* ) opsys=irix4-0 ;; + mips-sgi-irix3.* ) opsys=irix3-3 machine=iris4d ;; + mips-sgi-irix4.* ) opsys=irix4-0 machine=iris4d ;; mips-sgi-irix6* ) opsys=irix6-0 ;; - mips-sgi-irix5.1* ) opsys=irix5-1 ;; - mips-sgi-irix5.2* ) opsys=irix5-2 ;; - mips-sgi-irix5.* ) opsys=irix5-3 ;; - mips-sgi-irix* ) opsys=irix5-0 ;; + mips-sgi-irix5.1* ) opsys=irix5-1 machine=iris4d ;; + mips-sgi-irix5.2* ) opsys=irix5-2 machine=iris4d ;; + mips-sgi-irix5.* ) opsys=irix5-3 machine=iris4d ;; + mips-sgi-irix* ) opsys=irix6-0 machine=iris4d ;; dnl SONY machines *-sony-newsos[[34]]* | *-sony-news[[34]]* ) opsys=bsd4-3 ;; ＠＠ -1791,6 +1791,70 ＠＠ CFLAGS="-O" ;dnl The only POSIX-approved flag fi fi + +dnl Search for GCC specific build problems we know about +if test "$GCC" = "yes"; then +AC_MSG_CHECKING(for buggy gcc versions) +GCC_VERSION=`$CC --version` +case `uname -s`:`uname -m`:$GCC_VERSION in + dnl egcs 2.90.21 (egcs-1.00 release) + dnl egcs 2.90.29 (egcs-1.0.3 release) + *:sun4*:2.8.1|*:sun4*:egcs-2.90.*) + dnl Don't use -O2 with gcc 2.8.1 and egcs 1.0 under SPARC architectures + dnl without also using `-fno-schedule-insns'. + case "$CFLAGS" in + *-O2*|*-O3*) + case "$CFLAGS" in + *-fno-schedule-insns*) ;; + *) + AC_MSG_RESULT(Yes) + AC_MSG_WARN(Don't use -O2 with gcc 2.8.1 and egcs 1.0 under SPARC architectures) + AC_MSG_WARN(without also using -fno-schedule-insns.) + AC_MSG_ERROR(Aborting due to known problem) + ;; + esac + ;; + esac + ;; + dnl egcs-2.91.57 (egcs-1.1 release) + dnl egcs-2.91.66 (egcs-1.1.2 release) + Linux:alpha:egcs-2.91.*) + AC_MSG_RESULT(Yes) + AC_MSG_WARN(There have been reports of egcs-1.1 not compiling XEmacs correctly on) + AC_MSG_WARN(Alpha Linux. There have also been reports that egcs-1.0.3a is O.K.) + AC_MSG_ERROR(Aborting due to known problem) + ;; + *:i*86*:2.7.2*) + case "$GCC_VERSION" in + 2.7.2) + case "$CFLAGS" in + *-O2*|*-O3*) + case "$CFLAGS" in + *-fno-strength-reduce*) ;; + *) + AC_MSG_RESULT(Yes) + AC_MSG_WARN(Don't use -O2 with gcc 2.7.2 under Intel/XXX without also using) + AC_MSG_WARN(-fno-strength-reduce.) + AC_MSG_ERROR(Aborting due to known problem) + ;; + esac + ;; + esac + ;; + esac + case "$CFLAGS" in + *-fno-caller-saves*) ;; + *) + AC_MSG_RESULT(Yes) + AC_MSG_WARN(Don't use -O2 with gcc 2.7.2 under Intel/XXX without also using) + AC_MSG_WARN(-fno-caller-saves.) + AC_MSG_ERROR(Aborting due to known problem) + ;; + esac + ;; +esac +fi +AC_MSG_RESULT(No) dnl Inform compiler that certain flags are meant for the linker dnl XE_PROTECT_LINKER_FLAGS(shell_var)

1 participants
0 comments

Re: unexec causes crash in Xt [was: Re: XEmacs 21.1 CVS updates] 24 years, 5 months

Alexandre Oliva

On Dec 6, 1999, Gunnar Evermann <ge204(a)eng.cam.ac.uk> wrote: > [ Alexandre, are you reading xemacs-beta? Nope, sorry. Should I? > this crash occurs with the latest 21.1 version in CVS, i.e. including > your patch <orbt8826hb.fsf(a)garnize.lsd.ic.unicamp.br> ] Yep, it seems that SGI ELF is much more complicated than I expected :-( We should probably stick with unexelfsgi.c, at least for now. Maybe some day I can try to port/generalize Max Matveev's change to unexelf.c > with gcc version 2.7.2.3 linking against X11R6.4 and NOT using motif. Too bad it won't even work with old GCCs :-( > The crash occurs in X11R6.4's XtInitializeWidgetClass() at the > following place: Yeah, I think I've seen that before, with older versions of XEmacs. It might even have been before I first patched it to use unexelf.c on IRIX systems, but I may be wrong. One potentially important difference I see between the current XEmacs 21-1 unexelf.c and the patched GNU Emacs version of unexelf.c I've got, that works fine on all systems I've got, including IRIX 6.3 with GCC 2.95.2, is the last hunk of the following patch: As noted by others, `.got' doesn't need special handling on most systems. Moreover, `.lit4' and `.lit8' do not even exist on IRIX, at least on my build. They must be targeted at some other platform. > Please note that we have received a couple of reports of similar > crashes (i.e. same C backtrace) from people using Solaris 7. I'm going to give it a try on IRIX and Solaris7. In fact, on all platforms I've got. Unfortunately, this patch can't possibly make any difference on Solaris7 :-( BTW, which compiler is being used on Solaris7? In 32 or 64 bits mode? -- Alexandre Oliva http://www.ic.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva(a){lsd.ic.unicamp.br,guarana.{org,com}} aoliva(a){acm,computer}.org oliva(a){gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them

1 participants
0 comments

Re: unexec causes crash in Xt [was: Re: XEmacs 21.1 CVS updates] 24 years, 5 months

Jan Vroonhof

Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: > [ Alexandre, are you reading xemacs-beta? > this crash occurs with the latest 21.1 version in CVS, i.e. including > your patch <orbt8826hb.fsf(a)garnize.lsd.ic.unicamp.br> ] Have you tried with Max Matveev's patch? Jan

1 participants
0 comments

status of PCL-CVS 24 years, 5 months

Charles G Waldman

who is using PCL-CVS? Is anybody interested in syncing up our package with the latest PCL-CVS version?

1 participants
0 comments

Re: Xemacs 20.4 crash (PR#1039) 24 years, 5 months

Jan Vroonhof

> I actually know this bug. A long time ago I tracked it down but never > fixed it :-( I sent an explanation to xemacs-beta: > > http://www.xemacs.org/list-archives/xemacs-beta/9905/msg00184.html > > but nobody bothered to reply... and I guess I forgot about it. > > What do you think? I hate stupid assert's like that. There is no reason to crash here. Just give an error exist value and/or signal an error. In addition that code suffers from Macroitis. > The Lispref says: > > Emacs supports two comment styles simultaneously in any one syntax > table. This is for the sake of C++. [...] > > The two comment-start sequences must begin with the same > character; only the second character may differ. > > but this isn't really enforced. A consequence of this is that you can > make xemacs hit an abort() in font-lock.c. An example of this occurs > in some recent version of a sql mode, which tries to support '/*' and > '--' as comment starters (see recipe below for the crash). The Lisp ref is waaaayyy out of date.. It doesn't mention the 5678 flags at all. > The abort() is triggered in find_context(). In Fparse_partial_sexp() > we are not so aggressive and just parse '/-' and '-*' as comments -- > this also happens in FSF emacs, which uses Fparse_partial_sexp in > font-lock. I think this a bug. The infra structure seems there to do it correctly because of the 5-8 flags. This the code that aborts if ((SYNTAX_COMMENT_BITS (mirrortab, c) & SYNTAX_SECOND_CHAR_START) && context_cache.context == context_none && context_cache.ccontext == ccontext_start1 && SYNTAX_START_P (mirrortab, prev_c, c) /* the two chars match */ ) { context_cache.ccontext = ccontext_start2; context_cache.style = SYNTAX_START_STYLE (mirrortab, prev_c, c); if (context_cache.style == comment_style_none) abort (); } The problem is that in this case SYNTAX_START_P (mirrortab, prev_c, c) is defined as #define SYNTAX_START_P(table, a, b) \ ((SYNTAX_COMMENT_BITS (table, a) & SYNTAX_FIRST_CHAR_START) \ && (SYNTAX_COMMENT_BITS (table, b) & SYNTAX_SECOND_CHAR_START)) And thus it returns true even if a is the first char of a style a comment and b is the second char of a style b comment. i.e. (SYNTAX_COMMENT_BITS (table, a) & SYNTAX_FIRST_CHAR_START) and (SYNTAX_COMMENT_BITS (table, b) & SYNTAX_SECOND_CHAR_START) must have a type in common.. I think you can write this as /* See if a and b can be first and second char of the same comment type */ #define SYNTAX_START_P(table, a, b) \ (((SYNTAX_COMMENT_BITS (table, a) & SYNTAX_FIRST_CHAR_START) >> 2) \ & (SYNTAX_COMMENT_BITS (table, b) & SYNTAX_SECOND_CHAR_START)) and probably a similar definition of SYNTAX_END_P. This definition could even make parse-partial-sexp do the right thins... Jan

1 participants
0 comments

Re: Some small bugs in b22 and b20 24 years, 5 months

Raymond Toy

>>>>> "Raymond" == Raymond Toy <toy(a)rtp.ericsson.se> writes: >>>>> "Kyle" == Kyle Jones <kyle_jones(a)wonderworks.com> writes: Kyle> It is probably happening, but slowly. If your machine is paging Kyle> heavily, as you indicate below, even if VM gives up control it Kyle> can be a while before your computer starts listening to you Kyle> again. Disk interrupts have priority over socket or terminal Kyle> waits. Also XEmacs might be stuck in page wait. Raymond> I finally got some long awaited memory for this machine so it doesn't Raymond> really swap anymore, and I think flushing did stop when I typed. It happened again. I'm sure there was no swapping (no disk noise) and no other activitiy. Typing *did not* cause VM's flushing to stop. Or if it did, it took more than 3-4 seconds to return control. I don't mind this delay (similar to GC delays), but it would be nice if VM could change the cursor to something to indicate that it's busy. Thanks, Ray

2 participants
1 comments

Re: Introduce proper bool types - finally. 24 years, 5 months

Jan Vroonhof

[I am moving this to -beta] Martin Buchholz <martin(a)xemacs.org> writes: > Is it really so bad to be able to say > static size_t > Lstream_adding (Lstream *lstr, size_t num, bool force) > ... > size_t chunk = Lstream_adding (lstr, size, false); No. But it doesn't have that warm comfy feeling :-) > Having done some benchmarking, I hereby retract the part of the patch > that defined a bool type that occupies a char. The first compiler I > tried gave a 17% performance improvement in (garbage-collect) by > making the mark bit a char. However, other compilers have not > confirmed the advantage of this change - some work the other way > around. > > Jan: By the way, this means that I'm not sure I believe your 10% > redisplay speedup is for real - you might have just been lucky with > your choice of compiler and machine. Note that that choice included Solaris with its native compiler and egcs 1.1 on i386 so I think it covers the majority of users. However I frankly do not believe that this patch could cause a slowdown anywhere. it does not increase the size of the structure. Are there really compilers/machine that are faster at masking off bits then at reading bytes. What I can believe is that there isn't a speed up on machine that cannot do byte addressing and thus have to masking for that too.. > So let's just talk about `bool'. Is it so bad to have a type that > expresses the idea of a `bit' in a standard way? After all, Elisp > also knows about bits. > > This patch seems to be going down in flames, but I'd really like to > know why there is such *strong* opposition. Because I like the fact that in C truth values (not bits) are represented by numbers. I simply do not see the use of introducing bolos. For instance in the example above I do not see any gain in clarity. It might make sense in languages that are much more strongly typed but I cannot see it in C. Jan

3 participants
2 comments

Re: XEmacs 21.1 CVS updates 24 years, 5 months

Gunnar Evermann

Olivier Galibert <galibert(a)pobox.com> writes: > On Mon, Dec 06, 1999 at 02:09:09PM +0100, Jan Vroonhof wrote: > > According to Olivier the difficulty is in running a MIPSpro compiled > > version from 6.2 on 6.5. Does that work for you? yes, but only using -nw. > And also compiling in -n32 mode (which gives a subtly different > section usage pattern). so far I have only used -o32, as -n32 complained about my X11R6.4 libs being in -o32 format or something like that. Maybe I should link against the SGI X libs. <sigh> the number of tests I need to perform seems to be exponential in the number of messages in this thread... Gunnar

1 participants
0 comments

Re: XEmacs 21.1 CVS updates 24 years, 5 months

Jan Vroonhof

Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: > > > So far I have only built using gcc (except for the 6.5 system where we > > > only have the SGI compiler installed). > > > > Does that mean you have at least one platform where native compiler > > worked that worked > > yes: > > ge204＠truth$ cc -version > MIPSpro Compilers: Version 7.2.1 > > uname -a: IRIX truth 6.5 01221553 IP32 mips According to Olivier the difficulty is in running a MIPSpro compiled version from 6.2 on 6.5. Does that work for you? Jan

2 participants
1 comments

unexec causes crash in Xt [was: Re: XEmacs 21.1 CVS updates] 24 years, 5 months

Gunnar Evermann

[ Alexandre, are you reading xemacs-beta? this crash occurs with the latest 21.1 version in CVS, i.e. including your patch <orbt8826hb.fsf(a)garnize.lsd.ic.unicamp.br> ] Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: > #0 XtInitializeWidgetClass () at Create.c:95 > #1 0x4096274 in xtWidgetAlloc () at Create.c:260 > #2 0x4096550 in xtCreate () at Create.c:349 > #3 0x409710c in _XtCreatePopupShell () at Create.c:660 > #4 0x4097174 in XtCreatePopupShell () at Create.c:695 > #5 0x677490 in x_create_widgets (f=0x10252600, lisp_window_id=-1609027580, > parent=-1609027580) > at /home/tigger3/ge204/src/XEmacs/21-1/xemacs/src/frame-x.c:1952 OK, I have looked a bit closer at this and now I could use some help. first of all this X crash is indeed a dumping problem. run-temacs works fine even under X. All the following info is gleamed from a debug build on IRIX64 ruby 6.2 06101031 IP28 mips with gcc version 2.7.2.3 linking against X11R6.4 and NOT using motif. The phenomenon of temacs working and xemacs crashing is the same on the IRIX6.5/SGIcc build mentioned previously. The crash occurs in X11R6.4's XtInitializeWidgetClass() at the following place: ----- XtInitializeWidgetClass(wc) WidgetClass wc; { [...snip by ge...] WidgetClass pc; #define LeaveIfClass(c, d) if (pc == c) { inited = d; break; } for (pc = wc; pc; pc = pc->core_class.superclass) ------ the wc is actually our topLevelEmacsShellClassRec. In temacs directly before calling unexec it looks like this: $1 = {core_class = {superclass = 0x40ebcf4, class_name = 0x101285e0 "TopLevelEmacsShell", ... even after unexec() finishes it's the same. Now if I use 'gdb xemacs' and then immediately (i.e. before running) print it again it's still the same. Now I put a breakpoint at main() and 'run -vanilla' and it has changed to: $2 = {core_class = {superclass = 0xa81dbcf4, class_name = 0x101285e0 "TopLevelEmacsShell", ... i.e. the first two bytes were overwritten! As I have no clue what exactly is happening when a program is loaded/started I would appreciate some hints from the experts :-) Feel free to request more info or to provide instructions what to check. Please note that we have received a couple of reports of similar crashes (i.e. same C backtrace) from people using Solaris 7. Gunnar

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 December 1999