October 1999 - XEmacs-Beta - XEmacs Mailing List Archives

[bug report, 21.2] font-lock face inheritance 25 years, 1 month

Olivier Galibert

In a non-color xterm, with a .emacs that activates font-lock, do a xemacs -nw file.c and start gnuserv The font lock comes as bold/underline. Then (with a good $DISPLAY), do a gnuclient file2.c. An X frame opens, with the font-lock using _both_ bold/underline and colors. The reason ? 'global, i.e. fallback, specifiers values are chosen by matching the face spec with the properties given by (get-custom-frame-properties nil). When called with nil, the first time this defun gets the properties of the currently selected frame. The result (for nil) is cached, and given again all following times. For a mono tty, the result is: (type tty class mono background dark) For a (default) X frame: (type x class color background light) For a face like font-lock-comment-face, this gives :bold t (default, taken for mono) + :foreground blue4 (for color). Incidentally, this is also the cause of the problem with the pdump. The first frame coming up in that mode has these properties: (type stream class nil background dark) ...which explains the problems I have. Now, the question is, what is the Right Way[tm] to fix that? OG.

2 participants
1 comments

[bug report 21.2] Gutter/gnuclient 25 years, 1 month

Olivier Galibert

Start an xemacs on X. Open a file in it. In an xterm, do a gnuclient -nw another_file (1) (error/warning) Error in process filter: (error Image instantiator format is invalid in this locale. [tab-control :descriptor Buffers :face default :properties (:items ([*scratch* (buffers-tab-switch-to-buffer *scratch*)]))]) ... and gnuclient explodes, probably because of that. OG.

1 participants
0 comments

Re: The latest CVS segfaults in temacs while doing update-elc 25 years, 1 month

Andreas Jaeger

Ok, here comes the results of the discussion with the glibc developers about __malloc_hook (and __free_hook etc): For efficiency reasons, __malloc_hook is used internally by glibc to initialize malloc. You're therefore not allowed to use __malloc_hook _before_ malloc is initialized. The proper way to set __malloc_hook is in __malloc_initialize_hook but not in main. Therefore we could patch XEmacs to use __malloc_initialize_hook (AFAIK emacs does this) to set the hook. But since we don't need these hooks with doug lea's malloc, the best way is to not set it all as my second patch does. glibc will not be changed - but we're going to update the documentation to clearly state these issues. Andreas -- Andreas Jaeger aj(a)suse.de aj(a)arthur.rhein-neckar.de for pgp-key finger ajaeger(a)aixd1.rhrk.uni-kl.de

1 participants
0 comments

21.1.7 crashes without '--use-system-malloc' on solaris 2.5 25 years, 1 month

Mike Fabian

I had some problems to get XEmacs 21.1.7 running on solaris 2.5. XEmacs compiled fine, but until I finally configured with '--use-system-malloc', XEmacs always crashed immediately (Segmentation fault) when I tried to start it using X-Windows. There was no lisp-backtrace. gdb said the core-file was truncated and couldn't produce a C-backtrace. `xemacs -nw' in a xterm worked OK, even without the configure option '--use-system-malloc'. With the configure option '--use-system-malloc' everything seems to be OK. Mike fabian＠mungo ~/usr/src/xemacs-cvs$ cat Installation uname -a: SunOS mungo 5.5.1 Generic_103640-24 sun4u sparc SUNW,Ultra-2 ./configure '--prefix=/dvs/stow/xemacs-21.1.7' '--with-pop' '--with-dialogs=athena' '--with-mule=yes' '--cflags=-g -O4 -fno-strength-reduce' '--with-xface=yes' '--with-canna=yes' '--site-includes=/dvs/local/include /dvs/include' '--site-libraries=/dvs/local/lib /dvs/lib' '--site-prefixes=/dvs/local /dvs' '--use-system-malloc' XEmacs 21.1.7 "Biscayne" configured for `sparc-sun-solaris2.5.1'. Where should the build process find the source code? /disk-a/fabian/usr/src/xemacs-cvs What installation prefix should install use? /dvs/stow/xemacs-21.1.7 What operating system and machine description files should XEmacs use? `s/sol2.h' and `m/sparc.h' What compiler should XEmacs be built with? gcc -g -O4 -fno-strength-reduce Should XEmacs use the GNU version of malloc? no (User chose not to use GNU allocators). 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/dt/include /usr/openwin/include Where do we find X Windows libraries? /usr/dt/lib /usr/openwin/lib Additional header files: /dvs/local/include /dvs/include Additional libraries: /dvs/local/lib /dvs/lib Additional prefixes: /dvs/local /dvs Runtime library search path: /usr/ccs/lib:/dvs/lib:/usr/dt/lib:/usr/openwin/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 X-Face message headers. Compiling in native sound support. Compiling in support for DBM. Compiling in Mule (multi-lingual) support. Compiling in XIM (X11R5+ I18N input method) support. Using Motif to provide XIM support. Compiling in support for Canna on Mule. Compiling in support for ToolTalk. 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 POP for mail access fabian＠mungo ~/usr/src/xemacs-cvs$ -- Dr. Mike Fabian <fabian(a)mpia-hd.mpg.de> Max-Planck-Institut fuer Astronomie, Koenigsstuhl 17, 69117 Heidelberg Telephone: +49(0)6221/528216

