* bug#16140: 24.3.50; GC tries to free invalid font objects
@ 2013-12-14 9:51 Eli Zaretskii
2013-12-16 8:00 ` Dmitry Antipov
0 siblings, 1 reply; 4+ messages in thread
From: Eli Zaretskii @ 2013-12-14 9:51 UTC (permalink / raw)
To: 16140
This program:
(defun bloat-font ()
(interactive)
(let ((fonts (x-list-fonts "*")))
(while fonts
(condition-case nil (set-frame-font (car fonts)) (error nil))
(setq fonts (cdr fonts))
(redisplay))))
reveals some subtle problem in GC: we sometimes try to free font
objects that re not valid (already freed?). Here's one such case:
Program received signal SIGSEGV, Segmentation fault.
0x01160e2c in cleanup_vector (vector=0x100ed2a0) at alloc.c:2884
2884 fnt->driver->close (fnt);
(gdb) p fnt
$1 = (struct font *) 0x100ed2a0
(gdb) p fnt->driver
$2 = (struct font_driver *) 0x26
When I originally saw this, fnt->driver was NULL. I added protection
against that, but then it crashed with non-NULL but still invalid
pointer. Such pointers should never end up in font objects, so how
come they do?
In GNU Emacs 24.3.50.137 (i686-pc-mingw32)
of 2013-12-14 on HOME-C4E4A596F7
Bzr revision: 115517 eliz@gnu.org-20131214091610-1glyl0400451irx0
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
`configure --prefix=/d/usr --enable-checking=yes,glyphs 'CFLAGS=-O0
-gdwarf-2 -g3''
Important settings:
value of $LANG: ENU
locale-coding-system: cp1255
default enable-multibyte-characters: t
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
M-x r e p o r t - e m <tab> <return>
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Load-path shadows:
None found.
Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils time-date tooltip electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp
w32-common-fns disp-table w32-win w32-vars tool-bar dnd fontset image
regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode register
page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core frame cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew
greek romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process w32notify w32
multi-tty emacs)
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#16140: 24.3.50; GC tries to free invalid font objects
2013-12-14 9:51 bug#16140: 24.3.50; GC tries to free invalid font objects Eli Zaretskii
@ 2013-12-16 8:00 ` Dmitry Antipov
2013-12-16 15:26 ` Dmitry Antipov
2014-04-25 18:31 ` Johan Bockgård
0 siblings, 2 replies; 4+ messages in thread
From: Dmitry Antipov @ 2013-12-16 8:00 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 16140
On 12/14/2013 01:51 PM, Eli Zaretskii wrote:
> When I originally saw this, fnt->driver was NULL. I added protection
> against that, but then it crashed with non-NULL but still invalid
> pointer. Such pointers should never end up in font objects, so how
> come they do?
Hm...I've tried bloat-font quite a lot with my MinGW build, but didn't
see anything similar. Anyway, r115541 has an extra check for valid
font driver pointer in font objects; if you hit this eassert, please
let me know.
Dmitry
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#16140: 24.3.50; GC tries to free invalid font objects
2013-12-16 8:00 ` Dmitry Antipov
@ 2013-12-16 15:26 ` Dmitry Antipov
2014-04-25 18:31 ` Johan Bockgård
1 sibling, 0 replies; 4+ messages in thread
From: Dmitry Antipov @ 2013-12-16 15:26 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 16140
On 12/16/2013 12:00 PM, Dmitry Antipov wrote:
> On 12/14/2013 01:51 PM, Eli Zaretskii wrote:
>
>> When I originally saw this, fnt->driver was NULL. I added protection
>> against that, but then it crashed with non-NULL but still invalid
>> pointer. Such pointers should never end up in font objects, so how
>> come they do?
>
> Hm...I've tried bloat-font quite a lot with my MinGW build, but didn't
> see anything similar. Anyway, r115541 has an extra check for valid
> font driver pointer in font objects; if you hit this eassert, please
> let me know.
BTW, this may be caused by heap corruption, which I found and described
in Bug#16165.
Dmitry
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#16140: 24.3.50; GC tries to free invalid font objects
2013-12-16 8:00 ` Dmitry Antipov
2013-12-16 15:26 ` Dmitry Antipov
@ 2014-04-25 18:31 ` Johan Bockgård
1 sibling, 0 replies; 4+ messages in thread
From: Johan Bockgård @ 2014-04-25 18:31 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: 16140
Dmitry Antipov <dmantipov@yandex.ru> writes:
> On 12/14/2013 01:51 PM, Eli Zaretskii wrote:
>
>> When I originally saw this, fnt->driver was NULL. I added protection
>> against that, but then it crashed with non-NULL but still invalid
>> pointer. Such pointers should never end up in font objects, so how
>> come they do?
>
> Hm...I've tried bloat-font quite a lot with my MinGW build, but didn't
> see anything similar. Anyway, r115541 has an extra check for valid
> font driver pointer in font objects; if you hit this eassert, please
> let me know.
#0 0x00007fd1f97cba8b in raise (sig=sig@entry=6)
at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:38
#1 0x0000000000513c76 in terminate_due_to_signal (sig=sig@entry=6,
backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:382
#2 0x0000000000577794 in die (
msg=msg@entry=0x651d78 "valid_font_driver (((struct font *) vector)->driver)", file=file@entry=0x651580 "alloc.c", line=line@entry=2961) at alloc.c:6953
#3 0x000000000057bd0d in cleanup_vector (vector=0x3b7f650) at alloc.c:2961
#4 0x000000000057bdc6 in sweep_vectors () at alloc.c:3001
#5 0x000000000057d62a in gc_sweep () at alloc.c:6771
#6 Fgarbage_collect () at alloc.c:5678
I have a core file if that is of any help.
In GNU Emacs 24.4.50.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw scroll bars)
of 2014-04-13 on muon
Repository revision: 116973 monnier@iro.umontreal.ca-20140412193806-72yt4285lm8bf9nj
Windowing system distributor `The X.Org Foundation', version 11.0.11405000
System Description: Ubuntu 13.10
Configured using:
`configure --enable-checking --enable-asserts'
Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS GCONF GSETTINGS NOTIFY ACL
LIBSELINUX GNUTLS LIBXML2 FREETYPE XFT ZLIB
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-04-25 18:31 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-12-14 9:51 bug#16140: 24.3.50; GC tries to free invalid font objects Eli Zaretskii
2013-12-16 8:00 ` Dmitry Antipov
2013-12-16 15:26 ` Dmitry Antipov
2014-04-25 18:31 ` Johan Bockgård
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.