February 2005 - XEmacs-Beta - XEmacs Mailing List Archives

RE: [Bug: 21.5-b19] Core dump 19 years, 10 months

Ben Wing

> You wrote: > > Ben> Mats -- I need to see the whole backtrace. In this > case, what's in > Ben> the inner frames is critical. > > Well, no problem except how to I create such a thing? The > backtrace you got is the whole backtrace I got when I gave > gdb the backtrace command. Strange ... Mats, which platform are you using? Some version of Linux? Can anyone help Mats get a full backtrace when the call stack goes into Xt and back out again? Maybe Xt needs to be recompiled? ben

2 participants
1 comments

[Bug: 21.5.19] src/alloc.c MALLOC_BEGIN() 19 years, 10 months

Andrey Slusar

Hi, >From alloc.c: --8<---------------cut here---------------start------------->8--- #ifdef ERROR_CHECK_MALLOC [...] #define MALLOC_BEGIN() \ do \ { \ assert (!in_malloc); \ assert (!regex_malloc_disallowed); \ in_malloc = 1; \ } \ while (0) [...] #else /* ERROR_CHECK_MALLOC */ #define MALLOC_BEGIN(block) [...] #endif /* ERROR_CHECK_MALLOC */ --8<---------------cut here---------------end--------------->8--- When ERROR_CHECK_MALLOC defined, compiling is ok - MALLOC_BEGIN is running whithout args in functions xmalloc() and xcalloc(). When is not defined, XEmacs is not compiled. 2005-02-23 Andrey Slusar <anrays(a)gmail.com> * alloc.c (MALLOC_BEGIN): MALLOC_BEGIN is not reguire arg `block'. Index: src/alloc.c =================================================================== RCS file: /pack/xemacscvs/XEmacs/xemacs/src/alloc.c,v retrieving revision 1.106 diff -u -r1.106 alloc.c --- src/alloc.c 2005/02/03 16:14:04 1.106 +++ src/alloc.c 2005/02/23 00:01:18 ＠＠ -349,7 +349,7 ＠＠ #else /* ERROR_CHECK_MALLOC */ -#define MALLOC_BEGIN(block) +#define MALLOC_BEGIN() #define FREE_OR_REALLOC_BEGIN(block) #define MALLOC_END() -- Regards, Andrey.

1 participants
0 comments

Movemail security issue (fix in SXEmacs?) 19 years, 10 months

Johann 'Myrkraverk' Oskarsson

Hi, Out of pure curtesy, I'm bringing this to your attention: http://bastard.youngs.au.com/pipermail/sxemacs-patches/2005-February/0001... There you should find all the reference urls you need to judge whether this is a vulnerability issue (one line patch, or so) or not. I'm not really sure myself. This is not the same issue as was patched for GNU Emacs, but similar. Johann -- This line is left blank intentionally

3 participants
2 comments

Mule-ization of Carbon work 19 years, 10 months

Ben Wing

