April 1998 - XEmacs-Beta - XEmacs Mailing List Archives

[crash]: more on `internal bug', and another `fatal i/o error' 27 years

Karl M. Hegbloom

gesture, and XEmacs disappeared. There was no core dump. I found this in ~/.xsession-errors: Lisp backtrace follows: ding(nil command-error) # bind (inhibit-quit debug-on-error etype error-object) command-error((wrong-type-argument symbolp #<INTERNAL EMACS BUG (symbol-value-forward type 13) 0x0x82492e8>)) # (catch top-level ...) /usr/local/bin/xg: line 7: 26866 Terminated xemacs "$＠" xemacs: Fatal I/O Error 14 (Bad address) on display connection ":0.0" after 107657 requests (107655 known processed) with 0 events remaining. The backtrace is from the crash I sent a screenshot of, and the last message is from the disappearing act.

1 participants
0 comments

Re: [bug] w3 goes boom... 27 years

SL Baur

Rebecca Ore <rebecca.ore(a)op.net> writes: > ... when I tried to access www.sputum.com, the slack version. I cannot reproduce this with $ xemacs -vanilla M-x w3-fetch http://www.sputum.com

1 participants
0 comments

Re: [PATCH] Frame crash and extra minibuffers fixes 27 years

Greg Klanderman

>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> sb> Greg Klanderman <greg(a)alphatech.com> writes: >>>>>>> "kkm" == Kirill M Katsnelson <kkm(a)kis.ru> writes: kkm> kkm> This fixes [very probable cause for] crashes seen by Karl and Greg, kkm> and solves extra minibuffers problem in ediff, reported by Greg. sb> >> Thanks Kirill! That does it. BTW, this appears to be the ChangeLog >> entry you were looking for: sb> >>> 1998-03-17 SL Baur <steve(a)altair.xemacs.org> >>> >>> * frame.c (delete_frame_internal): Correct check. sb> >> Steve, was this to fix a bug or did it just look wrong? sb> sb> It was to fix a bug. `called_from_delete_device' can never be less sb> than 0 so it is a degenerate comparison. The bug being that called_from_delete_device can never be negative, or that this code not being run was actually causing a problem for someone? >> I see nowhere that function is called with other than 0 or 1, >> so maybe this code should just be ifdef'd out or removed? sb> sb> Yes, reversing the patch I made is equivalent to `if (1)' so there sb> little point to keeping that conditional if it is causing problems. You mean `if (0)', of course... Can you reproduce this: xemacs -q <split window, load 2 files> M-x ediff-buffers quit ediff M-x ediff-buffers again Do you get spurious creation of a minibuffer only frame? Both Kirill and I do. greg

1 participants
0 comments

[bug] w3 goes boom... 27 years

Rebecca Ore

