October 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Xemacs crashes my linux! 25 years, 1 month

Jan Vroonhof

morten.stenseth(a)baerum-kommune.telemax.no writes: > Hi, I have had som problems with xemacs 21.2.15 to 21.2.19, everytime > i start up xemacs,it crashes linux when the xemacs-beta logo > becomes visible, You mean it crashes the X server? > Anyone have a solution to this problem? The best solution would be to fix the X server. Try and see whether redhat has an update. Jan

1 participants
0 comments

Re: TPD, here we go again 25 years, 1 month

Jan Vroonhof

Andy Piper <andy(a)xemacs.org> writes: > >itself is not needed until the sweep arrives. My guess would be that > >[a new GC] would produce better cache behaviour that would offset any > >computational disadvantages. > > Sounds like a job for Martin :) Actually I was sort of expecting Michael to come in and give reference to 3 of the hundred thousand papers where this was done and found not to work :-). Would suit me well for not doing my homework. Jan

1 participants
0 comments

Re: TPD, here we go again 25 years, 1 month

Jan Vroonhof

Hrvoje Niksic <hniksic(a)srce.hr> writes: > > That's what I'm working on right now: using an external hash table > > for marking instead of an internal markbit. > > Won't this slow things down? XEmacs' GC is not exactly fast as it is. > Making it any slower would be a mistake. It depends. If (most) objects XEmacs are organised in pools it would be possible to write the sweep loop such that it is scans over the heap in a linear fashion, backtracking only occasionally. Supposing the locality of reference is good an the hashing is done per page that means that the hash is needed relatively seldom. In addition in such an implementation the _address_ is used in the hash table. The object itself is not needed until the sweep arrives. My guess would be that this would produce better cache behaviour that would offset any computational disadvantages. I think it is time to save a copy of XEmacs for benchmark comparisons. Jan

2 participants
1 comments

latest cvs goes bang 25 years, 1 month

Michael Harnois

