December 1998 - XEmacs-Beta - XEmacs Mailing List Archives

21.2.5 crash and question 25 years, 12 months

Gunnar Evermann

Wow, this was really a mega-patch! Really amazing, Martin. I can build "Aphrodite" fine on Linux 2.0.36, but get the same crash Steve mentioned. the problem is: Fatal error: assertion failed, file /local/srcdisk/gunnar/src/XEmacs/xemacs-20/src/bytecode.c, line 1904, OPAQUEP (f->instructions) I looked a bit closer with gdb and what I saw was the following (please note that I do *not* understand anything of what is going on here, but maybe this can point Martin to the problem faster): - optimize_compiled_function is called - f->instructions is a cons and therefore: - Ffetch_bytecode is called - in here the code is fetched, but *not* copied to f->instruction (see commented line in bytecode.c:2349 ), if I execute this codeline manually in gdb, everything seems to work. OK, so this is the obvious patch: --- src/bytecode.c~ Sat Dec 5 13:02:24 1998 +++ src/bytecode.c Sat Dec 5 15:02:03 1998 ＠＠ -2346,7 +2346,7 ＠＠ ebolify_bytecode_constants (XCDR (tem)); /* VERY IMPORTANT to purecopy here!!!!! See load_force_doc_string_unwind. */ - /* f->instructions = Fpurecopy (XCAR (tem)); */ + f->instructions = Fpurecopy (XCAR (tem)); f->constants = Fpurecopy (XCDR (tem)); return function; } I recompiled and it seems to work. I'm even sending this mail from it! Please wait till Martin comments on this, I *really* have no idea what is going on here -- this is one of my "zero-knowledge patches"! I have not even read the new stuff in the internals manual. I just needed an excuse for a break from my work. HTH Gunnar -- Gunnar Evermann Speech, Vision & Robotics Group Engineering Department Cambridge University

1 participants
0 comments

[Success, but...] 21.2 "Aphrodite" XEmacs Lucid (beta5) on i686-pc-linux 25 years, 12 months

Hayashi Tanaka