Andrew -- I took a look at your code and it should not be difficult to make the strings work correctly with internationalized text. Basically, you just need to figure out what encoding of text the external API's expect and then call the appropriate conversion functions. For example, if the API's expect UTF-8, then some variation of replacing XSTRING_DATA (string) with NEW_LISP_STRING_TO_EXTERNAL (string, Qutf8) should do the trick. This returns a string in alloca() space so there is no need to free it. (The GTK code doesn't always do this currently but there is a pending patch among my workspaces to fix this.) ben

2 participants
2 comments

Xft and configure.ac status 19 years, 10 months

Stephen J. Turnbull

I've been using the sjt-xft branch pretty much exclusively for over a month now, and it's pretty stable. One really obnoxious bug that (at least for some freely available TT fonts) caused completely bogus window sizing and tab expansion has been fixed, and (if you're reasonably careful about choice of fonts) it's quite usable for ASCII-only users. To make it even more usable I've turned off the flood of debugging output, for now. I assume that would also apply to ISO-8859-1 users. The next step is to clean up charset handling a little bit (not the major improvements to Customize that are discussed in internals, just enough to allow people who are willing to use set-face-font to use non-ASCII fonts without too many gotchas), and to synch to 21.5.19. Note that sjt-xft is using Malcolm Purvis's port of configure to autoconf 2.59, so if you want to get a look at that before it goes into the mainline, this is your chance. If configured --without-xft, it should be pretty close to a vanilla 21.5.18 (actually I think it's +CVS-20041209), so you can check out the new configure on your favorite options/platforms without dealing with the deficiencies of Xft support just yet. If you do, don't forget to update the autoconf regression tests in tests/autoconf for your configuration, and give it a try. Don't forget those build reports! -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

1 participants
0 comments

Re: [PATCH] defaults.el: record and revert changing XEmacs defaults across time 19 years, 10 months

Stephen J. Turnbull

Sorry for letting this go so long. Moving discussion to xemacs-beta. Nix, if you have commit privileges in the packages, you can just create an unsupported/nix directory and put anything you want (that won't get us or our hosts sued, of course) there. If you don't, we should fix that, but I could create the directory in the meantime. >>>>> "nix" == nix <nix(a)esperi.org.uk> writes: nix> Have a package, everyone. nix> I'm not sure where it belongs; if we want both core *and* the nix> packages to be able to use it (which is kind of the point), nix> we're in a bit of a bind. Can core reasonably require new nix> packages when you upgrade it, or are they completely nix> decoupled? (I seem to recall a change to auto-mode-alist nix> construction in core that required new packages...) I've been working on packages-in-source-tarball recently, with the idea being two options: sumo-in-source, and package-bootstrap (enough to download packages from ftp.xemacs.org). What I have in mind is a three-tier approach: application packages, standard library packages, and core. Core implements the Lisp language and the editor primitives; the standard library implements the standard editor functionality and hides backward-incompatible core changes from the applications and (optionally) provides common functionality such as mail-lib; and the applications are applications. Then the source for the standard library packages (such as xemacs-base) would live in the package source tree, but would be distributed in a new standard-library tarball which would be included in source distributions that don't include the whole sumo. nix> If the core can force new packages, it should probably go in nix> xemacs-base... packages certainly can't require a new core, nix> so it can't go in core if we want the packages to be able to nix> use it without testing. nix> (This sounds rather backwards to me, given the sort of things nix> core contains; i.e., standard XEmacs things that the packages nix> can use without testing, but I understand why it's the case.) Well, there are arguments both ways. nix> Anyway, wherever it goes, here it is for people to laugh nix> at. (Adjust the (not) in the heading comments if you actually nix> accept it.) Actually the code hardly looks laughable to me. I haven't actually had a chance to try it, mind you .... ;-) Once I've done that, maybe we can add it to xemacs-base. I think something we should consider for the future is some kind of out-of-RAM database (use dbm or even just a lisp library). It also could get a submenu under help, with the submenu containing the list of default-changed-dates known to XEmacs. The main "bug" I see is that there doesn't seem to be any way to determine whether the site admin or a user changed a default, or if some package did. Maybe we could have a flag that if set would allow defaults.el to revert "rogue" changes. The code is at http://list-archive.xemacs.org/xemacs-patches/200502/msg00059.html see also http://list-archive.xemacs.org/xemacs-patches/200502/msg00040.html -- Institute of Policy and Planning Sciences http:

2 participants
2 comments

A xemacsweb commit of last night not showing up on xemacs-cvs 19 years, 10 months

Adrian Aichner

The commit happened minutes before I sent following patch: http://list-archive.xemacs.org/xemacs-patches/200502/msg00176.html Could someone please look into this? I have not found the missing xemacs-cvs mail in the mailman queue either. -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/

2 participants
1 comments

[Bug: 21.5-b19] Core dump 19 years, 10 months

The XEmacs Package Smoketest

================================================================ Dear Bug Team! ================================================================ System Info to help track down your bug: --------------------------------------- uname -a: Linux spencer 2.6.10-gentoo-r6 #1 SMP Tue Jan 25 00:57:07 CET 2005 i686 Intel(R) Pentium(R) M processor 1300MHz GenuineIntel GNU/Linux ./configure '--prefix=/src/xemacs' '--with-mule' '--package-path=/src/xemacs/xemacs-packages:/src/xemacs/mule-packages:/src/xemacs/site-packages' '--with-sound=esd' '--with-database=no' XEmacs 21.5-b19 "chives" (+CVS-20050218) configured for `i686-pc-linux'. Compilation Environment and Installation Defaults: Source code location: /src/xemacs/working Installation prefix: /src/xemacs Operating system description file: `s/linux.h' Machine description file: `m/intel386.h' Compiler version: gcc (GCC) 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1) - GCC specs file: /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/specs - Compiler command: gcc -Wall -Wno-switch -Wundef -Wsign-compare -Wno-char-subscripts -Wpacked -Wunused-parameter -g libc version: 2.3.4 Relocating allocator for buffers: no GNU version of malloc: yes - Using Doug Lea's new malloc from the GNU C Library. Window System: Compiling in support for the X window system: - X Windows headers location: /usr/X11R6/include - X Windows libraries location: /usr/X11R6/lib - Handling WM_COMMAND properly. Using Lucid menubars. Using Lucid scrollbars. Using Motif dialog boxes. Using Motif native widgets. TTY: Compiling in support for ncurses. Compiling in support for GPM (General Purpose Mouse). Images: Compiling in support for GIF images (builtin). Compiling in support for XPM images. Compiling in support for PNG images. Compiling in support for JPEG images. Compiling in support for TIFF images. Compiling in support for X-Face message headers. Sound: Compiling in support for sound (native). Compiling in support for ESD (Enlightened Sound Daemon). Databases: Internationalization: Compiling in support for Mule (multi-lingual Emacs). Compiling in support for XIM (X11R5+ I18N input method). - Using Motif to provide XIM support. Mail: Compiling in support for "file" mail spool file locking method. Other Features: Inhibiting IPv6 canonicalization at startup. Compiling in support for dynamic shared object modules. Using the new portable dumper. Compiling in support for extra debugging code. Compiling in support for runtime error checking. WARNING: --------------------------------------------------------- WARNING: XEmacs will run noticeably more slowly as a result. WARNING: Error checking is on by default for XEmacs beta releases. WARNING: --------------------------------------------------------- Backtrace ... ---------------------------------------------------------------------- (gdb) backtrace #0 0x405ca431 in kill () from /lib/libc.so.6 #1 0x080d438f in fatal_error_signal (sig=6) at emacs.c:3707 #2 0x407851e6 in __pthread_sighandler () from /lib/libpthread.so.0 #3 <signal handler called> #4 0x405ca431 in kill () from /lib/libc.so.6 #5 0x40781e99 in pthread_kill () from /lib/libpthread.so.0 #6 0x40782244 in raise () from /lib/libpthread.so.0 #7 0x405ca084 in raise () from /lib/libc.so.6 #8 0x405cb6b8 in abort () from /lib/libc.so.6 #9 0x080d5618 in really_abort () at emacs.c:4551 #10 0x080d4482 in assert_failed (file=0x82c38ff "signal.c", line=730, expr=0x82c39c0 "QUIT called from within redisplay without being properly wrapped") at emacs.c:3892 #11 0x0820b223 in check_quit () at signal.c:728 #12 0x0820addb in check_what_happened () at signal.c:458 #13 0x080dd236 in Ffuncall (nargs=2, args=0xbfffe218) at eval.c:3776 #14 0x080deb7c in call1 (fn=137393072, arg0=137770652) at eval.c:4497 #15 0x08269c81 in menu_item_descriptor_to_widget_value_1 (desc=137770652, menu_type=1, deep_p=1, filter_p=0, depth=0) at menubar-x.c:218 #16 0x08269ffd in protected_menu_item_descriptor_to_widget_value_1 (gack=0xbfffe5b0) at menubar-x.c:353 #17 0x080df687 in call_trapping_problems_2 (opaque=143285600) at eval.c:4885 #18 0x080d9f72 in call_with_condition_handler (handler=0x80df5dc <flagged_a_squirmer>, handler_arg=143285600, fun=0x80df64f <call_trapping_problems_2>, arg=143285600) at eval.c:2135 #19 0x080df6b1 in call_trapping_problems_1 (opaque=143285600) at eval.c:4891 #20 0x080d92cd in internal_catch (tag=138963416, func=0x80df689 <call_trapping_problems_1>, arg=143285600, threw=0xbfffe49c, thrown_tag=0xbfffe4a8, backtrace_before_throw=0xbfffe4a0) at eval.c:1530 #21 0x080dfaef in call_trapping_problems (warning_class=137489096, warning_string=0x82ce665 "Error during menu callback", flags=35, problem=0x0, fun=0x8269fb2 <protected_menu_item_descriptor_to_widget_value_1>, arg=0xbfffe5b0) at eval.c:5164 #22 0x080efde9 in event_stream_protect_modal_loop (error_string=0x82ce665 "Error during menu callback", bfun=0x8269fb2 <protected_menu_item_descriptor_to_widget_value_1>, barg=0xbfffe5b0, flags=32) at event-stream.c:1910 #23 0x0826a077 in protected_menu_item_descriptor_to_widget_value (desc=137770688, menu_type=1, deep_p=1, filter_p=0) at menubar-x.c:382 #24 0x0826a222 in pre_activate_callback (widget=0x9651648, unused_id=65601, client_data=0x9644ca0) at menubar-x.c:476 #25 0x0828c63c in pre_hook (w=0x9651648, client_data=0x9651630, call_data=0x9644ca0) at lwlib-Xlw.c:82 #26 0x402ef839 in XtCallCallbackList () from /usr/lib/libXt.so.6 (gdb) ---------------------------------------------------------------------- I don't know if this is related but the old bug that keeps haunting me with 21.5 has occurred twice before I get this core dump . The old bug is this: While (most often in a gnus *Group*) buffer I try open a dired buffer, Ctrl-x Ctrl-j (dired-jump-back), dired somehow gets the idea that the *Group* buffer actually is the dired buffer and reports something about a mangled subdir or something. This is not strange since the contents of a *Group* buffer doesn't look at all like a dired buffer. The odd thing is why dired somehow looses the buffer with the ls-listing and tries to continue its work with the wrong buffer. This does not always occur with gnus. It can happen with other buffers as well. Yours -- %% Mats

3 participants
3 comments

I've moved! 19 years, 10 months

email moraes＠cs dot toronto dot edu

[This is a recording] I'm no longer at the University of Toronto. If you received any message from this e-mail address other than this recording, it was spam with a forged e-mail address, because I never send e-mail from cs.toronto.edu (and have not done so for over 10 years). Please check the message headers carefully and report it to the originating Internet Service Provider (ISP). If you don't know how, please ask your own ISP or read http://tinyurl.com/38eh3 to learn how to track down the source of spam. If you are receiving this message because you inquired about jove, xcpustate, xpic, xtroff, xplaces, the HP X widgets, the CSRI malloc or any other ftp://ftp.cs.toronto.edu/pub/moraes/ software, try my web page at http://tinyurl.com/vdh3 for more information.

1 participants
0 comments

ClearCase, hijack error and itimer signal 19 years, 10 months

Roland Frank

Hello Michael, from time to time I run into problem with ClearCase, e.g. when I try to hijack a file. I then get an error and the file is not updated (although it is hijacked). I have a debug for this: Debugger entered--Lisp error: (wrong-type-argument number-char-or-marker-p t) clearcase-utl-touch-file("D:\\ws\\Sources\\adc.c") clearcase-hijack("D:\\ws\\Sources\\adc.c") #<compiled-function nil "...(4)" [buffer-file-name clearcase-hijack] 2 ("c:\\Programme\\XEmacs\\xemacs-packages\\lisp\\clearcase\\clearcase.elc " . 26474) nil>() call-interactively(clearcase-hijack-current-buffer) recursive-edit() byte-code("..." [buffer-read-only noninteractive debugger-buffer middlestart debugger-args debugger-batch-max-lines pop-to-buffer debugger-mode debugger-setup-buffer count-lines 2 "...\n" message buffer-string kill-emacs debug backtrace-debug 3 t debugger-reenable "" nil recursive-edit standard-output] 3) After running in those problems I get regularly itimer error signals. Debug information for those is here: Debugger entered--Lisp error: (error "Selecting deleted or non-existent buffer") clearcase-post-update-check-process-buffer(#<killed buffer>) clearcase-utl-list-filter(clearcase-post-update-check-process-buffer (#<killed buffer>)) clearcase-post-update-timer-function() apply(clearcase-post-update-timer-function nil) byte-code("..." [this-command inhibit-quit quit-flag match-data itimer current-itimer match-data ((store-match-data match-data)) nil itimer-uses-arguments apply itimer-function itimer-function-arguments last-event-time next-wakeup itimers time-elapsed] 5) itimer-run-expired-timers(13.953) itimer-timer-driver(nil) I hope you can use the probided information to solve the problem. Kind regards, Frank Emacs: XEmacs 21.4 (patch 13) "Rational FORTRAN" [Lucid] (i586-pc-win32) of Sun May 25 2003 on TSUNAMI Package: clearcase.el </main/laptop/156> current state: ============== (setq system-type 'windows-nt system-configuration "i586-pc-win32" emacs-version "21.4 (patch 13) \"Rational FORTRAN\" XEmacs Lucid" clearcase-clearcase-version-installed "ClearCase version 2002.05.00 (Tue Oct 30 08:27:59 2001)\nclearcase patch p2002.05.00.NT-16 (Mon Mar 17 16:45:02 2003)\nclearcase patch p2002.05.00.NT-21 (Thu Apr 24 15:54:17 2003)\nclearcase patch p2002.05.00.NT-22 (Thu Apr 24 16:17:23 2003)\nclearcase patch p2002.05.00.NT-23 (Mon Jun 16 13:44:05 2003)\nclearcase patch p2002.05.00.NT-24 (Sun Jul 6 21:59:28 2003)\nclearcase patch p2002.05.00.NT-25 (Wed Sep 24 11:53:01 2003)\nclearcase patch p2002.05.00.NT-26 (Wed Sep 24 20:12:12 2003)\nclearcase patch p2002.05.00.NT-27 (Tue Dec 9 14:37:31 2003)\n＠(#) MVFS version 2002.05.00+ (Sep 8 2003 18:46:11)cleartool 2002.05.00+ (Thu Dec 4 13:26:05 2003)\ndb_server 2002.05.00+ (Fri Nov 7 12:08:38 2003)\nVOB database schema version: 54" clearcase-cleartool-path "C:\\Programme\\Rational\\ClearCase\\bin\\cleartool.exe" clearcase-lt nil clearcase-v3 nil clearcase-v4 nil clearcase-v5 t clearcase-v6 nil clearcase-servers-online t clearcase-disable-tq '(windows-nt ms-windows cygwin cygwin32) clearcase-on-cygwin nil clearcase-setview-root nil clearcase-suppress-vc-within-mvfs t shell-file-name "C:\\WINDOWS\\system32\\cmd.exe" )

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 February 2005