--- Begin Message ---
Subject: |
23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX |
Date: |
Sat, 6 Nov 2010 21:20:03 +0000 |
Method to replicate:
1/ Compile recent OSX Emacs from 'emacs-23' branch
2/ Launch 'emacs -Q'
3/ Press: C-x 2
4/ Move your mouse to the corner of the frame, grab it, drag up,
rescaling the vertically to minimum size
Effect: Emacs crashes, if you resize it fast enough. If you resize it
slowly, it will survive. I've discovered it as I use SizeUp, program
that allows resizing OSX windows via keyboard shortcuts.
Looks like this particular problem is related to scrollbars. If I
disable scrollbars before resizing, this doesn't happen.
In GNU Emacs 23.2.50.1 (x86_64-apple-darwin10.4.0, NS apple-appkit-1038.32)
of 2010-10-17 on imacoob.nerv.local
Windowing system distributor `Apple', version 10.3.1038
configured using `configure '--prefix=/opt/local' '--with-ns'
'--without-x' '--without-dbus' 'CC=/usr/bin/gcc-4.2' 'CFLAGS=-O2 -arch
x86_64' 'LDFLAGS=-L/opt/local/lib -arch x86_64'
'CPPFLAGS=-I/opt/local/include''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: pl_PL.UTF-8
value of $LC_CTYPE: pl_PL.UTF-8
value of $LC_MESSAGES: C
value of $LC_MONETARY: en_IE.utf-8
value of $LC_NUMERIC: en_IE.utf-8
value of $LC_TIME: en_IE.utf-8
value of $LANG: en_IE.UTF-8
value of $XMODIFIERS: nil
locale-coding-system: utf-8-unix
default enable-multibyte-characters: t
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
M-x b i g <backspace> <backspace> u g <tab> <tab> <backspace>
<backspace> <backspace> <backspace> <backspace> <backspace>
<backspace> <backspace> <backspace> <backspace> <backspace>
<backspace> <backspace> <backspace> <backspace> e m
a c s - <tab> C-w <M-backspace> r e p o r t <tab>
<return>
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...
call-interactively: Text is read-only
Making completion list...
kill-region: The mark is not set now, so there is no region
Load-path shadows:
None found.
Features:
(shadow sort mail-extr message ecomplete rfc822 mml mml-sec
password-cache mm-decode mm-bodies mm-encode mailcap mail-parse rfc2231
rfc2047 rfc2045 qp ietf-drums mailabbrev nnheader gnus-util netrc
time-date mm-util mail-prsvr gmm-utils wid-edit mailheader canlock sha1
hex-util hashcash mail-utils emacsbug help-mode view tooltip ediff-hook
vc-hooks lisp-float-type mwheel ns-win easymenu tool-bar dnd fontset
image fringe lisp-mode register page menu-bar rfn-eshadow timer select
scroll-bar mldrag 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 loaddefs button minibuffer faces cus-face files
text-properties overlay md5 base64 format env code-pages mule custom
widget hashtable-print-readable backquote make-network-process ns
multi-tty emacs)
--- End Message ---
--- Begin Message ---
Subject: |
Re: bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX |
Date: |
Tue, 08 Feb 2011 08:23:51 +0100 |
User-agent: |
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.2.14) Gecko/20110123 Thunderbird/3.1.8 |
Eli Zaretskii skrev 2011-02-08 05.57:
From: Jakub Turski<address@hidden>
Date: Mon, 7 Feb 2011 17:26:41 +0000
Cc:
This bug hasn't been fixed, has it?
Just wanted to see what are the chances of having this fixed in the
next release.
I could try fixing it as discussed near the end of this thread, but do
I have a reliable procedure for reproducing it? Is the bug OSX
specific, and if so, in what way (i.e. what OSX specific features
trigger it)?
It is Nextstep-specific, easy to trigger. I think most of the discussion in
this bug is about something else, that comes from trying to reproduce it on a
Gtk+-build. The crash is Nextstep-specific and now fixed.
Jan D.
--- End Message ---