Patched up from *happy-stable-for-me* beta4. $ cat /etc/redhat-release Red Hat Linux release 5.2 (Apollo) $ egcs -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.90.29/specs gcc version egcs-2.90.29 980515 (egcs-1.0.3 release) Built successfully, but... ``M-x fast-lock'' immediately killed Aphrodite, as below. Fatal error (6). Your files have been auto-saved. Use `M-x recover-session' to recover them. Please report this bug by running the send-pr script included with XEmacs, or selecting `Send Bug Report' from the help menu. As a last resort send ordinary email to `crashes(a)xemacs.org'. *MAKE SURE* to include the information in the command M-x describe-installation. If at all possible, *please* try to obtain a C stack backtrace; it will help us immensely in determining what went wrong. To do this, locate the core file that was produced as a result of this crash (it's usually called `core' and is located in the directory in which you started the editor, or maybe in your home directory), and type gdb /usr/local/bin/xemacs-21.2-b5 core then type `where' when the debugger prompt comes up. (If you don't have GDB on your system, you might have DBX, or XDB, or SDB. A similar procedure should work for all of these. Ask your system administrator if you need more help.) Lisp backtrace follows: fast-lock-mode(nil) # bind (command-debug-status) call-interactively(fast-lock-mode) command-execute(fast-lock-mode t) # bind (_execute_command_keys_ _execute_command_name_ prefix-arg) execute-extended-command(nil) # bind (command-debug-status) call-interactively(execute-extended-command) # (condition-case ... . error) # (catch top-level ...) Aborted > XEmacs Build Report as generated > by build-report-version 1.35 follows: > Contents of /home/tanaka/src/xemacs-21.2.5/Installation: > (Output from most recent run of ./configure)

1 participants
0 comments

Re: [Sug] auto-autoload generation 25 years, 12 months

Christoph Wedler

Sorry, the previous patch to XEmacs.rules was stupid. This (to the orig) is better: - Christoph diff -c /home/clstaff/wedler/sources/x-symbol/XEmacs.rules~ /home/clstaff/wedler/sources/x-symbol/XEmacs.rules *** /home/clstaff/wedler/sources/x-symbol/XEmacs.rules~ Sat Dec 5 15:19:29 1998 --- /home/clstaff/wedler/sources/x-symbol/XEmacs.rules Sat Dec 5 15:19:29 1998 *************** *** 135,143 **** $(AUTOLOAD_PATH)/_pkg.el: Makefile ＠echo Creating $(AUTOLOAD_PATH)/_pkg.el ＠echo ";;;###autoload" > $(AUTOLOAD_PATH)/_pkg.el ! ＠echo "(package-provide '$(PACKAGE)" >> $(AUTOLOAD_PATH)/_pkg.el ! ＠echo " :version $(VERSION)" >> $(AUTOLOAD_PATH)/_pkg.el ! ＠echo " :type '$(PKG_TYPE))" >> $(AUTOLOAD_PATH)/_pkg.el .PHONY: srckit-std --- 135,144 ---- $(AUTOLOAD_PATH)/_pkg.el: Makefile ＠echo Creating $(AUTOLOAD_PATH)/_pkg.el ＠echo ";;;###autoload" > $(AUTOLOAD_PATH)/_pkg.el ! ＠echo "(if (fboundp 'package-provide)" >> $(AUTOLOAD_PATH)/_pkg.el ! ＠echo " (package-provide '$(PACKAGE)" >> $(AUTOLOAD_PATH)/_pkg.el ! ＠echo " :version $(VERSION)" >> $(AUTOLOAD_PATH)/_pkg.el ! ＠echo " :type '$(PKG_TYPE)))" >> $(AUTOLOAD_PATH)/_pkg.el .PHONY: srckit-std

1 participants
0 comments

Re: [Sug] auto-autoload generation 25 years, 12 months

Christoph Wedler

>>>>>"sb" == SL Baur <steve(a)xemacs.org> writes: sb> Christoph Wedler <wedler(a)fmi.uni-passau.de> writes in xemacs-beta(a)xemacs.org: >> I would suggest to add the following line as the first line of each >> generated auto-autoload file: >> (unless (fboundp 'package-provide) (fset 'package-provide 'ignore)) sb> Not O.K. Why should this be done by autoload generation? sb> The `package-provide' call is due to _pkg.el: [...] sb> Any backwards compatibility on the `package-provide' should go there. Adding this line to _pkg.el with an autoload cookie is fine for me, too. See patch below. >> (Well, they don't because files with some macros compiled in XEmacs-21 >> don't run in XEmacs-20, but that is another story...) sb> There's a flag for that. Martin's changes for 21.2.5 might have sb> introduced more bytecode incompatibilities, if so there should be a sb> flag for that too. Sorry, I wasn't clear that I know the flag. It is just that --as Jan pointed out-- that the .elc files should be marked as incompatible. - Christoph diff -c /home/clstaff/wedler/sources/x-symbol/XEmacs.rules~ /home/clstaff/wedler/sources/x-symbol/XEmacs.rules *** /home/clstaff/wedler/sources/x-symbol/XEmacs.rules~ Sat Dec 5 14:47:56 1998 --- /home/clstaff/wedler/sources/x-symbol/XEmacs.rules Sat Dec 5 14:47:56 1998 *************** *** 135,140 **** --- 135,143 ---- $(AUTOLOAD_PATH)/_pkg.el: Makefile ＠echo Creating $(AUTOLOAD_PATH)/_pkg.el ＠echo ";;;###autoload" > $(AUTOLOAD_PATH)/_pkg.el + ＠echo "(unless (fboundp 'package-provide)" >> $(AUTOLOAD_PATH)/_pkg.el + ＠echo " (fset 'package-provide 'ignore))" >> $(AUTOLOAD_PATH)/_pkg.el + ＠echo ";;;###autoload" >> $(AUTOLOAD_PATH)/_pkg.el ＠echo "(package-provide '$(PACKAGE)" >> $(AUTOLOAD_PATH)/_pkg.el ＠echo " :version $(VERSION)" >> $(AUTOLOAD_PATH)/_pkg.el ＠echo " :type '$(PKG_TYPE))" >> $(AUTOLOAD_PATH)/_pkg.el