Program received signal SIGSEGV, Segmentation fault. 0x814c250 in x_finalize_image_instance (p=0x876cf28) at /usr/src/xemacs-21.2/src/glyphs-x.c:422 422 if (IMAGE_INSTANCE_X_MASK (p) && (gdb) where #0 0x814c250 in x_finalize_image_instance (p=0x876cf28) at /usr/src/xemacs-21.2/src/glyphs-x.c:422 #1 0x80d9c55 in finalize_image_instance (header=0x876cf28, for_disksave=0) at /usr/src/xemacs-21.2/src/glyphs.c:830 #2 0x805454c in sweep_lcrecords_1 (prev=0x81afa70, used=0xbfffe958) at /usr/src/xemacs-21.2/src/alloc.c:2631 #3 0x8055387 in gc_sweep () at /usr/src/xemacs-21.2/src/alloc.c:3221 #4 0x80558b1 in garbage_collect_1 () at /usr/src/xemacs-21.2/src/alloc.c:3540 #5 0x807fd3a in Ffuncall (nargs=2, args=0xbfffea28) at /usr/src/xemacs-21.2/src/eval.c:3124 #6 0x805ce47 in execute_optimized_program ( program=0x87dc260 "À\211\211\031\032\eÄ\r!\210ÆÇÈ\t\"\036\t\036\nË\tÌÍ\n!ÎP#À\036\017\211\036\020«-\016\020＠\026\017Ñ\016\017!«\032\013\016\017!«\024Ò\016\017\016\023\"«\f\016\nÔ\016\025\016\017\"\\\026\n\016\020A\211\026\020¬Õ*\016\n-\207-p nnheY", stack_depth=6, constants_data=0x87ac090) at /usr/src/xemacs-21.2/src/bytecode.c:743 #7 0x805cb3f in funcall_compiled_function (fun=141697884, nargs=2, args=0xbfffeb48) at /usr/src/xemacs-21.2/src/bytecode.c:516 #8 0x807ffe5 in Ffuncall (nargs=3, args=0xbfffeb44) at /usr/src/xemacs-21.2/src/eval.c:3210 #9 0x807fa5c in Feval (form=142247864) at /usr/src/xemacs-21.2/src/eval.c:3001 #10 0x807da78 in condition_case_1 (handlers=142247996, bfun=0x807f494 <Feval>, barg=142247864, hfun=0x807dad8 <run_condition_case_handlers>, harg=137724348) at /usr/src/xemacs-21.2/src/eval.c:1630 -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA mharnois(a)willinet.net aa0bt(a)aa0bt.ampr.org Make everything as simple as possible, but not simpler. -- Einstein

2 participants
1 comments

Re: Xemacs crashes my linux! 25 years, 1 month

morten.stenseth＠baerum-kommune.telemax.no

> > Hi, I have had som problems with xemacs 21.2.15 to 21.2.19, everytime > > i start up xemacs,it crashes linux when the xemacs-beta logo > > becomes visible, > > You mean it crashes the X server? > no . it locks up my linux. i can't do anything ,but turn the computer off. > > Anyone have a solution to this problem? > > The best solution would be to fix the X server. Try and see whether > redhat has an update. > I have tried with XFree86 3.3.3-3.3.5 and AccelratedX 5.0 , and the problem is the same on all of them . Morten Stensteh <morste(a)baerum-kommune.telemax.no>

1 participants
0 comments

Xemacs crashes my linux! 25 years, 1 month

morten.stenseth＠baerum-kommune.telemax.no

Hi, I have had som problems with xemacs 21.2.15 to 21.2.19, everytime i start up xemacs,it crashes linux when the xemacs-beta logo becomes visible, but the problem only happens when the xemacs welcome screen becomes visible , if i f.ex types xemacs ~/.emacs the problem does not occur. Anyone have a solution to this problem? Thanks. Morten Stenseth <morste(a)baerum-kommune.telemax.no> ( btw: i am running Xemacs 21.2.19,redhat 6.0 with a 2.2.5 kernel )

1 participants
0 comments

Re: 21.2.19 crash in ldap on Solaris 2.7 25 years, 1 month

Gunnar Evermann

Oscar Figueiredo <Oscar.Figueiredo(a)di.epfl.ch> writes: > >>>>> "Raymond" == Raymond Toy <toy(a)rtp.ericsson.se> writes: > > Raymond> I got a crash when trying to do an ldap access. 100% repeatable. > Raymond> This is the first time I've tried to do that on Solaris 2.7, which > Raymond> seems to come with it's own ldap libraries. Previously, I was using > Raymond> the UMICH 3.3 ldap libraries on Solaris 2.5.1. I'll have to try using > Raymond> the UMICH 3.3 ldap libraries instead of the Solaris 2.7 ones.... > > According to the Lisp and C backtraces and the description you give, the > problem is certainly not in your LDAP libraries: there's no call to the LDAP > routines involved in what you describe. Well, the bytecode stack seems to be corrupted. Could some call to the LDAP lib have caused this? On the other hand a dialog box seems to be involved in Raymond's recipe, so it could also be related to motif or something. Raymond, could you look a bit closer at this, e.g. check when & where the stack is corrupted? dbx on Solaris has these fantastic watchpoints which might be helpful for this. Gunnar

1 participants
0 comments

Re: the package system doesn't erase gzip'd lisp sources 25 years, 1 month

Jan Vroonhof

giacomo boffi <giacomo.boffi(a)polimi.it> writes: > the package system doesn't erase gzip'd lisp sources when updating or > removing a package It doesn't remove any files that didn't come with the package... I am not sure it should. Jan

1 participants
0 comments

Re: 21.2.19 crash in ldap on Solaris 2.7 25 years, 1 month

Oscar Figueiredo

>>>>> "Raymond" == Raymond Toy <toy(a)rtp.ericsson.se> writes: Raymond> I got a crash when trying to do an ldap access. 100% repeatable. Raymond> This is the first time I've tried to do that on Solaris 2.7, which Raymond> seems to come with it's own ldap libraries. Previously, I was using Raymond> the UMICH 3.3 ldap libraries on Solaris 2.5.1. I'll have to try using Raymond> the UMICH 3.3 ldap libraries instead of the Solaris 2.7 ones.... Raymond> Ray Raymond> The recipe: Raymond> xemacs -vanilla >> From the menus Tools->Directory Search->Query with Form. Raymond> A dialog box asks if I want to define a Search Base. Press No. Raymond> Crash! According to the Lisp and C backtraces and the description you give, the problem is certainly not in your LDAP libraries: there's no call to the LDAP routines involved in what you describe. So I don't think UMich libs will help in any way. The problem seems to be rather related to Custom instead. Something might be wrong in the definition of ldap-host-parameters-alist but that should never trigger a crash anyway. Oscar

1 participants
0 comments

the package system doesn't erase gzip'd lisp sources 25 years, 1 month

Giacomo Boffi

the package system doesn't erase gzip'd lisp sources when updating or removing a package

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