1 participants
0 comments

Re: The latest CVS segfaults in temacs while doing update-elc 25 years, 1 month

Andreas Jaeger

>>>>> Jan Vroonhof writes: Jan> I am reading this remote so I cannot check all the details. Ok, I fill you in. Jan> Andreas Jaeger <aj(a)suse.de> writes: >> Btw. just run `nm xemacs |grep malloc_hook' on the binary after applying >> my other patch - we really don't need malloc_hook if DOUG_LEA_MALLOC >> is used. Jan> Is there a documented guarantee this will never be needed? I'll happy Jan> to take your word for glibc related things, but isn't it is possible Jan> that for instance the gcc folk could decide to set it in libgcc.a? Or Jan> should I take your comment to mean that glic's malloc doesn't use the Jan> hook at all? If we compile with DOUG_LEA_MALLOC, XEmacs nowhere sets or uses __malloc_hook - besides in this one place. __malloc_hook is essential for GNU malloc - but with Doug Lea's malloc, we don't need it. glibc needs to initialize its malloc implementation and uses __malloc_hook for this initilisation. If you set __malloc_hook to NULL, the initialisation code is not executed at all - and the malloc implementation will fail. Therefore, we've got two solutions for XEmacs for now: - call malloc before setting __malloc_hook so that it gets initialised (my first patch) - don't set __malloc_hook at all. Since __malloc_hook is part of glibc and not part of gcc, we only have to deal with glibc here. Jan> Is the version in Debian potato an official released version. If not Jan> would it may be better just to make this patch when there is actually Jan> a version with this problem released? The version 2.1.2-6 from Debian is based on the current CVS version of glibc 2.1.3 - nothing official. BUT: All distributions[1] use at least some patches from the CVS archive. I don't think there's a distribution that uses plain 2.1.2 without patches. I guess that users of the current Debian potato, the latest RedHat release (6.1?) and of the coming SuSE release (6.3) who try to compile their own XEmacs, get these problems. Jan> Jan Jan> P.S. I am interpreting your patch correctly as saying glibc doesn't Jan> actually define malloc_hook until after the first malloc. Yes - and this is a bug IMO. glibc uses __malloc_hook internally - and also externally. After malloc is initialized, __malloc_hook can be used by user programs - but before malloc is initialized you've got to be careful. This is broken. But there's no trivial patch for glibc. Andreas Footnotes: [1] Ok, I know only SuSE, RedHat and Debian in this regard. -- Andreas Jaeger SuSE Labs aj(a)suse.de private aj(a)arthur.rhein-neckar.de

1 participants
0 comments

Re: The latest CVS segfaults in temacs while doing update-elc 25 years, 1 month

Jan Vroonhof

I am reading this remote so I cannot check all the details. Andreas Jaeger <aj(a)suse.de> writes: > Btw. just run `nm xemacs |grep malloc_hook' on the binary after applying > my other patch - we really don't need malloc_hook if DOUG_LEA_MALLOC > is used. Is there a documented guarantee this will never be needed? I'll happy to take your word for glibc related things, but isn't it is possible that for instance the gcc folk could decide to set it in libgcc.a? Or should I take your comment to mean that glic's malloc doesn't use the hook at all? Is the version in Debian potato an official released version. If not would it may be better just to make this patch when there is actually a version with this problem released? Jan P.S. I am interpreting your patch correctly as saying glibc doesn't actually define malloc_hook until after the first malloc.

1 participants
0 comments

Re: The latest CVS segfaults in temacs while doing update-elc 25 years, 1 month

Andreas Jaeger