1 participants
0 comments

[OK] 21.2 "Aphrodite" XEmacs Lucid (beta5) on i586-pc-linux 25 years, 12 months

Larry Ayers

Patched up from 21.2-b4, built and runs fine so far. > XEmacs Build Report as generated > by build-report-version 1.35 follows: > Contents of /usr/local/src/xemacs-21.2-b5/Installation: > (Output from most recent run of ./configure) uname -a: Linux liatris 2.1.131 #17 Thu Dec 3 19:02:18 CST 1998 i586 unknown ./configure '--prefix=/usr/local/xemacs-beta' '--with-site-lisp' '--package-path=/usr/local/xemacs-beta/lib/xemacs/packages' '--gung-ho' '--with-xpm' '--with-tiff=no' '--with-dialogs=athena' '--error-checking=none' XEmacs 21.2-b5 "Aphrodite" configured for `i586-pc-linux'. Where should the build process find the source code? /usr/local/src/xemacs-21.2-b5 What installation prefix should install use? /usr/local/xemacs-beta What operating system and machine description files should XEmacs use? `s/linux.h' and `m/intel386.h' What compiler should XEmacs be built with? gcc -g -O3 -Wall -Wno-switch Should XEmacs use the GNU version of malloc? yes (Using Doug Lea's new malloc from the GNU C Library.) Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? x11 Where do we find X Windows header files? /usr/X11/include Where do we find X Windows libraries? /usr/X11/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for PNG image handling. Compiling in support for (builtin) GIF image handling. Compiling in support for JPEG image handling. Compiling in native sound support. Compiling in support for Berkeley DB. Compiling in support for GNU DBM. Compiling in support for ncurses. Compiling in support for GPM (General Purpose Mouse). Compiling in support for proper session-management. Using Lucid menubars. Using Lucid scrollbars. Using Athena dialog boxes. Compiling in DLL support. movemail will use "dot-locking" for locking mail spool files. Using Lisp_Objects with minimal tagbits. Using indexed lrecord implementation. Compiling in extra code for debugging. Compiling in code for checking XEmacs memory usage. > /usr/local/src/xemacs-21.2-b5/beta.err does not exist!

1 participants
0 comments

Re: [Sug] XEmacs.rules with chmod 25 years, 12 months

Christoph Wedler

>>>>>"sb" == SL Baur <steve(a)xemacs.org> writes: sb> Christoph Wedler <wedler(a)fmi.uni-passau.de> writes in xemacs-beta(a)xemacs.org: >> I have a suggestion for XEmacs.rules. In order not to get errors during >> re-installation in the case when some files are read-only, I would >> suggest that all file permissions are changed with `chmod u+w'. sb> I don't think this is the right fix. By design, the XEmacs package sb> sources are supposed to be read+write for owner and group. If that is sb> not the case, then the source of the problem -- the CVS tree should be sb> fixed. OK. But some package authors (like myself) might use RCS for their local copy. I should probably switch to CVS... But since my patch to XEmacs.rules doesn't break anything... - Christoph

1 participants
0 comments

Re: XEmacs-21.2-beta4 is out 25 years, 12 months

SL Baur

William M Perry <wmperry(a)aventail.com> writes in xemacs-beta(a)xemacs.org: > Why not just upload .bz2 and have a script that steve can run > automatically to convert to gzip after the upload. That was what I basically had in mind and it didn't work out. The next best thing is to build the distributions network-topologically closer to ftp.xemacs.org, which is what we're trying now[1]. Unfortunately, cvs.xemacs.org doesn't have bzip2 installed, so I had to gzip the 21.2.5 tarballs. Sigh. If it looks like I'm making this up as I go along, sigh, I am. Please bear with me. Footnotes: [1] And it still took over 3 hours to make and upload a distribution. :-(

1 participants
0 comments

Re: [Sug] XEmacs.rules with chmod 25 years, 12 months

SL Baur

Christoph Wedler <wedler(a)fmi.uni-passau.de> writes in xemacs-beta(a)xemacs.org: > I have a suggestion for XEmacs.rules. In order not to get errors during > re-installation in the case when some files are read-only, I would > suggest that all file permissions are changed with `chmod u+w'. I don't think this is the right fix. By design, the XEmacs package sources are supposed to be read+write for owner and group. If that is not the case, then the source of the problem -- the CVS tree should be fixed.