... when I tried to access www.sputum.com, the slack version. (Don't ask). -- Rebecca Ore

1 participants
0 comments

[crash] Internal emacs bug. 27 years

Karl M. Hegbloom

I had typed an email, and forgot to send myself a copy, so I pulled up the message buffer it was in, and changed the headers. I turned the To header into X-To, and put a new To line on with my own name. Right after I pushed `C-c C-c', XEmacs locked up in a loop going blonde blonde blonde, with a message in the minibuffer. I took a snapshot:

1 participants
0 comments

Re: [PATCH] Frame crash and extra minibuffers fixes 27 years

SL Baur

Greg Klanderman <greg(a)alphatech.com> writes: >>>>>> "kkm" == Kirill M Katsnelson <kkm(a)kis.ru> writes: kkm> kkm> This fixes [very probable cause for] crashes seen by Karl and Greg, kkm> and solves extra minibuffers problem in ediff, reported by Greg. > Thanks Kirill! That does it. BTW, this appears to be the ChangeLog > entry you were looking for: >> 1998-03-17 SL Baur <steve(a)altair.xemacs.org> >> >> * frame.c (delete_frame_internal): Correct check. > Steve, was this to fix a bug or did it just look wrong? It was to fix a bug. `called_from_delete_device' can never be less than 0 so it is a degenerate comparison. > I see nowhere that function is called with other than 0 or 1, > so maybe this code should just be ifdef'd out or removed? Yes, reversing the patch I made is equivalent to `if (1)' so there little point to keeping that conditional if it is causing problems.

1 participants
0 comments

Re: [Success] XEmacs 21.0-b37 "Pygmy", sparc-sun-solaris2.5.1 27 years

SL Baur

Adrian Aichner <aichner(a)ecf.teradyne.com> writes: > First a correction of my correction: > The CVS release tag should have been: > r21-0b37 There was a typo in the release announcement, sorry. > What's all this stuff from the attic? It's mostly stuff that got packaged or moved. You need it if you wish to `cvs checkout' XEmacs 20.2, for example.

1 participants
0 comments

Re: [FAILURE, b37] 27 years

SL Baur

root <mdub(a)julian.uwo.ca> writes: > uname -a: Linux h219-29.reznet.uwo.ca 2.1.98 #44 Sat Apr 26 21:48:31 EST 1998 i586 unknown > ./configure '-cflags=-mpentium -march=pentium -O6 -g' '--dynamic' '--with-xfs' '--with-xpm' '--with-xim=xlib' '--with-mule' '--with-canna' '--error-checking=none' '--debug=no' '--extra-verbose' '--prefix=/usr/local' Which compiler are you using? If you are using Gcc 2.7* you will need to add -fno-strength-reduce (if your compiler is really old), or -fno-caller-saves if your compiler is Gcc-2.7.2 or later. Both these problems are known to be fixed in GCC 2.8/EGCS. If you are using GCC 2.8 or EGCS, for safety you should probably add the flags: `-fno-risc -fno-peep-spills'. Both of those optimizations have been known to cause problems at times. Depending on the version, you should also specify `-fno-exceptions'. I'm using Pentium GCC (based on egcs-1.01) with cflags: -mpentium -march=pentium -fno-peep-spills -O6 -fno-risc -fno-exceptions and it works fine for me.

1 participants
0 comments

Re: [PATCH] menubar selection in mswindows 27 years

SL Baur

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Hrvoje Niksic <hniksic(a)srce.hr> writes: >> Lstreams rule. Look at my latest and greatest md5.c implementation to >> see how simple it is to set up a decoding lstream for that purpose. > Does that mean that md5.c mow works under MULE? I haven't tested it since Hrvoje's changes. It was fixed some months previous by Jareth Hein.

1 participants
0 comments

Re: [Patch] Warnings in 21.0b37 27 years

SL Baur

Andreas Jaeger <aj(a)arthur.rhein-neckar.de> writes: ... > File: emacs.c: > ============== > In glibc 2.1 <malloc.h> will have: > extern void (*__free_hook) __MALLOC_P ((__malloc_ptr_t __ptr, > __const __malloc_ptr_t)); > But 2.0.7 has: > extern void (*__free_hook) __MALLOC_P ((__malloc_ptr_t __ptr)); > This leads to a warning in emacs.c for the assignment: > voodoo_free_hook(void *mem) > { > /* Disable all calls to free() when XEmacs is exiting and it doesn't */ > /* matter. */ > __free_hook = voodoo_free_hook; > } The `voodoo_free_hook' is what I'm using to avoid the C++ constructor/destructor fuckage introduced by GCC 2.8/EGCS that leaks into C code. > Should we add a second parameter with the following conditinal? > #if defined DOUG_LEA_MALLOC && __GLIBC__ == 2 && __GLIBC__MINOR__ >= 1 > Or should we just ignore it? You can probably ignore it. `voodoo_free_hook' is intentionally a black hole that is going to ignore its parameters anyway.

1 participants
0 comments

2025

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 April 1998