>>>>> Hrvoje Niksic writes: Hrvoje> With your hack applied, my XEmacs builds and runs. If we intend to Glad to hear. Hrvoje> apply it (which we should do if glibc doesn't get fixed soon), it Apply the other one - directly and without any further #ifdef. Hrvoje> should be wrapped in appropriate #ifdef on the buggy glibc version, Hrvoje> with an accompanying comment on why it's there, to be phased out as Hrvoje> soon as glibc is fixed. Btw. just run `nm xemacs |grep malloc_hook' on the binary after applying my other patch - we really don't need malloc_hook if DOUG_LEA_MALLOC is used. Andreas -- Andreas Jaeger SuSE Labs aj(a)suse.de private aj(a)arthur.rhein-neckar.de

1 participants
0 comments

Re: The latest CVS segfaults in temacs while doing update-elc 25 years, 1 month

Hrvoje Niksic

Andreas Jaeger <aj(a)suse.de> writes: > I think I've found a big bad bug in the internal handling of > __malloc_hook in glibc's malloc implementation. Thanks for the update. > The following _hack_ should fix the bootstrapping: > --- src/emacs.c.~2~ Thu Jun 17 08:31:05 1999 > +++ src/emacs.c Thu Oct 28 16:03:22 1999 > ＠＠ -536,6 +536,7 ＠＠ > hook for a gmalloc of a potentially incompatible version. */ > /* If we're using libmcheck, the hooks have already been initialized, */ > /* don't touch them. -slb */ > + malloc (4); > __malloc_hook = NULL; > __realloc_hook = NULL; > __free_hook = NULL; With your hack applied, my XEmacs builds and runs. If we intend to apply it (which we should do if glibc doesn't get fixed soon), it should be wrapped in appropriate #ifdef on the buggy glibc version, with an accompanying comment on why it's there, to be phased out as soon as glibc is fixed.

1 participants
0 comments

Re: The latest CVS segfaults in temacs while doing update-elc 25 years, 1 month

Andreas Jaeger

Here comes the real fix - we don't need to set __malloc_hook et al if we use DOUG_LEA_MALLOC. I do know now why setting __malloc_hook to NULL fails - but a fix might take a bit longer. The appended patch is IMO the right way to fix XEmacs. Andreas P.S. CC'ed to xemacs-patches - please remove it when replying. 1999-10-28 Andreas Jaeger <aj(a)suse.de> * src/emacs.c (main_1): Don't set the malloc hooks if using DOUG_LEA_MALLOC. --- src/emacs.c.~2~ Thu Jun 17 08:31:05 1999 +++ src/emacs.c Thu Oct 28 16:43:07 1999 ＠＠ -531,7 +531,7 ＠＠ extern int malloc_cookie; #endif -#if !defined(SYSTEM_MALLOC) && !defined(HAVE_LIBMCHECK) +#if !defined(SYSTEM_MALLOC) && !defined(HAVE_LIBMCHECK) && !defined DOUG_LEA_MALLOC /* Make sure that any libraries we link against haven't installed a hook for a gmalloc of a potentially incompatible version. */ /* If we're using libmcheck, the hooks have already been initialized, */ -- Andreas Jaeger SuSE Labs aj(a)suse.de private aj(a)arthur.rhein-neckar.de

1 participants
0 comments

Re: The latest CVS segfaults in temacs while doing update-elc 25 years, 1 month

Andreas Jaeger

>>>>> Hrvoje Niksic writes: > Yoshiki Hayashi <t90553(a)mail.ecc.u-tokyo.ac.jp> writes: >> Hrvoje Niksic <hniksic(a)pc-hrvoje.srce.hr> writes: >> >> > On Wed, Oct 27, 1999 at 03:30:26PM -0400, Olivier Galibert wrote: >> > > > make[1]: *** [update-elc.stamp] Segmentation fault (core dumped) >> > > > make[1]: Leaving directory `/home/hniksic/work/emacs/debug/src' >> > > > make: *** [src] Error 2 >> >> You are using Debian potato aren't you? > Indeed, I am. >> After I upgraded glibc package to glib-2.1.2-6 I can no longer >> compile XEmacs without --with-system-malloc (vanilla XEmacs 21.2.7, >> 21.2.19, CVS version of 21.2 and 21.1). > Now, the question is whether new glibc is buggy, or whether it just > uncovers an XEmacs bug. I find the latter more probably. I can reproduce this on my system and didn't understand it first. With the old libraries it works fine - but just changing the shared libs [1] and I can't bootstrap temacs any more. I think I've found a big bad bug in the internal handling of __malloc_hook in glibc's malloc implementation. The following _hack_ should fix the bootstrapping: --- src/emacs.c.~2~ Thu Jun 17 08:31:05 1999 +++ src/emacs.c Thu Oct 28 16:03:22 1999 ＠＠ -536,6 +536,7 ＠＠ hook for a gmalloc of a potentially incompatible version. */ /* If we're using libmcheck, the hooks have already been initialized, */ /* don't touch them. -slb */ + malloc (4); __malloc_hook = NULL; __realloc_hook = NULL; __free_hook = NULL; I'm one of the glibc developers and have just send an email to the developers list to get this fixed asap in glibc. I'll keep you updated, Andreas Footnotes: [1] Please note that I use a self compiled glibc - but 2.1.2-6 is similiar to the version I'm running. -- Andreas Jaeger SuSE Labs aj(a)suse.de private aj(a)arthur.rhein-neckar.de

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