1 participants
0 comments

Re: [Sug] auto-autoload generation 25 years, 12 months

SL Baur

Christoph Wedler <wedler(a)fmi.uni-passau.de> writes in xemacs-beta(a)xemacs.org: > In order to make the generated auto-autoload files also work with > XEmacs-20.{3,4}, O.K. > I would suggest to add the following line as the first line of each > generated auto-autoload file: > (unless (fboundp 'package-provide) (fset 'package-provide 'ignore)) Not O.K. Why should this be done by autoload generation? The `package-provide' call is due to _pkg.el: ;;;###autoload (package-provide 'gnus :version 1.34 :type 'regular) Any backwards compatibility on the `package-provide' should go there. If there's a nit to be picked with the auto-autoloads files themselves, I would start with the top: ;;; DO NOT MODIFY THIS FILE (if (featurep 'gnus-autoloads) (error "Already loaded")) I put that there because I don't want those files being reloaded without careful thought -- one must unload the feature first before reloading the autoloads. > You might say that these files are not supposed to be loaded by > XEmacs-20.3, but the point is: XEmacs-20.3 *does* load files in > ~/.xemacs/lisp/*/ automatically. And if someone (e.g., package authors) > want to use both XEmacs-20 and XEmacs-21, the files in these directories > should work with both XEmacs-20 and XEmacs-21. Fair enough. > (Well, they don't because files with some macros compiled in XEmacs-21 > don't run in XEmacs-20, but that is another story...) There's a flag for that. Martin's changes for 21.2.5 might have introduced more bytecode incompatibilities, if so there should be a flag for that too.

1 participants
0 comments

Re: To gnupg or not to gnupg ... (was Re: Assertion while pui-list-packages) 25 years, 12 months

SL Baur

Valdis Kletnieks <Valdis.Kletnieks(a)vt.edu> writes in xemacs-beta(a)xemacs.org: > On 04 Dec 1998 05:32:33 PST, you said: >> Once I did manage to get it built (and after generating a secure key >> on a Linux box with /dev/random and importing it to the BSDI box) it >> spits this at me when stuff is signed: > This is, in *general*, not the recommended procedure, for all the > obvious reasons having to do with people seeing the keys as they go by > on the wire or finding the floppy after you sneakernet it. Sneakernet is out of the question. cvs.xemacs.org is physically 200 miles away, ftp.xemacs.org is physically 3000 miles away from me. My development machine is no longer accessible via the 'net and would make a perfect machine for signing except that I don't have a 'net connection where I can transfer that many megabytes of data as often as would be needed if distributions were being built there. > Now, if you use sufficient care (such as using SSH with good crypto > support), you can close those exposures, but... ;) I am. Since moving the XEmacs ftp server to gwyn from UIUC, I'm only talking to it over encrypted links, which is an improvement from the straight FTP I was doing in the 19.15 .. 20.2 days. >> Um, what does having a weak RNG have to do with signing with a key >> generated with a strong RNG? > Due to the above, the code is making an assumption that the key was > generated on the local machine. It has no way of knowing that you > built it on a machine with a working /dev/random and played crypto > games behind its back... I got an answer back from one of the gnupg people. It is explained in Schneier, _Applied Cryptography_[1]. Good random numbers are required for DSA digital signatures. Double Sigh. Footnotes: [1] Which I suppose I should have checked first, sigh.

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 1998