June 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: pgp key for the package list 24 years, 11 months

SL Baur

Earl Stutes <estutes(a)eas.san-jose.ca.us> writes in xemacs-beta(a)xemacs.org: ... > gpg: Can't check signature: public key not found Please snarf ftp://ftp.xemacs.org/pub/xemacs/pgp-keys/xemacs_dist.asc and try it again. -- I protest the NATO war in Yugoslavia.

1 participants
0 comments

Re: [Wolfram Gloger <wmglo@dent.med.uni-muenchen.de>] more on the emacs- 24 years, 11 months

SL Baur

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes in xemacs-beta(a)xemacs.org: > SL Baur <steve(a)xemacs.org> writes: ... >> We don't free *anything* starting just before >> exit(3) is called (the voodoo_free_hook hack). > I meant the fact that when running xemacs (not temacs) the > malloc_state_ptr is not freed after it is used to reinit the > allocator. This code is #if 0'ed out without comment. Right. I think I should have put a comment on that, because now I don't remember exactly why I did it. It probably interferes or causes a crash with malloc debugging enabled. >> I made a test on Demeter last night before she died, and I could not >> reproduce the exit(3) crash described above, but that may be due to >> differences between glibc-2.1 and glibc-2.0.7preX, or something else. >> I have upgraded practically everything between March of 1998 and now. > Note: The crash only occurs on glibc 2.1.1 (<-- Note the patch > level). O.K. Demeter was the only machine with glibc 2.1, so I cannot test this at present. -- I protest the NATO war in Yugoslavia.

1 participants
0 comments

pgp key for the package list 24 years, 11 months

Earl Stutes

Here are the final few lines of output when running gpg package-index-1999-05-27.sig gpg: Signature made Thu May 27 02:04:04 1999 PDT using DSA key ID DCF80B6B gpg: requesting key DCF80B6B from wwwkeys.us.pgp.net ... gpg: no valid OpenPGP data found. gpg: Total number processed: 0 gpg: Can't check signature: public key not found This is apparently causing a failure of the package list & install code in my xemacs-21.2 beta14. You might also be interested to know what pgp5 does. pgpv package-index-1999-05-27.sig Opening file "package-index-1999-05-27" type text. unknown hash: unable to verify signature I have really appreciated the Manage packages features and hope you get it repaired soon. Thanks =eas=

1 participants
0 comments

Re: open parts 24 years, 11 months

Colin Rafferty

SL Baur writes: > Hrvoje Niksic <hniksic(a)srce.hr> writes in xemacs-beta(a)xemacs.org: > ... >> Both points really boil down to the need of someone shaking the dust >> off it. We've discussed this at the symposium, and the general >> conclusion was that nobody > ;; except Colin Rafferty :-) >> knows how external widget support really works. I don't understand it. I simply use it. -- Colin

1 participants
0 comments

Re: XEmacs 21.1.2 is released 24 years, 11 months

Jan Vroonhof

mmandel(a)usd.edu (marc mandel) writes: > On 28 May 1999 10:07:47 +0200, Didier Verna <didier(a)xemacs.org> wrote: > > > > > Announcing XEmacs 21.1.2 Yippee! My news server doesn't have this yet. I had a look at it with www.deja.com (boy is the new look awfull). It doesn't seem to mention README.packages :-( Jan

1 participants
0 comments

Re: [21.1.2] Problems running dumped xemacs on hppa1.1-hp-hpux10.20 24 years, 11 months

SL Baur

Andrew Hobson <ahobson(a)eng.mindspring.net> writes in xemacs-beta(a)xemacs.org: ... > I didn't compile with egcs-1.1.2. I can try that if you think it will > make a difference. Please do, but also try the little test below first. I am going to do the same. > While trying to diagnose the problem, I discoved that 20.4 would > infloop if configured with MULE, so it doesn't seem like it's a > recently introduced problem. 20.4 didn't work at all. Steve Carney managed to build binary kits with a few patches. > I'll be happy to try and help if I can. I know nothing about xemacs > internals, so be gentle. > Should XEmacs use the GNU version of malloc? no > (The GNU allocators don't work with this system configuration). ... Something which must be tested is how this will work with the old GNU malloc in XEmacs. Hand patch src/m/alpha.h to look like: /* #ifdef LINUX */ # define SYSTEM_MALLOC /* #endif */ ;; Urgh! How did XEmacs end up with this indented preprocessor line ;; crap? Rerunning configure should have it build with the old GNU malloc (configure will call it the "New GNU malloc", but you can ignore it). If this works it still doesn't rule out a compiler bug or an XEmacs bug. -- I protest the NATO war in Yugoslavia.

2 participants
1 comments

Re: [21.1.2] Problems running dumped xemacs on hppa1.1-hp-hpux10.20 24 years, 11 months

Jan Vroonhof

