Re: Segmentation fault using font '7x13bold'
> > > Here's a simple test case that crashes reliably for me: > > > > > > $ emacs -Q -eval '(let ((f (make-temp-file "bang"))) (set-frame-font > > > "9x15") (with-temp-file f (insert 27 44 98 105 27 40 66)) > > > (find-alternate-file f))' > > > Fatal error (11)Segmentation fault > > > > It doesn't crash for me. > > It could be something specific with the fonts that are actually > installed. Can you both tell what font gets used when you specify the > 9x15 font? What is the full spec of the font Emacs uses? This is what I get if I do C-u C-x = on the character that's displayed in the buffer: character: ? (3945, #o7551, #xf69, U+00E9) charset: latin-iso8859-15 (Right-Hand Part of Latin Alphabet 9 (ISO/IEC 8859-15): ISO-IR-203.) code point: #x69 syntax: w which means: word category: l:Latin buffer code: #x8E #xE9 file code: ESC #x2C #x62 #x69 (encoded by coding system iso-2022-7bit) display: by this font (glyph code) -Misc-Fixed-Medium-R-Normal--15-140-75-75-C-90-ISO8859-15 (#xE9) > Also, what does "M-x report-emacs-bug RET" put in the buffer as the > values of important variables, for both of you? Well, as it works for me, I guess Chris's values are of more interest, but here they are anyway: In GNU Emacs 22.0.50.12 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2006-05-15 on kahikatea.snap.net.nz X server distributor `The X.Org Foundation', version 11.0.7000 configured using `configure 'CFLAGS=-g3'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Fundamental Minor modes in effect: tooltip-mode: t auto-compression-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t line-number-mode: t transient-mark-mode: identity Recent input: C-u C-x = C-h c C-x = C-h k C-x = M-x r e p o r t SPC e m a c s SPC b u f g Recent messages: For information about the GNU Project and its goals, type C-h C-p. Loading descr-text...done Loading composite...done Loading wid-edit...done Type C-x 1 to remove help window. Char: ? (3945, #o7551, #xf69, file ...) point=1 of 1 (0%) column=0 C-x = runs the command what-cursor-position Loading emacsbug... Loading regexp-opt...done Loading emacsbug...done -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Segmentation fault using font '7x13bold'
> From: Nick Roberts <[EMAIL PROTECTED]> > Date: Sat, 20 May 2006 10:47:33 +1200 > Cc: emacs-pretest-bug@gnu.org > > > Here's a simple test case that crashes reliably for me: > > > > $ emacs -Q -eval '(let ((f (make-temp-file "bang"))) (set-frame-font > > "9x15") (with-temp-file f (insert 27 44 98 105 27 40 66)) > > (find-alternate-file f))' > > Fatal error (11)Segmentation fault > > It doesn't crash for me. It could be something specific with the fonts that are actually installed. Can you both tell what font gets used when you specify the 9x15 font? What is the full spec of the font Emacs uses? Also, what does "M-x report-emacs-bug RET" put in the buffer as the values of important variables, for both of you? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Segmentation fault using font '7x13bold'
> Here's a simple test case that crashes reliably for me: > > $ emacs -Q -eval '(let ((f (make-temp-file "bang"))) (set-frame-font > "9x15") (with-temp-file f (insert 27 44 98 105 27 40 66)) > (find-alternate-file f))' > Fatal error (11)Segmentation fault It doesn't crash for me. xbacktrace is a user-defined command in .gdbinit in the src directory. You need to start gdb in that directory (or 'source' it). -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Segmentation fault using font '7x13bold'
Here's a simple test case that crashes reliably for me: $ emacs -Q -eval '(let ((f (make-temp-file "bang"))) (set-frame-font "9x15") (with-temp-file f (insert 27 44 98 105 27 40 66)) (find-alternate-file f))' Fatal error (11)Segmentation fault $ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Segmentation fault using font '7x13bold'
On 5/18/06, I wrote:
I just updated my Emacs source tree from CVS and rebuilt. I visited
the Changelog file and paged down 4 times and Emacs crashed.
I've found what it was in the ChangeLog file which was causing the
crash - it doesn't like the accented characters in Jérôme Marant's
name. Jérôme's name appears 4 times in the ChangeLog, but only the
first one causes the crash.
I pulled them out into 4 separate files using this command:
grep Marant ~/programs/emacs/ChangeLog | awk '{print $2}' | split -l1
Then ran Emacs on each of them:
$ emacs xaa
Fatal error (11)Segmentation fault
$ emacs xab
$ emacs xac
$ emacs xad
using 'od' to see the contents of the files:
$ for i in xa?; do echo $i; od -tx1 $i; done
xaa
000 4a 1b 2c 62 69 1b 28 42 72 1b 2c 62 74 1b 28 42
020 6d 65 0a
023
xab
000 4a 1b 2c 41 69 1b 28 42 72 1b 2c 41 74 1b 28 42
020 6d 65 0a
023
xac
000 4a 1b 2c 41 69 1b 28 42 72 1b 2c 41 74 1b 28 42
020 6d 65 0a
023
xad
000 4a 65 72 6f 6d 65 0a
007
$
- note that both the 'e' and the 'o' take up 7 bytes:
J (4a) e (1b 2c 62 69 1b 28 42) r (72) o (1b 2c 62 74 1b 28 42) m (6d) e (65) 0a
This happens with a one-line .emacs file, such as:
$ cat ~/.emacs
(set-frame-font "9x15")
$
It doesn't happen if I comment that line out.
Chris.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Re: How to use xft font in unicode-xft branch
Jan Djärv wrote: >Well, that should work, it works here. The -fn switch is currently the only way to select >a font. > > Jan D. I think that the configure script does not contain the check for --with-xft for some reason. After rebuilding it with autoconf and configuring and buiding emacs with it everything works. Best regards, Slavi Agafonkin www.imperia.net ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
emacs-unicode-2 fontset bug
Dear all, After many trials, I think I found another bug of emacs-unicode-2 branch. I have the following settings in ~/.Xresources: ,[ ~/.Xresources ] | Emacs.Fontset-0: -*-*-medium-r-*-*-16-*-*-*-*-*-fontset-unicode,\ | ascii:-*-terminus-medium-r-*-*-16-*-*-*-*-iso8859-1,\ | mule-unicode-2500-33ff:-gnu-unifont-medium-r-*-*-16-*-*-*-*-*-iso10646-1,\ | mule-unicode-e000-:-gnu-unifont-medium-r-*-*-16-*-*-*-*-*-iso10646-1,\ | mule-unicode-0100-24ff:-gnu-unifont-medium-r-*-*-16-*-*-*-*-*-iso10646-1 | Emacs.Font: fontset-unicode ` In emacs-unicode-2, the font for ascii will be a font that matches "-*-*-medium-r-*-*-16-*-*-*-*-*" instead of "-*-terminus-medium-r-*-*-16-*-*-*-*-iso8859-1". However, emacs 21.3 will correctly pick up the font matches "-*-terminus-medium-r-*-*-16-*-*-*-*-iso8859-1". Here is the output of describe-fontset in emacs 23 and 21.3: Fontset: -*-*-medium-r-*-*-16-*-*-*-*-*-fontset-unicode CHAR RANGE (CODE RANGE) FONT NAME (REQUESTED and [OPENED]) C-@ .. ÿ (#x43 .. #xFF) -*-terminus-medium-r-*-*-*-*-*-*-*-*-iso8859-1 Ä .. ã¿ (#x100 .. #x33FF) -gnu-unifont-medium-r-*-*-*-*-*-*-*-*-iso10646-1 ã .. í¿¿ (#x3400 .. #xDFFF) -*-terminus-medium-r-*-*-*-*-*-*-*-*-iso8859-1 î .. ï¿¿ (#xE000 .. #x) -gnu-unifont-medium-r-*-*-*-*-*-*-*-*-iso10646-1 ð .. ÿ (#x1 .. #x3F) -*-terminus-medium-r-*-*-*-*-*-*-*-*-iso8859-1 default -*-terminus-medium-r-*-*-*-*-*-*-*-*-iso8859-1 -- C-@ .. DEL -*-*-*-*-*-*-*-*-*-*-*-*-iso8859-1 -*-*-*-*-*-*-*-*-*-*-*-*-iso8859-2 -*-*-*-*-*-*-*-*-*-*-*-*-iso8859-3 -*-*-*-*-*-*-*-*-*-*-*-*-iso8859-4 -*-*-*-*-*-*-*-*-*-*-*-*-iso8859-9 -*-*-*-*-*-*-*-*-*-*-*-*-iso8859-10 -*-*-*-*-*-*-*-*-*-*-*-*-iso8859-13 -*-*-*-*-*-*-*-*-*-*-*-*-iso8859-14 -*-*-*-*-*-*-*-*-*-*-*-*-iso8859-15 -*-*-*-*-*-*-*-*-*-*-*-*-viscii1.1-1 -*-*-*-*-*-*-*-*-*-*-*-*-iso8859-1  ..  (#x80 .. #x9F) -*-*-*-*-*-*-*-*-*-*-*-*-gb2312.1980* -*-*-*-*-*-*-*-*-*-*-*-*-jisx0208* -*-*-*-*-*-*-*-*-*-*-*-*-ksc5601.1987* -*-*-*-*-*-*-*-*-*-*-*-*-cns11643.1992-1 -*-*-*-*-*-*-*-*-*-*-*-*-cns11643.1992-2 -*-*-*-*-*-*-*-*-*-*-*-*-cns11643.1992-3 -*-*-*-*-*-*-*-*-*-*-*-*-cns11643.1992-4 -*-*-*-*-*-*-*-*-*-*-*-*-cns11643.1992-5 -*-*-*-*-*-*-*-*-*-*-*-*-cns11643.1992-6 -*-*-*-*-*-*-*-*-*-*-*-*-cns11643.1992-7 -*-*-*-*-*-*-*-*-*-*-*-*-big5* -*-*-*-*-*-*-*-*-*-*-*-*-jisx0213.2000-1 -*-*-*-*-*-*-*-*-*-*-*-*-jisx0213.2004-1 -*-*-*-*-*-*-*-*-*-*-*-*-jisx0212* -*-*-*-*-*-*-*-*-*-*-*-*-iso10646-1 -gnu-unifont-*-*-*-*-*-*-*-*-*-*-iso10646-1 -mutt-clearlyu-*-*-*-*-*-*-*-*-*-*-iso10646-1  .. ͯ (#xA0 .. #x36F) -*-*-*-*-*-*-*-*-*-*-*-*-iso8859-1 -*-*-*-*-*-*-*-*-*-*-*-*-iso8859-2 -*-*-*-*-*-*-*-*-*-*-*-*-iso8859-3 -*-*-*-*-*-*-*-*-*-*-*-*-iso8859-4 -*-*-*-*-*-*-*-*-*-*-*-*-iso8859-9 -*-*-*-*-*-*-*-*-*-*-*-*-iso8859-10 -*-*-*-*-*-*-*-*-*-*-*-*-iso8859-13 -*-*-*-*-*-*-*-*-*-*-*-*-iso8859-14 -*-*-*-*-*-*-*-*-*-*-*-*-iso8859-15 -*-*-*-*-*-*-*-*-*-*-*-*-viscii1.1-1 Í° .. Ï¡ (#x370 .. #x3E1) -*-*-*-*-*-*-*-*-*-*-*-*-iso8859-7 Ï¢ .. ϯ (#x3E2 .. #x3EF) -*-*-*-*-*-*-*-*-*-*-*-*-gb2312.1980* -*-*-*-*-*-*-*-*-*-*-*-*-jisx0208* -*-*-*-*-*-*-*-*-*-*-*-*-ksc5601.1987* -*-*-*-*-*-*-*-*-*-*-*-*-cns11643.1992-1 -*-*-*-*-*-*-*-*-*-*-*-*-cns11643.1992-2 -*-*-*-*-*-*-*-*-*-*-*-*-cns11643.1992-3 -*-*-*-*-*-*-*-*-*-*-*-*-cns11643.1992-4 -*-*-*-*-*-*-*-*-*-*-*-*-cns11643.1992-5 -*-*-*-*-*-*-*-*-*-*-*-*-cns11643.1992-6 -*-*-*-*-*-*-*-*-*-*-*-*-cns11643.1992-7 -*-*-*-*-*-*-*-*-*-*-*-*-big5* -*-*-*-*-*-*-*-*-*-*-*-*-jisx0213.2000-1 -*-*-*-*-*-*-*-*-*-*-*-*-jisx0213.2004-1 -*-*-*-*-*-*-*-*-*-*-*-*-jisx0212* -*-*-*-*-*-*-*-*-*-*-*-*-iso10646-1 -gnu-unifont-*-*-*-*-*-*-*-*-*-*-iso10646-1 -mutt-clearlyu-*-*-*-*-*-*-*-*-*-*-iso10646-1 Ï° .. ϳ (#x3F0 .. #x3F3) -*-*-*-*-*-*-*-*-*-*-*-*-iso8859-7 Ï´ .. Ï¿ (#x3F4 .. #x3FF) -*-*-*-*-*-*-*-*-*-*-*-*-gb2312.1980* -*-*-*-*-*-*-*-*-*-*-*-*-jisx0208* -*-*-*-*-*-*-*-*-*-*-*-*-ksc5601.1987* -*-*-*-*-*-*-*-*-*-*-*-*-cns11643.1992-1 -*-*-*-*-*-*-*-*-*-*-*-*-cns11643.1992-2 -*-*-*-*-*-*-*-*-*-*-*-*-cns11643.1992-3 -*-*-*-*-*-*-*-*-*-*-*-*-cns11643.1992-4 -*-*-*-*-*-*-*-*-*-*-*-*-cns11643.1992-5 -*-*-*-*-*-*-*-*-*-*-*-*-cns11643.1992-6 -*-*-*-*-*-*-*-*-*-*-*-*-cns11643.1992-7 -*-*-*-*-*-*-*-*-*-*-*-*-big5* -*-*-*-*-*-*-*-*-*-*-*-*-jisx0213.2000-1 -*-*-*-*-*-*-*-*-*-*-*-*-jisx0213.2004-1 -*-*-*-*-*-*-*-*-*-*-*-*-jisx0212* -*-*-*-*-*-*-*-*-*-*-*-*-iso10646-1 -gnu-unifont-*-*-*-*-*-*-*-*-*-*-iso10646-1 -mutt-clearlyu-*-*-*-*-*-*-*-*-*-*-iso10646-1 Ð .. Ó¿ (#x400 .. #x4FF) -*-*-*-*-*-*-*-*-*-*-*-*-iso8859-5 -*-*-*-*-*-*-*-*-*-*-*-*-microsoft-cp1251 -*-*-*-*-*-*-*-*-*-*-*-*-koi8-r Ô .. Ö (#x500 .. #x58F) -*-*-*-*-*-*-*-*-*-*-*-*-gb2312.1980* -*-*-*-*-*
Re: gud-tooltip-mode: gdb-prompt: Wrong number of arguments
> "Nick" == Nick Roberts <[EMAIL PROTECTED]> writes: Nick> Nick> Are you suggesting that I remove one so that the user isn't confused? The problem is that both commands gdb and gdba print the same command in the mini-buffer. I think a user would accept/understand that "M-x gdb -> gdb --annotate=3" and "M-x gdb -> gdb --fullname" behave differently. But now we have "M-x gdba -> gdb --annotate=3 core" which works and "M-x gdb -> gdb --annotate=3 core" that doesn't work. Besides it's incompatible to older emacs versions and how the user would call gdb in the shell. >> BTW when I strip "source " from the filename by adding: >> (if (and file (string-match "^source " file)) >> (setq file (replace-match "" t t file))) Nick> You can use that as a local patch, if you like, but I don't want to Nick> install such a hack. What happens if the file is called "source Nick> filenames can have spaces.c" for example? Very unlikely IMHO: no directory, white space in filename and "source" as first part of the filename. I make that a defadvice for me. Nick> Yes, the new interface is too inefficient at times. Its an ongoing Nick> process, but after the release (we're already two years nearer than Nick> we were two years ago), the real question is not how much nearer, but how far away :-(. Nick> Well it's caused by the way Emacs uses the annotations. Maybe it Nick> could be done better, but its the best that I could do. For such a Nick> large image and core you're probably better off using "gdb Nick> -fullname". I guess I have to go back to --fullname and wait for GDB/MI. Thanks for your detailed explanations. Klaus -- -- | Klaus Zeitler Lucent Technologies | | Email: [EMAIL PROTECTED] | -- --- Committee, n.: A group of men who individually can do nothing but as a group decide that nothing can be done. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: gud-tooltip-mode: gdb-prompt: Wrong number of arguments
> Not sure what you mean with old behaviour. "gdb --fullname" which is what Emacs 21 (and earlier) uses, although the fullname option was never visible in the command in the minibuffer. > Should I see a difference (as > long I don't set gdb-many-windows) between "M-x gdb" and "M-x gdba". Both > start by printing "gdb -annotate=3 " and then give me a gdb and > a source window. The only difference is at startup. 'M-x gdba' presupposes "-annotate=3" and is therefore ready for the "source" annotation that you see, whereas 'M-x gdb' has to look at the markup output to work out whether gdb has been invoked with "-annotate=3" or "-fullname" and gets caught out because "source" is not usually the first annotation. I'm sure the code could be further hacked to deal with this case but I don't think the benefits justify the risks at this point in the development cycle. > Isn't that confusing for the user when "gdb -annotate=3 core" > works in one case, but not the other? M-x gdb works with "-fullname" and, in almost all cases, with "-annotate=3". M-x gdba doesn't work with "-fullname", but in all cases with "-annotate=3". Are you suggesting that I remove one so that the user isn't confused? > BTW when I strip "source " from the filename by adding: > (if (and file (string-match "^source " file)) > (setq file (replace-match "" t t file))) > to the beginning gud-find-file, I can call gdb the usual way, i.e. with > and core like I would do in the shell. You can use that as a local patch, if you like, but I don't want to install such a hack. What happens if the file is called "source filenames can have spaces.c" for example? > I also have serious performance issues with the new gdb interface, e.g. > gdb --fullname core > and then "up" or "bt" in gdb takes a bit more than 20 seconds, whereas > gdba -annotate=3 core > and then "up" or "bt" needs 2 and a half minutes. Yes, the new interface is too inefficient at times. Its an ongoing process, but after the release (we're already two years nearer than we were two years ago), things should get better when we move from annotations to GDB/MI. > This is almost certainly not an emacs problem, but seems to be caused by > the --annotate=3 option for gdb and of course our image size (125 MB and > 155 for the core file). Well it's caused by the way Emacs uses the annotations. Maybe it could be done better, but its the best that I could do. For such a large image and core you're probably better off using "gdb -fullname". > Does "--annotate" even make sense when analyzing a core? Well you can't step through the program or set breakpoints, but if you want to see the stack, the locals, examine memory... certainly it does. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: gud-tooltip-mode: gdb-prompt: Wrong number of arguments
> "Nick" == Nick Roberts <[EMAIL PROTECTED]> writes: Nick> Nick> I can suggest two workarounds: Nick> Nick> 1) Specify the core file later: Nick> Nick>Run gdb (like this): gdb --annotate=3 emacs Nick> Nick>Then in the GUD buffer: Nick> Nick>(gdb) core ~/emacs/src/core.3491 Nick> Nick> 2) Use 'M-x gdba', which should work how you want but won't give you Nick>the old behaviour. Yes both your 2 suggested methods work fine, but this doesn't look like a consistent user interface. Not sure what you mean with old behaviour. Should I see a difference (as long I don't set gdb-many-windows) between "M-x gdb" and "M-x gdba". Both start by printing "gdb -annotate=3 " and then give me a gdb and a source window. Isn't that confusing for the user when "gdb -annotate=3 core" works in one case, but not the other? BTW when I strip "source " from the filename by adding: (if (and file (string-match "^source " file)) (setq file (replace-match "" t t file))) to the beginning gud-find-file, I can call gdb the usual way, i.e. with and core like I would do in the shell. I also have serious performance issues with the new gdb interface, e.g. gdb --fullname core and then "up" or "bt" in gdb takes a bit more than 20 seconds, whereas gdba -annotate=3 core and then "up" or "bt" needs 2 and a half minutes. This is almost certainly not an emacs problem, but seems to be caused by the --annotate=3 option for gdb and of course our image size (125 MB and 155 for the core file). Does "--annotate" even make sense when analyzing a core? Klaus -- -- | Klaus Zeitler Lucent Technologies | | Email: [EMAIL PROTECTED] | -- --- The purpose of a windowing system is to put some amusing fluff around your one almighty emacs window. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Fontification problem with fancy diary display
After getting some help on emacs-devel re multiline font-lock patterns, I've checked in what I think is a fix for this. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Click on fancy diary entry cause error if diary buffer was killed
I think this is fixed now. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
