* emacs crash
@ 2005-08-31 19:58 Philip B Giangarra
0 siblings, 0 replies; 33+ messages in thread
From: Philip B Giangarra @ 2005-08-31 19:58 UTC (permalink / raw)
This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.
Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.
In GNU Emacs 21.1.1 (sparc-sun-solaris2.8, X toolkit, Xaw3d scroll bars)
of 2002-05-28 on tx30sws004
configured using `configure --prefix=/_TOOLS_/dist/gnu-emacs-21.1/sparc-sun-solaris2.8 --with-tiff'
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: en_US.ISO8859-1
value of $LC_CTYPE: en_US.ISO8859-1
value of $LC_MESSAGES: C
value of $LC_MONETARY: en_US.ISO8859-1
value of $LC_NUMERIC: en_US.ISO8859-1
value of $LC_TIME: en_US.ISO8859-1
value of $LANG: en_US.ISO8859-1
locale-coding-system: iso-latin-1
default-enable-multibyte-characters: t
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:
I closed a frame and buffer, and the entire emacs sessions crashed with the following error message:
X protocol error: BadDrawable (invalid Pixmap or Window parameter) on protocol request 69
This happens many times per week (I use emacs extensively every day).
Thank you,
Philip Giangarra
Freescale
781-932-6021
508-294-7066
Philip.Giangarra@freescale.com
Recent input:
<help-echo> <switch-frame> <prior> <switch-frame> <help-echo>
<switch-frame> <switch-frame> <switch-frame> <switch-frame>
<S-down-mouse-3> <S-mouse-3> <pause> C-c C-a <pause>
<switch-frame> <switch-frame> <switch-frame> <S-down-mouse-3>
<S-mouse-3> <pause> C-c C-a <switch-frame> <switch-frame>
<switch-frame> <S-down-mouse-3> <S-mouse-3> <switch-frame>
<switch-frame> <switch-frame> <switch-frame> <switch-frame>
<switch-frame> <help-echo> <help-echo> <help-echo>
<menu-bar> <help-menu> <emacs-problems> <help-echo>
<help-echo> <help-echo> <switch-frame> <switch-frame>
<help-echo> C-s p i x m a p <home> C-s c r a s h <help-echo>
<help-echo> C-s C-s C-s C-s C-s C-s C-s C-s C-s C-s
C-s C-s C-s <switch-frame> <switch-frame> C-s C-s C-s
C-s C-s C-s C-s C-s C-s C-s <help-echo> <help-echo>
<help-echo> <menu-bar> <buffer> "lpg013*shell*<2>"
<help-echo> <help-echo> <help-echo> <help-echo> <menu-bar>
<help-menu> <report-emacs-bug>
Recent messages:
Fontifying spu_ch.v... (regexps............)
Updating AUTOs...done (no changes)
/proj/.ppc_draco8_design_01/design_01/d8roc/u/philg/design/SPU/blocks/spu_ch/rtl_v/spu_ch_get_fsm.v and /proj/.ppc_draco8_design_01/design_01/d8roc/u/philg/design/SPU/blocks/state_machines/channel_state_machines/hdl/spu_ch_get_fsm.v are the same file
Loading view...done
Note: file is write protected
Type C-h for help, h for commands, q to quit.
Mark saved where search started
Mark set
Mark saved where search started [2 times]
Loading emacsbug...done
^ permalink raw reply [flat|nested] 33+ messages in thread
* Emacs crash
@ 2016-06-20 14:17 Rusi
0 siblings, 0 replies; 33+ messages in thread
From: Rusi @ 2016-06-20 14:17 UTC (permalink / raw)
To: help-gnu-emacs
Can someone check this recipe for crashing emacs please?
Ubuntu 16.4 running vanilla Unity -- yes this is likely related to X/WM stuff
emacs 24.5.1
1 Start emacs with
$ emacs --daemon
init contains just this 2 line function:
(defun kill-later ()
(run-with-timer 1 nil 'save-buffers-kill-emacs))
2.
$ emacsclient -n -c somefile
[somefile exists]
3. Write something there (ie dirty it and get a '*' in modeline)
4. Remove the frame by clicking the X in the frame
5. Try to kill emacs with
$ emacsclient -c -e '(kill-later)'
6. top shows emacs running at 100% usage
7. killing it in top causes an apport crash
Note 1 Why is kill-later defined in that round-about way?
Because directly invoking save-buffers-kill-emacs from emacsclient
makes the -n option ignored
This in turn causes the save-buffers-kill-emacs to say "You have clients"
Note 2 If an emacs frame is present the save-buffer dialog appears as expected
and there is no issue
^ permalink raw reply [flat|nested] 33+ messages in thread
* emacs crash
@ 2015-02-13 15:56 Rusi
2015-02-13 16:03 ` Rusi
` (3 more replies)
0 siblings, 4 replies; 33+ messages in thread
From: Rusi @ 2015-02-13 15:56 UTC (permalink / raw)
To: help-gnu-emacs
emacs crashes with this (below)
Does not happen with -Q
Happens with -q
Can file bug report but not clear whether its debian or emacs.
Happens as follows:
Start emacs -q
Goto options set default font and pull slider to a large value
Click once -- beep.
Click again -- crash!
=================================
Fatal error 11: Segmentation fault
Backtrace:
emacs[0x8138719]
emacs[0x8120446]
emacs[0x813758e]
emacs[0x81375fb]
linux-gate.so.1(__kernel_sigreturn+0x0)[0xb7723d18]
/lib/i386-linux-gnu/libglib-2.0.so.0(g_main_loop_quit+0x18)[0xb6809548]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_cclosure_marshal_VOID__INTv+0x50)[0xb68fa920]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(+0xda5f)[0xb68f8a5f]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0x889)[0xb69127f9]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x25)[0xb69130d5]
/usr/lib/i386-linux-gnu/libgtk-3.so.0(gtk_dialog_response+0x72)[0xb6f22042]
/usr/lib/i386-linux-gnu/libgtk-3.so.0(+0x1583e7)[0xb6f223e7]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_cclosure_marshal_VOID__VOID+0x6c)[0xb68fa46c]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_closure_invoke+0x14b)[0xb68f883b]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(+0x1f855)[0xb690a855]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0xf6a)[0xb6912eda]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x25)[0xb69130d5]
/usr/lib/i386-linux-gnu/libgtk-3.so.0(gtk_button_clicked+0x71)[0xb6ebb6f1]
/usr/lib/i386-linux-gnu/libgtk-3.so.0(+0xf18cd)[0xb6ebb8cd]
/usr/lib/i386-linux-gnu/libgtk-3.so.0(+0xf1926)[0xb6ebb926]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_cclosure_marshal_VOID__VOIDv+0x27)[0xb68fa4c7]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(+0xc2e2)[0xb68f72e2]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(+0xda5f)[0xb68f8a5f]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0x889)[0xb69127f9]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x25)[0xb69130d5]
/usr/lib/i386-linux-gnu/libgtk-3.so.0(+0xef71b)[0xb6eb971b]
/usr/lib/i386-linux-gnu/libffi.so.6(ffi_call_SYSV+0x1a)[0xb5744a82]
/usr/lib/i386-linux-gnu/libffi.so.6(ffi_call+0x76)[0xb5744556]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_cclosure_marshal_generic_va+0x21d)[0xb68f93bd]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(+0xda5f)[0xb68f8a5f]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0x889)[0xb69127f9]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x25)[0xb69130d5]
/usr/lib/i386-linux-gnu/libgtk-3.so.0(+0x19d354)[0xb6f67354]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_cclosure_marshal_VOID__BOXEDv+0x4e)[0xb68fb47e]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(+0xc2e2)[0xb68f72e2]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(+0xda5f)[0xb68f8a5f]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0x889)[0xb69127f9]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x25)[0xb69130d5]
/usr/lib/i386-linux-gnu/libgtk-3.so.0(+0x19a94d)[0xb6f6494d]
/usr/lib/i386-linux-gnu/libgtk-3.so.0(+0x19be51)[0xb6f65e51]
/usr/lib/i386-linux-gnu/libgtk-3.so.0(+0x19e9e4)[0xb6f689e4]
...
Segmentation fault
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacs crash
2015-02-13 15:56 emacs crash Rusi
@ 2015-02-13 16:03 ` Rusi
2015-02-14 6:44 ` Alexis
` (2 subsequent siblings)
3 siblings, 0 replies; 33+ messages in thread
From: Rusi @ 2015-02-13 16:03 UTC (permalink / raw)
To: help-gnu-emacs
On Friday, February 13, 2015 at 9:26:37 PM UTC+5:30, Rusi wrote:
> emacs crashes with this (below)
Should have said:
emacs 24.4.1
on debian testing
xfce4
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacs crash
2015-02-13 15:56 emacs crash Rusi
2015-02-13 16:03 ` Rusi
@ 2015-02-14 6:44 ` Alexis
[not found] ` <mailman.35.1423896300.31049.help-gnu-emacs@gnu.org>
2015-02-14 17:53 ` Robert Thorpe
3 siblings, 0 replies; 33+ messages in thread
From: Alexis @ 2015-02-14 6:44 UTC (permalink / raw)
To: help-gnu-emacs
On 2015-02-14T02:56:34+1100, Rusi said:
R> emacs crashes with this (below)
R> Does not happen with -Q Happens with -q Can file bug report
but R> not clear whether its debian or emacs.
R> Happens as follows: Start emacs -q Goto options set default
font R> and pull slider to a large value Click once -- beep.
Click again R> -- crash! ================================= Fatal
error 11: R> Segmentation fault
i'm on Debian Wheezy x86_64 (+updates), running a manually
compiled Emacs 24.4.1, and have not so far managed to reproduce
this. However, i'm not sure what you mean by "Click once" and
"Click again" - where are you clicking in each instance?
Alexis.
^ permalink raw reply [flat|nested] 33+ messages in thread
[parent not found: <mailman.35.1423896300.31049.help-gnu-emacs@gnu.org>]
* Re: emacs crash
[not found] ` <mailman.35.1423896300.31049.help-gnu-emacs@gnu.org>
@ 2015-02-14 10:23 ` Rusi
2015-02-14 11:10 ` Alexis
0 siblings, 1 reply; 33+ messages in thread
From: Rusi @ 2015-02-14 10:23 UTC (permalink / raw)
To: help-gnu-emacs
On Saturday, February 14, 2015 at 12:15:02 PM UTC+5:30, Alexis wrote:
> On 2015-02-14T02:56:34+1100, Rusi said:
>
> R> emacs crashes with this (below)
>
> R> Does not happen with -Q Happens with -q Can file bug report
> but R> not clear whether its debian or emacs.
>
> R> Happens as follows: Start emacs -q Goto options set default
> font R> and pull slider to a large value Click once -- beep.
> Click again R> -- crash! ================================= Fatal
> error 11: R> Segmentation fault
>
> i'm on Debian Wheezy x86_64 (+updates), running a manually
> compiled Emacs 24.4.1, and have not so far managed to reproduce
> this. However, i'm not sure what you mean by "Click once" and
> "Click again" - where are you clicking in each instance?
>
>
> Alexis.
Menu → Options → Set Default Font → (Slide the font value up and then) SELECT (button)
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacs crash
2015-02-13 15:56 emacs crash Rusi
` (2 preceding siblings ...)
[not found] ` <mailman.35.1423896300.31049.help-gnu-emacs@gnu.org>
@ 2015-02-14 17:53 ` Robert Thorpe
3 siblings, 0 replies; 33+ messages in thread
From: Robert Thorpe @ 2015-02-14 17:53 UTC (permalink / raw)
To: Rusi; +Cc: help-gnu-emacs
Rusi <rustompmody@gmail.com> writes:
> emacs crashes with this (below)
>
> Does not happen with -Q
> Happens with -q
> Can file bug report but not clear whether its debian or emacs.
-Q disables loading of .emacs/init.el and site-start.el. -q disables
loading of .emacs/init.el but not site-start.el. So, the problem is
probably in site-start.el which is a debian file.
> Happens as follows:
> Start emacs -q
> Goto options set default font and pull slider to a large value
> Click once -- beep.
> Click again -- crash!
I see no problem on Xubuntu. You clarified that "click once" means
click on "Select". What does "Click again" mean? When I click on
select the pop-up window disappears and I see the Emacs frame with huge
text. I can click on things in the frame with no problem.
BR,
Robert Thorpe
^ permalink raw reply [flat|nested] 33+ messages in thread
* emacs crash
@ 2006-06-07 19:12 Donald Zoch
0 siblings, 0 replies; 33+ messages in thread
From: Donald Zoch @ 2006-06-07 19:12 UTC (permalink / raw)
Cc: Donald Zoch
We think we've experienced a bug in emacs
It dies with a segmentation fault.
GNU Emacs 21.4.1
Copyright (C) 2002 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.
Backtrace:
#0 0x40294fd1 in kill () from /lib/tls/libc.so.6
#1 0x080decb2 in fatal_error_signal (sig=26106) at emacs.c:354
#2 <signal handler called>
#3 0x0804fd50 in increment_row_positions (row=0x85fdd10, delta=1, delta_bytes=4) at dispnew.c:1188
#4 0x0804fdef in increment_matrix_positions (matrix=0x84df150, start=65, end=65, delta=1,
delta_bytes=1) at dispnew.c:927
#5 0x0806c3eb in try_window_id (w=0x8498798) at xdisp.c:11883
#6 0x080711a0 in redisplay_window (window=1212778392, just_this_one_p=1) at xdisp.c:10260
#7 0x080736b1 in redisplay_internal (preserve_echo_area=4) at xdisp.c:8910
#8 0x080e8ceb in read_char (commandflag=1, nmaps=2, maps=0xffffaa10, prev_event=405378092,
used_mouse_menu=0xffffaa68) at keyboard.c:2299
#9 0x080ea551 in read_key_sequence (keybuf=0xffffaba0, bufsize=30, prompt=405378092,
dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:8209
#10 0x080ec3eb in command_loop_1 () at keyboard.c:1451
#11 0x0813d39a in internal_condition_case (bfun=0x80ec1e0 <command_loop_1>, handlers=405474436,
hfun=0x80e5440 <cmd_error>) at eval.c:1267
#12 0x080e0d5e in command_loop_2 () at keyboard.c:1245
#13 0x0813d2a9 in internal_catch (tag=4, func=0x80e0d30 <command_loop_2>, arg=405378092)
at eval.c:1030
#14 0x080e0b2e in command_loop () at keyboard.c:1224
#15 0x080e0bd9 in recursive_edit_1 () at keyboard.c:950
#16 0x080e0d0e in Frecursive_edit () at keyboard.c:1006
#17 0x080dff09 in main (argc=2, argv=0xffffb254, envp=0xffffb260) at emacs.c:1547
Detail from our user on what he was doing when it crashed:
Here's the detail that I have:
Similar to the last failure I had 2 files open in buffers (size:401204B
& 995B)
with the emacs panel split in 2 vertically and a separate buffer in each.
The 401204B file was in the left pane, 995B file in the right pane.
I had just copy/pasted the 995B into the 2nd file which hadn't yet been
saved.
I left clicked the mouse to place the cursor in the left window
and the session disappeared.
I think that this time was slightly different than the last time it failed.
Last time I wasn't doing copy/paste, but was typing text,
I left clicked and then when I typed the 1st character the session
disappeared.
I think that I didn't hit a character this time.
Thanks for any help you can provide.
Donald
--
Donald Zoch
donald.zoch@amd.com
^ permalink raw reply [flat|nested] 33+ messages in thread
* emacs crash
@ 2005-04-24 10:23 joseph
2005-04-25 16:05 ` Richard Stallman
0 siblings, 1 reply; 33+ messages in thread
From: joseph @ 2005-04-24 10:23 UTC (permalink / raw)
To: bug-gnu-emacs@gnu.org
Subject: emacs crash
Reply-to: joseph@vlsidesigntools.com
FCC: ~/rmail
--text follows this line--
This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.
Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.
In GNU Emacs 21.3.1 (i386-dell-linux-gnu, X toolkit, Xaw3d scroll bars)
of 2003-09-02 on jtpc840
configured using `configure i386-dell-linux-gnu --prefix=/home/joseph/gnu/emacs-21.3
--exec-prefix=/home/joseph/gnu/emacs-21.3/linux24 --with-x-toolkit=athena'
Important settings:
value of $LC_ALL: C
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: nil
default-enable-multibyte-characters: t
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:
22 Apr 2005
create a file with the following octal dump (i.e., od -c file) in emacs 21.3.1:
0000000 h e l l o 033 4 033 S 001 h e l l o \n
0000020
These contents are "hello(esc)4(esc)S(ctrl-A)hello\n". I type them here
in representational form rather than the exact form to avoid the potential
problem of your emacs version crashing on reading this bug message and being
unable to decipher it.
When I read this very simple file with emacs version 21.3.1, the message
Fatal error (6).Aborted
appears and the emacs process aborts. It will not read this file. Interestingly,
emacs 21.3.1 will create this file and write it out. Upon deleting the corresponding
buffer and re-reading the file, it crashes. This happens every time.
Version 20.4.1 of emacs does not exhibit this problem. It creates the test file,
writes it out, and re-reads it with no difficulty after deleting the corresponding
buffer. Some problem has been introduced in the newer version leading to this
crash phenomenon.
Recent input:
C-S-n C-S-n C-S-n C-S-n C-S-n C-S-n C-S-n C-S-n C-S-n
C-S-n C-S-n <return> <next> <next> <down> <down> <down>
<down> <down> <down> <down> <down> <down> <up> <up>
<return> C-S-n C-S-n C-S-n C-S-n C-S-n C-S-n C-S-n
C-S-n C-S-n C-S-n C-S-n C-S-n C-S-n C-S-n C-S-n C-S-n
C-S-n C-S-n C-S-n C-S-n C-S-n C-S-n C-S-n <return>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <menu-bar> <help-menu> <emacs-version>
<next> <next> <next> <next> <next> <next> <prior> <prior>
<prior> <prior> <prior> <prior> <prior> <escape> x
r e p o SPC r SPC SPC SPC <return>
Recent messages:
Loading apropos...done
Loading view...done
Loading info...done
Composing main Info directory...
Mark set
Composing main Info directory...done
GNU Emacs 21.3.1 (i386-dell-linux-gnu, X toolkit, Xaw3d scroll bars) of 2003-09-02 on jtpc840
call-interactively: End of buffer
Making completion list...
Loading emacsbug...done
Joseph Patterson
VLSI Design Tools
P.O. Box 378
W. Boxford, MA 01885-0378
(978)352-7976
joseph@vlsidesigntools.com
^ permalink raw reply [flat|nested] 33+ messages in thread
* emacs crash
@ 2004-11-03 9:55 B. Anyos
2004-11-03 10:28 ` Jason Rumney
0 siblings, 1 reply; 33+ messages in thread
From: B. Anyos @ 2004-11-03 9:55 UTC (permalink / raw)
Hi,
I checked out the latest version form CVS.
I cleaned my version and compiled it from sratch.
Even tried "nmake bootstrap".
When I try to exeucte emacs it crashed with a message box:
==================
Emacs Abort Dialog
==================
"A fatal error occured!"
"Select Abort to exit, Retry to debug, Ignore to continue"
Any idea how can I fix this.
Bela
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacs crash
2004-11-03 9:55 B. Anyos
@ 2004-11-03 10:28 ` Jason Rumney
2004-11-03 10:50 ` B. Anyos
2004-11-03 11:06 ` Dhruva Krishnamurthy
0 siblings, 2 replies; 33+ messages in thread
From: Jason Rumney @ 2004-11-03 10:28 UTC (permalink / raw)
Cc: emacs-devel
B. Anyos wrote:
> When I try to exeucte emacs it crashed with a message box:
>
> ==================
> Emacs Abort Dialog
> ==================
> "A fatal error occured!"
> "Select Abort to exit, Retry to debug, Ignore to continue"
>
Did you try pressing Retry? If you have a just-in-time debugger
installed, that should show where the program is crashing.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacs crash
2004-11-03 10:28 ` Jason Rumney
@ 2004-11-03 10:50 ` B. Anyos
2004-11-03 11:21 ` Jason Rumney
2004-11-03 11:06 ` Dhruva Krishnamurthy
1 sibling, 1 reply; 33+ messages in thread
From: B. Anyos @ 2004-11-03 10:50 UTC (permalink / raw)
Cc: Jason Rumney
Jason Rumney said the following on 11/3/2004 11:28 AM:
> B. Anyos wrote:
>
>> When I try to exeucte emacs it crashed with a message box:
>>
>> ==================
>> Emacs Abort Dialog
>> ==================
>> "A fatal error occured!"
>> "Select Abort to exit, Retry to debug, Ignore to continue"
>>
> Did you try pressing Retry? If you have a just-in-time debugger
> installed, that should show where the program is crashing.
>
Sure in the meantime I did. It crashed in emacs\src\eval.c
at line 409.
DEFUN ("progn", Fprogn, Sprogn, 0, UNEVALLED, 0,
doc: /* Eval BODY forms sequentially and return value of last one.
usage: (progn BODY ...) */)
(args)
Lisp_Object args;
{
register Lisp_Object val = Qnil;
struct gcpro gcpro1;
GCPRO1 (args);
while (CONSP (args))
{
val = Feval (XCAR (args));
-> args = XCDR (args);
}
UNGCPRO;
return val;
}
Here is the stack trace:
NTDLL! 77f75a58()
Fprogn(int -1592181732) line 409
unbind_to(int 656, int 556594176) line 3124
Fbyte_code(int 18430916, int -2129052740, int 7) line 716 + 17 bytes
funcall_lambda(int -2129052976, int 3, int * 0x0082f188) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f188) line 2814 + 12 bytes
Fbyte_code(int 19015816, int -2128467840, int 4) line 688
funcall_lambda(int -2128467916, int 1, int * 0x0082f244) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f244) line 2814 + 12 bytes
Fbyte_code(int 19018312, int -2128465344, int 5) line 688
funcall_lambda(int -2128465448, int 2, int * 0x0082f304) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f304) line 2814 + 12 bytes
call2(int 556627832, int 1633770048, int -2127346688) line 2569 + 11 bytes
tty_lookup_color() line 1320
tty_defined_color() line 1385 + 18 bytes
load_face_colors(frame * 0x01334400, face * 0x015ce500, int * 0x61724310) line 1680 + 45 bytes
realize_x_face(face_cache * 0x01334400, int * 0x0082f3f8, int 0, face * 0x00000000) line 7144
realize_face(face_cache * 0x01710080, int * 0x0082f3f8, int 0, face * 0x00000000, int 0) line 7040 + 15 bytes
realize_default_face(frame * 0x812ca600) line 6967 + 17 bytes
realize_basic_faces(frame * 0x01334400) line 6834 + 9 bytes
Fdisplay_supports_face_attributes_p(int -1590125944, int -2127346688) line 6132 + 6 bytes
Ffuncall(int -2147483648, int * 0x0082f508) line 2761 + 8 bytes
Fbyte_code(int 18628360, int -2128855296, int 5) line 688
funcall_lambda(int -2128855556, int 2, int * 0x0082f5c8) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f5c8) line 2814 + 12 bytes
Fbyte_code(int 18628728, int -2128854928, int 4) line 688
funcall_lambda(int -2128855088, int 2, int * 0x0082f684) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f684) line 2814 + 12 bytes
Fbyte_code(int 18629200, int -2128854456, int 6) line 688
funcall_lambda(int -2128854656, int 3, int * 0x0082f748) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f748) line 2814 + 12 bytes
Fbyte_code(int 18634476, int -2128849180, int 5) line 688
Feval(int 8583088) line 2120
Fcondition_case(int -1589005424) line 1314 + 62 bytes
Fbyte_code(int 18634264, int -2128849392, int 9) line 864 + 17 bytes
funcall_lambda(int -2128849612, int 1, int * 0x0082f980) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f980) line 2814 + 12 bytes
call1(int 556794192, int -2127346688) line 2547 + 11 bytes
Fx_create_frame(int 0) line 4355
Ffuncall(int -2147483648, int * 0x0082fa0c) line 2758
Fbyte_code(int 18633764, int -2128849892, int 5) line 688
funcall_lambda(int -2128850016, int 1, int * 0x0082fac4) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082fac4) line 2814 + 12 bytes
Fbyte_code(int 19004120, int -2128479536, int 3) line 688
funcall_lambda(int -2128479620, int 1, int * 0x0082fb7c) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082fb7c) line 2814 + 12 bytes
Fbyte_code(int 19000176, int -2128483480, int 4) line 688
funcall_lambda(int -2128483612, int 0, int * 0x0082fc38) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082fc38) line 2814 + 12 bytes
Fbyte_code(int 19140348, int -2128343308, int 6) line 688
funcall_lambda(int -2128344604, int 0, int * 0x0082fcfc) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082fcfc) line 2814 + 12 bytes
Fbyte_code(int 19134352, int -2128349304, int 7) line 688
funcall_lambda(int -2128349488, int 0, int * 0x0082fd8c) line 2946 + 17 bytes
apply_lambda(int -2128349488, int 556594176, int 1) line 2869
Feval(int -2147483648) line 2170 + 11 bytes
top_level_2() line 1317 + 11 bytes
internal_condition_case(int (void)* 0x0100e695 top_level_2(void), int 556679768, int (void)* 0x0100e3fd cmd_error(void)) line 1368
top_level_1() line 1326 + 21 bytes
internal_catch(int 556676056, int (void)* 0x0100e6a2 top_level_1(void), int 556594176) line 1128 + 6 bytes
command_loop() line 1288
recursive_edit_1() line 981 + 5 bytes
Frecursive_edit() line 1043
main() line 1738 + 5 bytes
EMACS! mainCRTStartup + 180 bytes
KERNEL32! 77e8141a()
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacs crash
2004-11-03 10:28 ` Jason Rumney
2004-11-03 10:50 ` B. Anyos
@ 2004-11-03 11:06 ` Dhruva Krishnamurthy
2004-11-03 14:09 ` CHENG Gao
1 sibling, 1 reply; 33+ messages in thread
From: Dhruva Krishnamurthy @ 2004-11-03 11:06 UTC (permalink / raw)
Cc: B. Anyos, emacs-devel
Hello,
I had the same results on my XP box. Here goes the stack trace for
(runemacs -q):
NTDLL! 77f767cd()
Fprogn(int -1592177612) line 409
unbind_to(int 656, int 556578816) line 3124
Fbyte_code(int 18435036, int -2129048620, int 7) line 716 + 17 bytes
funcall_lambda(int -2129048856, int 3, int * 0x0082f188) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f188) line 2814 + 12 bytes
Fbyte_code(int 19019936, int -2128463720, int 4) line 688
funcall_lambda(int -2128463796, int 1, int * 0x0082f244) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f244) line 2814 + 12 bytes
Fbyte_code(int 19022432, int -2128461224, int 5) line 688
funcall_lambda(int -2128461328, int 2, int * 0x0082f304) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f304) line 2814 + 12 bytes
call2(int 556641144, int 1633580288, int -2127505408) line 2569 + 11 bytes
tty_lookup_color() line 1320
tty_defined_color() line 1385 + 18 bytes
load_face_colors(frame * 0x0130d800, face * 0x01541000, int *
0x61724310) line 1680 + 45 bytes
realize_x_face(face_cache * 0x0130d800, int * 0x0082f3f8, int 0, face
* 0x00000000) line 7144
realize_face(face_cache * 0x0170e540, int * 0x0082f3f8, int 0, face *
0x00000000, int 0) line 7040 + 15 bytes
realize_default_face(frame * 0x812cc800) line 6967 + 17 bytes
realize_basic_faces(frame * 0x0130d800) line 6834 + 9 bytes
Fdisplay_supports_face_attributes_p(int -1590109480, int -2127505408)
line 6132 + 6 bytes
Ffuncall(int -2147483648, int * 0x0082f508) line 2761 + 8 bytes
Fbyte_code(int 18632480, int -2128851176, int 5) line 688
funcall_lambda(int -2128851436, int 2, int * 0x0082f5c8) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f5c8) line 2814 + 12 bytes
Fbyte_code(int 18632848, int -2128850808, int 4) line 688
funcall_lambda(int -2128850968, int 2, int * 0x0082f684) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f684) line 2814 + 12 bytes
Fbyte_code(int 18633320, int -2128850336, int 6) line 688
funcall_lambda(int -2128850536, int 3, int * 0x0082f748) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f748) line 2814 + 12 bytes
Fbyte_code(int 18638596, int -2128845060, int 5) line 688
Feval(int 8583088) line 2120
Fcondition_case(int -1588988960) line 1314 + 62 bytes
Fbyte_code(int 18638384, int -2128845272, int 9) line 864 + 17 bytes
funcall_lambda(int -2128845492, int 1, int * 0x0082f980) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f980) line 2814 + 12 bytes
call1(int 556796240, int -2127505408) line 2547 + 11 bytes
Fx_create_frame(int 0) line 4355
Ffuncall(int -2147483648, int * 0x0082fa0c) line 2758
Fbyte_code(int 18637884, int -2128845772, int 5) line 688
funcall_lambda(int -2128845896, int 1, int * 0x0082fac4) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082fac4) line 2814 + 12 bytes
Fbyte_code(int 19008240, int -2128475416, int 3) line 688
funcall_lambda(int -2128475500, int 1, int * 0x0082fb7c) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082fb7c) line 2814 + 12 bytes
Fbyte_code(int 19004296, int -2128479360, int 4) line 688
funcall_lambda(int -2128479492, int 0, int * 0x0082fc38) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082fc38) line 2814 + 12 bytes
Fbyte_code(int 19144468, int -2128339188, int 6) line 688
funcall_lambda(int -2128340484, int 0, int * 0x0082fcfc) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082fcfc) line 2814 + 12 bytes
Fbyte_code(int 19138472, int -2128345184, int 7) line 688
funcall_lambda(int -2128345368, int 0, int * 0x0082fd8c) line 2946 + 17 bytes
apply_lambda(int -2128345368, int 556578816, int 1) line 2869
Feval(int -2147483648) line 2170 + 11 bytes
top_level_2() line 1317 + 11 bytes
internal_condition_case(int (void)* 0x0100e695 top_level_2(void), int
556684888, int (void)* 0x0100e3fd cmd_error(void)) line 1368
top_level_1() line 1326 + 21 bytes
internal_catch(int 556681176, int (void)* 0x0100e6a2
top_level_1(void), int 556578816) line 1128 + 6 bytes
command_loop() line 1288
recursive_edit_1() line 981 + 5 bytes
Frecursive_edit() line 1043
main() line 1738 + 5 bytes
EMACS! mainCRTStartup + 180 bytes
KERNEL32! 77e814c7()
On Wed, 03 Nov 2004 10:28:43 +0000, Jason Rumney <jasonr@gnu.org> wrote:
> B. Anyos wrote:
>
> > When I try to exeucte emacs it crashed with a message box:
> >
> > ==================
> > Emacs Abort Dialog
> > ==================
> > "A fatal error occured!"
> > "Select Abort to exit, Retry to debug, Ignore to continue"
> >
> Did you try pressing Retry? If you have a just-in-time debugger
> installed, that should show where the program is crashing.
-dhruva
--
Proud FSF member: #1935
http://schemer.fateback.com/
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacs crash
2004-11-03 11:06 ` Dhruva Krishnamurthy
@ 2004-11-03 14:09 ` CHENG Gao
2004-11-03 15:02 ` B. Anyos
2004-11-04 9:51 ` Richard Stallman
0 siblings, 2 replies; 33+ messages in thread
From: CHENG Gao @ 2004-11-03 14:09 UTC (permalink / raw)
I think RMS' latest commit to eval.c caused this.
,----
| CVSROOT: /cvsroot/emacs
| Module name: emacs
| Branch:
| Changes by: Richard M. Stallman <rms@gnu.org> 04/11/02 08:59:26
|
| Modified files:
| src : eval.c
|
| Log message:
| (Fcall_interactive_p): New function.
| (interactive_p): Don't test INTERACTIVE here.
| (Finteractive_p): Doc fix.
|
| (Feval): Abort if INPUT_BLOCKED_P.
|
| CVSWeb URLs:
| http://savannah.gnu.org/cgi-bin/viewcvs/emacs/emacs/src/eval.c.diff?tr1=1.221&tr2=1.222&r1=text&r2=text
`----
I have a temp solution:
open src/eval.c, go to line 1999, and change:
if (handling_signal || INPUT_BLOCKED_P)
to
if (handling_signal)
then rebuild Emacs.
Maybe it's only a workaround, not a real solution.
HTH,
--
花开花谢春不管,拂意事休对人言
水暖水寒鱼自知,会心处还期独赏
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacs crash
2004-11-03 14:09 ` CHENG Gao
@ 2004-11-03 15:02 ` B. Anyos
2004-11-04 9:51 ` Richard Stallman
2004-11-04 9:51 ` Richard Stallman
1 sibling, 1 reply; 33+ messages in thread
From: B. Anyos @ 2004-11-03 15:02 UTC (permalink / raw)
Cc: CHENG Gao
Hi,
Thanks for the tip.
It worked for me, too.
Bela
CHENG Gao said the following on 11/3/2004 15:09 PM:
> I think RMS' latest commit to eval.c caused this.
>
> ,----
> | CVSROOT: /cvsroot/emacs
> | Module name: emacs
> | Branch:
> | Changes by: Richard M. Stallman <rms@gnu.org> 04/11/02 08:59:26
> |
> | Modified files:
> | src : eval.c
> |
> | Log message:
> | (Fcall_interactive_p): New function.
> | (interactive_p): Don't test INTERACTIVE here.
> | (Finteractive_p): Doc fix.
> |
> | (Feval): Abort if INPUT_BLOCKED_P.
> |
> | CVSWeb URLs:
> | http://savannah.gnu.org/cgi-bin/viewcvs/emacs/emacs/src/eval.c.diff?tr1=1.221&tr2=1.222&r1=text&r2=text
> `----
>
> I have a temp solution:
> open src/eval.c, go to line 1999, and change:
>
> if (handling_signal || INPUT_BLOCKED_P)
>
> to
>
> if (handling_signal)
>
> then rebuild Emacs.
>
> Maybe it's only a workaround, not a real solution.
>
> HTH,
>
>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacs crash
2004-11-03 15:02 ` B. Anyos
@ 2004-11-04 9:51 ` Richard Stallman
2004-11-04 10:31 ` Jason Rumney
0 siblings, 1 reply; 33+ messages in thread
From: Richard Stallman @ 2004-11-04 9:51 UTC (permalink / raw)
Cc: chenggao, emacs-devel
Thanks for the tip.
It worked for me, too.
This may have "worked" in the sense of making the crash stop for you,
but it did not "work" for helping us to fix the bug. We need more
information to do that.
For instance, there is something really strange here:
funcall_lambda(int -2128849612, int 1, int * 0x0082f980) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f980) line 2814 + 12 bytes
call1(int 556794192, int -2127346688) line 2547 + 11 bytes
Fx_create_frame(int 0) line 4355
There is no call to Fx_create_frame in line 4355; in fact, line 4355
is far after the end of Fx_create_frame. What's going on? I need to
see where the call actually came from, and whether it was within
BLOCK_INPUT.
Can you examine the value 556794192 with xtype and see what sort of
Lisp object it is? If it is a symbol, use xsymbol to see what its
name is. See etc/DEBUG for more details on how to use these commands.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacs crash
2004-11-04 9:51 ` Richard Stallman
@ 2004-11-04 10:31 ` Jason Rumney
2004-11-04 12:52 ` B. Anyos
` (2 more replies)
0 siblings, 3 replies; 33+ messages in thread
From: Jason Rumney @ 2004-11-04 10:31 UTC (permalink / raw)
Cc: B. Anyos, emacs-devel, chenggao
Richard Stallman wrote:
>For instance, there is something really strange here:
>
> funcall_lambda(int -2128849612, int 1, int * 0x0082f980) line 2946 + 17 bytes
> Ffuncall(int -2147483648, int * 0x0082f980) line 2814 + 12 bytes
> call1(int 556794192, int -2127346688) line 2547 + 11 bytes
> Fx_create_frame(int 0) line 4355
>
>There is no call to Fx_create_frame in line 4355; in fact, line 4355
>is far after the end of Fx_create_frame. What's going on?
>
I think the user is on Windows, so that would be line 4355 of w32fns.c,
which is in Fx_create_frame.
My line numbers are slightly out, but I suspect this line (4350 in my
version):
/* Set up faces after all frame parameters are known. This call
also merges in face attributes specified for new frames. If we
don't do this, the `menu' face for instance won't have the right
colors, and the menu bar won't appear in the specified colors for
new frames. */
call1 (Qface_set_after_frame_default, frame);
It appears to be outside the BLOCK_INPUT blocks within x_create_frame.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacs crash
2004-11-04 10:31 ` Jason Rumney
@ 2004-11-04 12:52 ` B. Anyos
2004-11-04 13:08 ` Dhruva Krishnamurthy
2004-11-04 15:48 ` B. Anyos
2004-11-04 17:05 ` Jan D.
2 siblings, 1 reply; 33+ messages in thread
From: B. Anyos @ 2004-11-04 12:52 UTC (permalink / raw)
Cc: chenggao, rms, emacs-devel
It is true, I'm running emacs on Windows. So stacktrace is stopped right in
the middle of Fx_create_frame, though it seems it is over BLOCK_INPUT.
(file w32fns.c)
Anyway I tried to do what you asked for. Here's what I could figure out.
debug_print(args[0]):
face-set-after-frame-default
(struct Lisp_String *)(0xfffffff & ((struct Lisp_Symbol *) (0xfffffff & args[0]))->xname):
size 28
size_byte -1
intervals 0x00000000
data 0x01185dd0 "face-set-after-frame-default"
I hope this helps.
Unfortunately those nice commands listed in .gdbinit do not exist on MS Windows.
Any alternatives to help debugging on Windows ?
Jason Rumney said the following on 11/4/2004 11:31 AM:
> Richard Stallman wrote:
>
>> For instance, there is something really strange here:
>>
>> funcall_lambda(int -2128849612, int 1, int * 0x0082f980) line 2946
>> + 17 bytes
>> Ffuncall(int -2147483648, int * 0x0082f980) line 2814 + 12 bytes
>> call1(int 556794192, int -2127346688) line 2547 + 11 bytes
>> Fx_create_frame(int 0) line 4355
>>
>> There is no call to Fx_create_frame in line 4355; in fact, line 4355
>> is far after the end of Fx_create_frame. What's going on?
>>
> I think the user is on Windows, so that would be line 4355 of w32fns.c,
> which is in Fx_create_frame.
>
> My line numbers are slightly out, but I suspect this line (4350 in my
> version):
>
> /* Set up faces after all frame parameters are known. This call
> also merges in face attributes specified for new frames. If we
> don't do this, the `menu' face for instance won't have the right
> colors, and the menu bar won't appear in the specified colors for
> new frames. */
> call1 (Qface_set_after_frame_default, frame);
>
>
> It appears to be outside the BLOCK_INPUT blocks within x_create_frame.
>
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
>
>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacs crash
2004-11-04 12:52 ` B. Anyos
@ 2004-11-04 13:08 ` Dhruva Krishnamurthy
2004-11-05 8:38 ` Cheng Gao
0 siblings, 1 reply; 33+ messages in thread
From: Dhruva Krishnamurthy @ 2004-11-04 13:08 UTC (permalink / raw)
Cc: Emacs-Devel
Hello,
Now, this problem has encroached emacs-unicode-2 branch too. With the
automatic sync, which IMO has happened today, we have the same problem
(which leaves me with no working emacs).
-dhruva
On Thu, 04 Nov 2004 13:52:04 +0100, B. Anyos <banyos@freemail.hu> wrote:
> It is true, I'm running emacs on Windows. So stacktrace is stopped right in
> the middle of Fx_create_frame, though it seems it is over BLOCK_INPUT.
> (file w32fns.c)
>
> Anyway I tried to do what you asked for. Here's what I could figure out.
>
> debug_print(args[0]):
> face-set-after-frame-default
>
> (struct Lisp_String *)(0xfffffff & ((struct Lisp_Symbol *) (0xfffffff & args[0]))->xname):
> size 28
> size_byte -1
> intervals 0x00000000
> data 0x01185dd0 "face-set-after-frame-default"
>
> I hope this helps.
>
> Unfortunately those nice commands listed in .gdbinit do not exist on MS Windows.
> Any alternatives to help debugging on Windows ?
>
> Jason Rumney said the following on 11/4/2004 11:31 AM:
> > Richard Stallman wrote:
> >
> >> For instance, there is something really strange here:
> >>
> >> funcall_lambda(int -2128849612, int 1, int * 0x0082f980) line 2946
> >> + 17 bytes
> >> Ffuncall(int -2147483648, int * 0x0082f980) line 2814 + 12 bytes
> >> call1(int 556794192, int -2127346688) line 2547 + 11 bytes
> >> Fx_create_frame(int 0) line 4355
> >>
> >> There is no call to Fx_create_frame in line 4355; in fact, line 4355
> >> is far after the end of Fx_create_frame. What's going on?
> >>
> > I think the user is on Windows, so that would be line 4355 of w32fns.c,
> > which is in Fx_create_frame.
> >
> > My line numbers are slightly out, but I suspect this line (4350 in my
> > version):
> >
> > /* Set up faces after all frame parameters are known. This call
> > also merges in face attributes specified for new frames. If we
> > don't do this, the `menu' face for instance won't have the right
> > colors, and the menu bar won't appear in the specified colors for
> > new frames. */
> > call1 (Qface_set_after_frame_default, frame);
> >
> >
> > It appears to be outside the BLOCK_INPUT blocks within x_create_frame.
> >
> >
> >
> > _______________________________________________
> > Emacs-devel mailing list
> > Emacs-devel@gnu.org
> > http://lists.gnu.org/mailman/listinfo/emacs-devel
> >
> >
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
>
--
Proud FSF member: #1935
http://schemer.fateback.com/
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacs crash
2004-11-04 10:31 ` Jason Rumney
2004-11-04 12:52 ` B. Anyos
@ 2004-11-04 15:48 ` B. Anyos
2004-11-05 0:15 ` Richard Stallman
2004-11-04 17:05 ` Jan D.
2 siblings, 1 reply; 33+ messages in thread
From: B. Anyos @ 2004-11-04 15:48 UTC (permalink / raw)
Cc: chenggao, rms, Jason Rumney
It is true, I'm running emacs on Windows. So stacktrace is stopped right in
the middle of Fx_create_frame, though it seems it is over BLOCK_INPUT.
(file w32fns.c)
Anyway I tried to do what you asked for. Here's what I could figure out.
debug_print(args[0]):
face-set-after-frame-default
(struct Lisp_String *)(0xfffffff & ((struct Lisp_Symbol *) (0xfffffff & args[0]))->xname):
size 28
size_byte -1
intervals 0x00000000
data 0x01185dd0 "face-set-after-frame-default"
I hope this helps.
Unfortunately those nice commands listed in .gdbinit do not exist on MS Windows.
Any alternatives to help debugging on Windows ?
Jason Rumney said the following on 11/4/2004 11:31 AM:
> Richard Stallman wrote:
>
>> For instance, there is something really strange here:
>>
>> funcall_lambda(int -2128849612, int 1, int * 0x0082f980) line 2946
>> + 17 bytes
>> Ffuncall(int -2147483648, int * 0x0082f980) line 2814 + 12 bytes
>> call1(int 556794192, int -2127346688) line 2547 + 11 bytes
>> Fx_create_frame(int 0) line 4355
>>
>> There is no call to Fx_create_frame in line 4355; in fact, line 4355
>> is far after the end of Fx_create_frame. What's going on?
>>
> I think the user is on Windows, so that would be line 4355 of w32fns.c,
> which is in Fx_create_frame.
>
> My line numbers are slightly out, but I suspect this line (4350 in my
> version):
>
> /* Set up faces after all frame parameters are known. This call
> also merges in face attributes specified for new frames. If we
> don't do this, the `menu' face for instance won't have the right
> colors, and the menu bar won't appear in the specified colors for
> new frames. */
> call1 (Qface_set_after_frame_default, frame);
>
>
> It appears to be outside the BLOCK_INPUT blocks within x_create_frame.
>
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
>
>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacs crash
2004-11-04 10:31 ` Jason Rumney
2004-11-04 12:52 ` B. Anyos
2004-11-04 15:48 ` B. Anyos
@ 2004-11-04 17:05 ` Jan D.
2004-11-05 8:03 ` Stefan
2 siblings, 1 reply; 33+ messages in thread
From: Jan D. @ 2004-11-04 17:05 UTC (permalink / raw)
Cc: B. Anyos, chenggao, rms, Jason Rumney
Jason Rumney wrote:
> Richard Stallman wrote:
>
>> For instance, there is something really strange here:
>>
>> funcall_lambda(int -2128849612, int 1, int * 0x0082f980) line 2946
>> + 17 bytes
>> Ffuncall(int -2147483648, int * 0x0082f980) line 2814 + 12 bytes
>> call1(int 556794192, int -2127346688) line 2547 + 11 bytes
>> Fx_create_frame(int 0) line 4355
>>
>> There is no call to Fx_create_frame in line 4355; in fact, line 4355
>> is far after the end of Fx_create_frame. What's going on?
>>
> I think the user is on Windows, so that would be line 4355 of w32fns.c,
> which is in Fx_create_frame.
>
> My line numbers are slightly out, but I suspect this line (4350 in my
> version):
>
> /* Set up faces after all frame parameters are known. This call
> also merges in face attributes specified for new frames. If we
> don't do this, the `menu' face for instance won't have the right
> colors, and the menu bar won't appear in the specified colors for
> new frames. */
> call1 (Qface_set_after_frame_default, frame);
>
>
> It appears to be outside the BLOCK_INPUT blocks within x_create_frame.
It is outside the BLOCK_INPUT in x_create_frame, but inside another
BLOCK_INPUT.
Installed cygwin, and tried to build. Here is what I get:
#19 0x0114b433 in realize_x_face (cache=0x1b86140, attrs=0x82ec40, c=0,
base_face=0x0) at xfaces.c:7141
#20 0x0114b2ce in realize_face (cache=0x1b86140, attrs=0x82ec40, c=0,
base_face=0x0, former_face_id=0) at xfaces.c:7040
#21 0x0114ac0b in realize_default_face (f=0x16ce800) at xfaces.c:6967
#22 0x0114a942 in realize_basic_faces (f=0x16ce800) at xfaces.c:6834
#23 0x01149879 in Fdisplay_supports_face_attributes_p (attributes=23649197,
display=23914500) at xfaces.c:6132
#24 0x0101c9c6 in Ffuncall (nargs=3, args=0x82ede0) at eval.c:2760
#25 0x0110491e in Fbyte_code (bytestr=18487971, vector=18488188,
maxdepth=40)
at bytecode.c:686
#26 0x0101cdac in funcall_lambda (fun=18487924, nargs=2,
arg_vector=0x82ef24)
at eval.c:2944
Number 23: Fdisplay_supports_face_attributes_p calls
realize_basic_faces, which does BLOCK_INPUT before calling
realize_default_face.
xbacktrace:
"replace-regexp-in-string"
"tty-color-canonicalize"
"tty-color-desc"
"display-supports-face-attributes-p"
"face-spec-set-match-display"
"face-spec-choose"
"face-spec-set"
"byte-code"
"face-set-after-frame-default"
"x-create-frame"
"x-create-frame-with-faces"
"make-frame"
"frame-initialize"
"command-line"
"normal-top-level"
Why does W32 have to do "call1 (Qface_set_after_frame_default, frame);"?
The other platforms (Mac and X) does not. NOTE: I am not at all
familiar with W32, there might be a good reason.
Jan D.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacs crash
2004-11-03 14:09 ` CHENG Gao
2004-11-03 15:02 ` B. Anyos
@ 2004-11-04 9:51 ` Richard Stallman
1 sibling, 0 replies; 33+ messages in thread
From: Richard Stallman @ 2004-11-04 9:51 UTC (permalink / raw)
Cc: emacs-devel
If the crash is coming from my recent debugging check in eval.c,
and was not fixed by Jan's recent changes, then it is due to
a bug that is as yet unknown.
When a debugging assertion finds a problem, please do NOT suggest
removing the debugging assertion as a "workaround". That is not
constructive; in fact, it is likely to interfere with fixing the real
bug.
^ permalink raw reply [flat|nested] 33+ messages in thread
* emacs crash
@ 2003-10-08 12:42 Werner LEMBERG
0 siblings, 0 replies; 33+ messages in thread
From: Werner LEMBERG @ 2003-10-08 12:42 UTC (permalink / raw)
[CVS 2003-09-29]
Below is a backtrace of an Emacs crash which hasn't happened during
garbage collection. I still have this Emacs process so I can execute
your commands if necessary. IIRC, the segfault happened while
scrolling new Email (with various character sets) in Mew.
Of the variables shown under #0, `faces' and `char2b' are invalid
pointers (besides `s' and `first_s', of course).
Werner
======================================================================
Program received signal SIGSEGV, Segmentation fault.
0x08078bd3 in draw_glyphs (w=0x8f5e638, x=157, row=0x8e44590, area=TEXT_AREA,
start=0, end=62, hl=DRAW_NORMAL_TEXT, overlaps_p=0) at xdisp.c:17461
17461 BUILD_GLYPH_STRINGS (i, end, head, tail, hl, x, last_x);
(gdb) bt full
#0 0x08078bd3 in draw_glyphs (w=0x8f5e638, x=157, row=0x8e44590,
area=TEXT_AREA, start=0, end=62, hl=DRAW_NORMAL_TEXT, overlaps_p=0)
at xdisp.c:17461
c = 2747
this_face_id = 150339144
cmp_id = 2747
face_id = 150339144
base_face = (struct face *) 0x8ad25e0
char2b = (XChar2b *) 0x3fffe154
cmp = (struct composition *) 0x8f5fe80
glyph_len = 1073741826
faces = (struct face **) 0x3fffe144
first_s = (struct glyph_string *) 0x0
n = 0
head = (struct glyph_string *) 0xbfffe664
tail = (struct glyph_string *) 0xbfffe1d4
s = (struct glyph_string *) 0xabb
last_x = 973
x_reached = 149177744
i = 12
j = -1073748396
f = (struct frame *) 0x8640de8
#1 0x0807d00e in x_write_glyphs (start=0x8ff58f0, len=62) at xdisp.c:18503
start = (struct glyph *) 0x8f5fe48
x = 149177744
#2 0x08053fa5 in update_text_area (w=0x8f5e638, vpos=0) at dispnew.c:4270
current_row = (struct glyph_row *) 0x8f589f8
desired_row = (struct glyph_row *) 0x8e44590
changed_p = 0
#3 0x080543e6 in update_window_line (w=0x8f5e638, vpos=0,
mouse_face_overwritten_p=0xbfffe938) at dispnew.c:4494
w = (struct window *) 0x8f5e638
mouse_face_overwritten_p = (int *) 0x0
current_row = (struct glyph_row *) 0x8f589f8
desired_row = (struct glyph_row *) 0x8e44590
changed_p = 0
#4 0x08053d2b in update_window (w=0x8f5e638, force_p=0) at dispnew.c:4150
vpos = 0
i = 150339144
end = (struct glyph_row *) 0x8e45980
mode_line_row = (struct glyph_row *) 0x8f5fe80
header_line_row = (struct glyph_row *) 0x0
changed_p = 1
mouse_face_overwritten_p = 0
row = (struct glyph_row *) 0x8e44590
yb = 504
n_updated = 1
desired_matrix = (struct glyph_matrix *) 0x8c2abe0
paused_p = 0
preempt_count = 9
#5 0x08053793 in update_window_tree (w=0x8f94f40, force_p=0) at dispnew.c:3885
w = (struct window *) 0x8f5e638
force_p = 0
paused_p = 0
#6 0x08053778 in update_window_tree (w=0x8f97a88, force_p=0) at dispnew.c:3883
w = (struct window *) 0x8f97a88
force_p = 0
paused_p = 0
#7 0x08053691 in update_frame (f=0x8640de8, force_p=0, inhibit_hairy_id_p=0)
at dispnew.c:3822
f = (struct frame *) 0x8640de8
inhibit_hairy_id_p = 0
paused_p = 140818216
root_window = (struct window *) 0x8f97a88
#8 0x0806cdba in redisplay_internal (preserve_echo_area=0) at xdisp.c:10050
f = (struct frame *) 0x8640de8
tail = 150339144
frame = 150339144
i = 1
updated = (struct frame **) 0xbfffe9f4
n = 0
size = 50
w = (struct window *) 0x8f94f40
f = (struct frame *) 0x8f5fe80
pause = 0
must_finish = 1
tlbufpos = {charpos = 64537, bytepos = 64644}
tlendpos = {charpos = 6428, bytepos = 6508}
number_of_visible_frames = 1
count = 2
polling_stopped_here = 1
consider_all_windows_p = 1
#9 0x0806bcd0 in redisplay () at xdisp.c:9448
No locals.
#10 0x080e1375 in read_char (commandflag=1, nmaps=2, maps=0xbffff0f4,
prev_event=675054316, used_mouse_menu=0xbffff148) at keyboard.c:2495
c = 675054316
count = 0
local_getcjmp = {{__jmpbuf = {0, 0, 138441496, -1471787984, 675428364,
135432523}, __mask_was_saved = 138441496, __saved_mask = {__val = {
3221221484, 3221221484, 135432701, 675428364, 675054316, 675054316, 0,
1212183320, 675428364, 675428364, 135457263, 140715040, 2288198688,
3221221532, 135432844, 675428364, 1212183320, 64537, 135748393, 2, 0,
516296, 675054316, 3221221332, 64537, 3221221612, 135195085,
675404660, 0, 0, 135743368, 2}}}}
save_jump = {{__jmpbuf = {135740232, -1460667568, 675147572, 1,
-1073745988, 135747853}, __mask_was_saved = 64536, __saved_mask = {
__val = {3221221308, 135747862, 2834299728, 675147572, 0, 140715040, 0,
1, 3221221532, 135457649, 64536, 675147572, 2288198688, 135457649,
1215067860, 675260524, 2288198688, 135437987, 1215067860, 141495344,
142050320, 0, 1, 19, 3221221148, 135504025, 2826020352, 0, 8192, 0,
138441496, 2823179312}}}}
key_already_recorded = 0
tem = 0
save = 0
previous_echo_area_message = 675054316
also_record = 675054316
reread = 0
gcpro1 = {next = 0x486c76d4, var = 0xffffffff, nvars = 140715040}
gcpro2 = {next = 0x283c82ec, var = 0xbfffef7c, nvars = -1073746032}
last_idle_start = {tv_sec = 675054316, tv_usec = 64536}
polling_stopped_here = 0
#11 0x080e881f in read_key_sequence (keybuf=0xbffff254, bufsize=30,
prompt=675054316, dont_downcase_last=0, can_return_switch_frame=1,
fix_current_buffer=1) at keyboard.c:8825
key = 209
used_mouse_menu = 0
echo_local_start = 0
last_real_key_start = 0
keys_local_start = 0
local_first_binding = 0
from_string = 675054316
count = 2
t = 0
echo_start = 0
keys_start = 0
nmaps = 2
nmaps_allocated = 2
defs = (int *) 0xbffff0e4
submaps = (int *) 0xbffff0f4
orig_local_map = -1469255984
orig_keymap = 675054316
localized_local_map = 0
first_binding = 0
first_unbound = 31
mock_input = 0
fkey = {map = -1472400872, parent = -1472400872, start = 0, end = 0}
keytran = {map = -1471723376, parent = -1471723376, start = 0, end = 0}
delayed_switch_frame = 675054316
original_uppercase = 0
original_uppercase_position = -1
starting_buffer = (struct buffer *) 0x8632420
fake_prefixed_keys = 675054316
gcpro1 = {next = 0x0, var = 0x0, nvars = -1073745492}
#12 0x080df764 in command_loop_1 () at keyboard.c:1504
cmd = 2
lose = 2
nonundocount = 0
keybuf = {32, 98, -1073745220, 135131396, -1459750176, -1073745272,
-1073745220, 135131319, 0, 1, -1073743836, 1077983524, 135701888,
-1073744896, 17, 1076885774, 177478308, 1073775649, -1073745104, 32,
-1073745020, 0, -1073745312, -1073745452, 0, 1073741824, -1073744964,
135494457, -1073745148, -1073744768}
i = 2
no_direct = 0
prev_modiff = 6467
prev_buffer = (struct buffer *) 0x8632420
was_locked = 0
already_adjusted = 0
#13 0x08137b8d in internal_condition_case (bfun=0x80df450 <command_loop_1>,
handlers=675148004, hfun=0x80df030 <cmd_error>) at eval.c:1333
val = 150339144
c = {tag = 675054316, val = 675054316, next = 0xbffff404, gcpro = 0x0,
jmp = {{__jmpbuf = {0, 1, -1073743836, -1073744964, -1073745212, 135494457},
__mask_was_saved = 0, __saved_mask = {__val = {3221222348, 3221222100,
135494457, 0, 134530924, 335544320, 1076991992, 1076844252,
1074843024, 0 <repeats 16 times>, 3221222356, 1073787006,
1073827532, 1078006536, 1, 0, 0}}}}, backlist = 0x0,
handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2,
poll_suppress_count = 1, interrupt_input_blocked = 0, byte_stack = 0x0}
h = {handler = 675148004, var = 675054316, chosen_clause = 675054364,
tag = 0xbffff2f4, next = 0x0}
#14 0x080df2fe in command_loop_2 () at keyboard.c:1292
val = 0
#15 0x081376f5 in internal_catch (tag=675109268,
func=0x80df2e0 <command_loop_2>, arg=675054316) at eval.c:1094
tag = 150339144
c = {tag = 675109268, val = 675054316, next = 0x0, gcpro = 0x0, jmp = {
{__jmpbuf = {0, 1, -1073743836, -1073744692, -1073744924, 135493346},
__mask_was_saved = 0, __saved_mask = {__val = {3221222620, 3221222388,
135493346, 0, 3221222528, 3221222539, 0, 1077983524, 808465724,
3221222428, 1077248756, 5, 1077986688, 138389272, 138411460,
1212131096, 3221222204, 138209992, 675054316, 3221222588, 135434098,
675282372, 1212131096, 675054316, 138231648, 138411460, 675282372,
1212131096, 0, 138411460, 675282372, 137907392}}}}, backlist = 0x0,
handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2,
poll_suppress_count = 1, interrupt_input_blocked = 0, byte_stack = 0x0}
#16 0x080df2a3 in command_loop () at keyboard.c:1271
No locals.
#17 0x080deda4 in recursive_edit_1 () at keyboard.c:987
count = 1
val = 0
#18 0x080deee1 in Frecursive_edit () at keyboard.c:1043
count = 0
buffer = 0
#19 0x080ddc35 in main (argc=1, argv=0xbffff824) at emacs.c:1666
dummy = 0
stack_bottom_variable = 0 '\0'
skip_args = 0
rlim = {rlim_cur = 8388608, rlim_max = 18446744073709551615}
no_loadup = 0
junk = 0x0
#20 0x403087ee in __libc_start_main () from /lib/libc.so.6
^ permalink raw reply [flat|nested] 33+ messages in thread
* emacs crash
@ 2003-08-16 13:56 Werner LEMBERG
2003-08-18 4:52 ` Richard Stallman
0 siblings, 1 reply; 33+ messages in thread
From: Werner LEMBERG @ 2003-08-16 13:56 UTC (permalink / raw)
[This is CVS 2003-07-30]
I just got the following crash. Please tell me what I shall do.
Werner
======================================================================
Program received signal SIGSEGV, Segmentation fault.
0x081259f8 in mark_object (arg=543454268) at alloc.c:4991
4991 if (XMARKER (obj)->gcmarkbit)
#0 0x081259f8 in mark_object (arg=543454268) at alloc.c:4991
obj = 6583356
cdr_count = 0
#1 0x081255e8 in mark_object (arg=1487814016) at alloc.c:4831
size = 48
i = 0
obj = 0
cdr_count = 0
#2 0x081224b9 in mark_interval (i=0x8d8ece4, dummy=405548708) at alloc.c:1187
i = 0x2
#3 0x081710ed in traverse_intervals_noorder (tree=0x8d8ece4,
function=0x81224a0 <mark_interval>, arg=405548708) at intervals.c:207
tree = 0x8d8ece4
function = (void (*)()) 0x81224a0 <mark_interval>
arg = 405548708
#4 0x0817110e in traverse_intervals_noorder (tree=0x8d8ed00,
function=0x81224a0 <mark_interval>, arg=405548708) at intervals.c:212
tree = 0x8d8ed00
function = (void (*)()) 0x81224a0 <mark_interval>
arg = 405548708
#5 0x0817110e in traverse_intervals_noorder (tree=0x8d8ecc8,
function=0x81224a0 <mark_interval>, arg=405548708) at intervals.c:212
tree = 0x8d8ed38
function = (void (*)()) 0x81224a0 <mark_interval>
arg = 405548708
#6 0x0817110e in traverse_intervals_noorder (tree=0x8d8ee18,
function=0x81224a0 <mark_interval>, arg=405548708) at intervals.c:212
tree = 0x8d8ee18
function = (void (*)()) 0x81224a0 <mark_interval>
arg = 405548708
#7 0x0817110e in traverse_intervals_noorder (tree=0x8d8ee88,
function=0x81224a0 <mark_interval>, arg=405548708) at intervals.c:212
tree = 0x8d8ee88
function = (void (*)()) 0x81224a0 <mark_interval>
arg = 405548708
#8 0x0817110e in traverse_intervals_noorder (tree=0x8dc9684,
function=0x81224a0 <mark_interval>, arg=405548708) at intervals.c:212
tree = 0x8d8ef68
function = (void (*)()) 0x81224a0 <mark_interval>
arg = 405548708
#9 0x0817110e in traverse_intervals_noorder (tree=0x8a543e0,
function=0x81224a0 <mark_interval>, arg=405548708) at intervals.c:212
tree = 0x8d798bc
function = (void (*)()) 0x81224a0 <mark_interval>
arg = 405548708
#10 0x0817110e in traverse_intervals_noorder (tree=0x8aa91f4,
function=0x81224a0 <mark_interval>, arg=405548708) at intervals.c:212
tree = 0x8aa91f4
function = (void (*)()) 0x81224a0 <mark_interval>
arg = 405548708
#11 0x081224dd in mark_interval_tree (tree=0x8aa91f4) at alloc.c:1202
tree = 0x2
#12 0x08125bb4 in mark_buffer (buf=1219647024) at alloc.c:5098
buffer = (struct buffer *) 0x8b25630
ptr = (int *) 0x48b25630
tmp = 2
base_buffer = 2
#13 0x0812558c in mark_object (arg=1219647024) at alloc.c:4808
obj = 1219647024
cdr_count = 0
#14 0x08125a4a in mark_object (arg=677176588) at alloc.c:5008
obj = 140305676
cdr_count = 0
#15 0x0812596e in mark_object (arg=405681452) at alloc.c:4968
ptr = (struct Lisp_Symbol *) 0x82e352c
obj = 137245996
cdr_count = 0
#16 0x08125b1b in mark_object (arg=1490682944) at alloc.c:5061
ptr = (struct Lisp_Cons *) 0x8da0440
obj = 148506600
cdr_count = 0
#17 0x08125b1b in mark_object (arg=1490682952) at alloc.c:5061
ptr = (struct Lisp_Cons *) 0x8da0448
obj = 148506600
cdr_count = 0
#18 0x08125dbe in mark_buffer (buf=1218972696) at alloc.c:5150
buffer = (struct buffer *) 0x8a80c18
ptr = (int *) 0x8a80d00
tmp = 2
base_buffer = 2
#19 0x0812558c in mark_object (arg=1218972696) at alloc.c:4808
obj = 1218972696
cdr_count = 0
#20 0x08125a4a in mark_object (arg=681782748) at alloc.c:5008
obj = 144911836
cdr_count = 0
#21 0x0812596e in mark_object (arg=405706996) at alloc.c:4968
ptr = (struct Lisp_Symbol *) 0x82f5b0c
obj = 137321228
cdr_count = 0
...
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacs crash
2003-08-16 13:56 Werner LEMBERG
@ 2003-08-18 4:52 ` Richard Stallman
0 siblings, 0 replies; 33+ messages in thread
From: Richard Stallman @ 2003-08-18 4:52 UTC (permalink / raw)
Cc: emacs-devel
0x081259f8 in mark_object (arg=543454268) at alloc.c:4991
4991 if (XMARKER (obj)->gcmarkbit)
#0 0x081259f8 in mark_object (arg=543454268) at alloc.c:4991
obj = 6583356
cdr_count = 0
#1 0x081255e8 in mark_object (arg=1487814016) at alloc.c:4831
size = 48
i = 0
obj = 0
cdr_count = 0
You need to look at the objects being marked in these calls, and the
data structure they belong to, and figure out what's invalid
about the data structure.
That is the first step. After that step, there will probably be more
debugging to do, but we can't guess now what it will be.
^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2016-06-20 14:17 UTC | newest]
Thread overview: 33+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-08-31 19:58 emacs crash Philip B Giangarra
-- strict thread matches above, loose matches on Subject: below --
2016-06-20 14:17 Emacs crash Rusi
2015-02-13 15:56 emacs crash Rusi
2015-02-13 16:03 ` Rusi
2015-02-14 6:44 ` Alexis
[not found] ` <mailman.35.1423896300.31049.help-gnu-emacs@gnu.org>
2015-02-14 10:23 ` Rusi
2015-02-14 11:10 ` Alexis
2015-02-14 17:53 ` Robert Thorpe
2006-06-07 19:12 Donald Zoch
2005-04-24 10:23 joseph
2005-04-25 16:05 ` Richard Stallman
2004-11-03 9:55 B. Anyos
2004-11-03 10:28 ` Jason Rumney
2004-11-03 10:50 ` B. Anyos
2004-11-03 11:21 ` Jason Rumney
2004-11-03 11:29 ` Dhruva Krishnamurthy
2004-11-03 12:02 ` B. Anyos
2004-11-03 11:06 ` Dhruva Krishnamurthy
2004-11-03 14:09 ` CHENG Gao
2004-11-03 15:02 ` B. Anyos
2004-11-04 9:51 ` Richard Stallman
2004-11-04 10:31 ` Jason Rumney
2004-11-04 12:52 ` B. Anyos
2004-11-04 13:08 ` Dhruva Krishnamurthy
2004-11-05 8:38 ` Cheng Gao
2004-11-04 15:48 ` B. Anyos
2004-11-05 0:15 ` Richard Stallman
2004-11-04 17:05 ` Jan D.
2004-11-05 8:03 ` Stefan
2004-11-04 9:51 ` Richard Stallman
2003-10-08 12:42 Werner LEMBERG
2003-08-16 13:56 Werner LEMBERG
2003-08-18 4:52 ` Richard Stallman
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.