Justin Vallon <vallon(a)mindspring.com> writes: > I'm trying to build 21.1.2 on HP using HP's cc. xemacs gets dumped. > However, when src/xemacs is first run (as part of lisp shadows), it hangs, > and can't be interrupted, killed, or kill -9'ed. > > > If I run it from gdb (gdb ./xemacs CR run), it works. > > If I use dde: > > (Warning) Object file > "/var/tmp/vallon/public/xemacs-21.1/xemacs-21.1.2/src/xemacs" has no debug > information. Could you compile with debugging enabled (i.e. -g), so that you can use the debugger where to see where it is hanging? (BTW if it cannot be KILL -9'ed (assuming -9 is SIGKILL) then that is also an OS problem.) > Is the "Should XEmacs use the GNU version of malloc?" ok to be > yes, if using the native compiler? Yes. Anything else to try? Jan

3 participants
3 comments

Re: [Wolfram Gloger <wmglo@dent.med.uni-muenchen.de>] more on the emacs- 24 years, 11 months

Jan Vroonhof

SL Baur <steve(a)xemacs.org> writes: > > FSF Emacs doesn't have minimal tag bit support doesn't it? That > > could be the difference but it seems to me now to be more pure luck. > > It was not luck, except the fortunate circumstance that Kyle > implemented it around the time I ready was to use it. I meant it could still be that the fact that we not see the problem is just some silly timing issue.. > > (XEmacs also doesn't free the malloc_state_ptr but surely that cannot > > be it. > > Is that a problem? I don't think so. > We don't free *anything* starting just before > exit(3) is called (the voodoo_free_hook hack). I meant the fact that when running xemacs (not temacs) the malloc_state_ptr is not freed after it is used to reinit the allocator. This code is #if 0'ed out without comment. > I made a test on Demeter last night before she died, and I could not > reproduce the exit(3) crash described above, but that may be due to > differences between glibc-2.1 and glibc-2.0.7preX, or something else. > I have upgraded practically everything between March of 1998 and now. Note: The crash only occurs on glibc 2.1.1 (<-- Note the patch level). Jan

1 participants
0 comments

Re: [Wolfram Gloger <wmglo@dent.med.uni-muenchen.de>] more on the emacs-20.3 segfault 24 years, 11 months

Andreas Jaeger

>>>>> SL Baur writes: sb> Andreas Jaeger <aj(a)arthur.rhein-neckar.de> writes in xemacs-beta(a)xemacs.org: sb> ... >> I did send the patch for discussion and further testing and thought >> the information in it might become relevant. Looking at Wolfram's >> analysis of the situation, XEmacs should segfault the same way as >> FSF-Emacs does --- but AFAIK it doesn't. sb> It did, but I worked around it, I believe. Check out voodoo_free_hook sb> in emacs.c ... Also, look through your old glibc email archives. I sb> emailed you about this in March of 1998. I begin to remember ... That looks exactly like the same problem. sb> 1998-03-29 SL Baur <steve(a)altair.xemacs.org> sb> * emacs.c (voodoo_free_hook): ELF libraries built with newer sb> versions of GCC do horrible things in dumped binaries after exit() sb> is called. sb> (Fkill_emacs): Use it. >> Either the analysis is wrong, we're just lucky with XEmacs or XEmacs >> is just better;-). sb> The patch looks O.K. and Wolfram's analysis is correct. I no longer sb> have access to the machine where XEmacs crashed 100% of the time at sb> exit due to a double free, but hopefully I can duplicate it on a sb> different machine and verify that this fixes the problem without sb> voodoo_free_hook and turning off free at exit(3) time. Andreas Schwab commented on Wolfram's email with: > Unfortunately this has a very nasty side effect: the protection against > MALLOC_CHECK_ does not work any more. That means that Emacs will crash if > MALLOC_CHECK_ is defined in the environment, and there is no way to fix > that within Emacs (the malloc_initialize_hook runs too late). And Wolfram replied: > OK, I'll take a look at whether this can be fixed in malloc. Therefore your hack might be the better idea. If you still can reproduce it, you've got to decide yourself which hack works really better. Sorry, I don't have time to help investigating this - I should spend more time on my thesis :-(. But I'll try to keep you informed. Andreas -- Andreas Jaeger aj(a)arthur.rhein-neckar.de jaeger(a)informatik.uni-kl.de for pgp-key finger ajaeger(a)aixd1.rhrk.uni-kl.de

1 participants
0 comments

Re: [21.1.2] Problems running dumped xemacs on hppa1.1-hp-hpux10.20 24 years, 11 months

SL Baur

Justin Vallon <vallon(a)mindspring.com> writes in xemacs-beta(a)xemacs.org: > On 31 May 1999, SL Baur wrote: >> [#2. None of the messages I've emailed to XEmacs-related mail lists >> today has returned to me, here goes again.] >> >> Justin Vallon <vallon(a)mindspring.com> writes in xemacs-beta(a)xemacs.org: >> >> > I'm trying to build 21.1.2 on HP using HP's cc. xemacs gets dumped. >> > However, when src/xemacs is first run (as part of lisp shadows), it hangs, >> > and can't be interrupted, killed, or kill -9'ed. >> ... >> >> There is badness[tm] somewhere in the Motif/CDE code in XEmacs. I >> cannot get a build on Sun/Solaris to work properly either. Before you >> get rid of this binary, try `xrdb </dev/null' first. >> >> I have found that I cannot start an XEmacs on Sun/Solaris with Motif & >> XIM/Motif support *and* specify a font via X Defaults without getting >> a coredump deep in the initial frame initialization. Weird ... > After 'xrdb -load /dev/null', it still did not work. > [ I was not getting any core dumps, though, if that was your symptom ] On Solaris, yes. One symptom on OSF is that the character hash tables are read-only. The easiest way to demonstrate the damage is to start the program up, enter a string of hiragana (or cut & paste out of a file like its-hira.el), select it with the mouse then do `M-x japanese-katakana-region'. Please ignore my previous message regarding changing mallocs. The instructions are wrong. -- I protest the NATO war in Yugoslavia.

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