Emacs carbon crash, and beginner question...

Emacs carbon crash, and beginner question...

[Martin Fredriksson]

I just experienced a couple of crashes in Emacs carbon (current build). 
  Just died, no message, nothing.  Yes, yes, I know this is a stupid 
thing to say to you all; I'm just setting the stage for following even 
lamer question:

Is there a quick way to read up on how to get Emacs (particularly 
Carbon) to log more, run it in debug mode, or otherwise helpful things 
to get some more info about intermittent crash problems?  Just knowing 
whether it was Emacs itself which decided to quit silently or if some 
OS function is the source of problem would be very useful.  I guess 
what I'm asking for is pointer to docs to read, tips, etc, with the 
goal of getting a quick start into more serious Emacs debugging.

/m

Re: Emacs carbon crash, and beginner question...

[David Kastrup]

Martin Fredriksson <m@rfc.se> writes:

> I just experienced a couple of crashes in Emacs carbon (current
> build). Just died, no message, nothing.  Yes, yes, I know this is a
> stupid thing to say to you all; I'm just setting the stage for
> following even lamer question:
>
> Is there a quick way to read up on how to get Emacs (particularly
> Carbon) to log more, run it in debug mode, or otherwise helpful
> things to get some more info about intermittent crash problems?
> Just knowing whether it was Emacs itself which decided to quit
> silently or if some OS function is the source of problem would be
> very useful.  I guess what I'm asking for is pointer to docs to
> read, tips, etc, with the goal of getting a quick start into more
> serious Emacs debugging.

You could try looking into the etc/DEBUG file.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs carbon crash, and beginner question...

[Martin Fredriksson]

On 11 feb 2005, at 14.47, David Kastrup wrote:

> You could try looking into the etc/DEBUG file.

Of course.  And another "of course" is gdb.  Don't know why I wasn't 
thinking....

I seem to be able to trigger is by doing outline operations.  When it 
happened I used AUCTeX and LaTeX source. The backtrace (included below) 
seems to indicate internal problem?  I'll start running tests using 
only distrib stuff and with emacs -q and try to get a better bug report 
together, but I enclose the trace here anyway in case anyone can say 
anything based on it?

Program received signal SIGABRT, Aborted.
0x900429ac in kill ()
(gdb) bt
#0  0x900429ac in kill ()
#1  0x9009eb1c in abort ()
#2  0x0002fe44 in find_first_unchanged_at_end_row (w=0x11653e0, 
delta=0x0, delta_bytes=0xbfffd934) at xdisp.c:13128
#3  0x0003079c in try_window_id (w=0xbfffd934) at xdisp.c:13559
#4  0x0002d758 in redisplay_window (window=18240484, just_this_one_p=1) 
at xdisp.c:12104
#5  0x0002ae60 in redisplay_window_1 (window=0) at xdisp.c:10826
#6  0x000e1c10 in internal_condition_case_1 (bfun=0x2ae24 
<redisplay_window_1>, arg=18240484, handlers=5719349, hfun=0x2ad94 
<redisplay_window_error>) at eval.c:1426
#7  0x0002a530 in redisplay_internal (preserve_echo_area=0) at 
xdisp.c:10448
#8  0x0007c1a0 in read_char (commandflag=1, nmaps=5, maps=0xbfffef10, 
prev_event=58721281, used_mouse_menu=0xbffff014) at keyboard.c:2540
#9  0x000848e0 in read_key_sequence (keybuf=0xbffff0e0, bufsize=30, 
prompt=58721281, dont_downcase_last=0, can_return_switch_frame=1, 
fix_current_buffer=1) at keyboard.c:8799
#10 0x00079eac in command_loop_1 () at keyboard.c:1534
#11 0x000e1aa4 in internal_condition_case (bfun=0x799f0 
<command_loop_1>, handlers=58766425, hfun=0x79380 <cmd_error>) at 
eval.c:1385
#12 0x000797a8 in command_loop_2 () at keyboard.c:1315
#13 0x000e1500 in internal_catch (tag=0, func=0x79768 <command_loop_2>, 
arg=58721281) at eval.c:1144
#14 0x00079700 in command_loop () at keyboard.c:1294
#15 0x000790e8 in recursive_edit_1 () at keyboard.c:987
#16 0x00079280 in Frecursive_edit () at keyboard.c:1048
#17 0x00077d80 in main (argc=0, argv=0xbffffdc4) at emacs.c:1763
(gdb)

I have now triggered it using both Emacs/Carbon and Emacs/X11 (both 
running under Mac OS X).

/m

Re: Emacs carbon crash, and beginner question...

[Martin Fredriksson]

[-- Attachment #1: Type: text/plain, Size: 2071 bytes --]

Hi again Kim,

Don't know if my gdb output was useful or if you already found the 
problem, but here is some more info.

I can now reproduce the crash.  Perhaps not the simplest way, but 
following does it.

(1) Start emacs without any init file and with set geometry (to make 
sure my example works)

     emacs -q -geometry 80x40+0+0

(2) Open text file (I enclose an example "apa.txt") marked up for 
outline and with more lines than fit in one window (scrolling is needed 
to trigger the crash).

(3) Go to end of buffer (so that text scrolls)

(4) Press C-o C-t ('hide-body').  Buffer is still "scrolled" (you don't 
see the top of the buffer).

(5) Move up two rows ('previous-line' x 2).  This scrolls down so all 
text is visible.

(6) Press C-o C-a ('show-all')

     CRASH.

Configuration information below.  This run is from Emacs/X11, same 
result for Emacs/Carbon.

In GNU Emacs 22.0.50.2 (powerpc-apple-darwin7.8.0, X toolkit, Xaw3d 
scroll bars)
  of 2005-02-11 on seven.msp.se
Distributor `The XFree86 Project, Inc', version 11.0.40300000
configured using `configure '--without-carbon' '--with-x' 
'CPPFLAGS=-I/opt/local/include' 'LDFLAGS=-L/opt/local/lib''

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: nil
   locale-coding-system: nil
   default-enable-multibyte-characters: t

Major mode: Text

Minor modes in effect:
   outline-minor-mode: t
   mouse-wheel-mode: t
   menu-bar-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   unify-8859-on-encoding-mode: t
   utf-translate-cjk-mode: t
   line-number-mode: t
   transient-mark-mode: t

Recent input:
C-x C-f a p a . t x t <return> <escape> > C-o C-t <up>
<up>

Recent messages:
Loading tooltip...done
Loading font-lock...done
Loading jit-lock...done
Loading outline...
Loading easy-mmode...done
Loading outline...done
Loading vc-cvs...done
Mark set
Making completion list...
Loading emacsbug...done


[-- Attachment #2: apa.txt --]
[-- Type: text/plain, Size: 237 bytes --]

* Section 1
Line 1
Line 2
* Section 2
Line a
Line b
asdfadf
asdf
asdf
asdf
asdf
asdf
asd
fa
sdfa
sdf
asdf
asdf
asd
fas
dfa
sdfasdf
asdf
asdf
as
dfa
sdf
*Section 3
asdfadsf
asdf
asdfasdf
asdf
asdf
asd
fasdf
asdf
asfd
asdf
asd
fasdf
aadsf

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Emacs carbon crash, and beginner question...

[Kim F. Storm]

Martin Fredriksson <m@rfc.se> writes:

> Hi again Kim,
>
> Don't know if my gdb output was useful or if you already found the
> problem, but here is some more info.
>
> I can now reproduce the crash.  Perhaps not the simplest way, but
> following does it.

Unfortunately, I cannot reproduce the crash following your procedure.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Emacs carbon crash, and beginner question...

[chad brown]

At the moment, I do not have time to debug the issue, but as of a few 
days ago, the following will crash emacs:

  (set-default-font 
"-apple-tahoma-medium-r-normal--0-0-75-75-m-0-mac-roman")

GNU Emacs 22.0.50.1 (powerpc-apple-darwin7.8.0) of 2005-02-10 on 
aluminibook.local
built with:  ./configure --enable-carbon-app --without-x --without-xim

It's not just the tahoma font; it appears that any proportional-width 
font will cause the crash.

Thanks,
*chad

Re: Emacs carbon crash, and beginner question...

[YAMAMOTO Mitsuharu]

[-- Attachment #1: Type: text/plain, Size: 764 bytes --]

>>>>> On Sat, 12 Feb 2005 13:15:20 -0500, chad brown <y@MIT.EDU> said:

> At the moment, I do not have time to debug the issue, but as of a
> few days ago, the following will crash emacs:

>   (set-default-font "-apple-tahoma-medium-r-normal--0-0-75-75-m-0-mac-roman")

It crashes at the following xassert in set_lface_from_font_name:

      if (have_xlfd_p)
	pt = xlfd_point_size (f, &font);
      else
	pt = pixel_point_size (f, font_info->height * 10);
      xassert (pt > 0);

In Carbon Emacs, the value of `pt' possibly becomes 0 because the
`full_name' field in `struct font_info' may not be fully instantiated
and it may contain 0 in the XLFD pixel size field.  Please try the
attached patch.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp


[-- Attachment #2: diff-fullname.gz --]
[-- Type: application/octet-stream, Size: 7043 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Emacs carbon crash, and beginner question...

[Martin Fredriksson]

On 12 feb 2005, at 17.04, Kim F. Storm wrote:

> Unfortunately, I cannot reproduce the crash following your procedure.

That's understandable, as my description was flawed. Sorry.  I try 
again.

(1) gdb ./emacs
     (gdb) run -q

(2) Open apa.txt, select outline minor mode (M-x outline-minor-mode) 
and go to end of buffer.

(3) Hide body (must be done using keys):
     C-c @ C-t

(4) Go up two lines (previous-line x 2)

(5) Show all (must be done using keys):
     C-c @ C-a

CRASH

The bt here shows that it stops right at the line calling 
'find_first_unchanged_at_end_of_row'.  I don't understand the #1 entry 
below (unless the function has been inlined?).

Breakpoint 1, 0x9009ead8 in abort ()
(gdb) bt
#0  0x9009ead8 in abort ()
#1  0x0002a6e8 in try_window_id (w=0xbfffd744) at xdisp.c:13559
#2  0x0002a6e8 in try_window_id (w=0x1608020) at xdisp.c:13559
#3  0x000276a4 in redisplay_window (window=23101476, just_this_one_p=1) 
at xdisp.c:12104
#4  0x00024dac in redisplay_window_1 (window=244) at xdisp.c:10826
#5  0x0010b638 in internal_condition_case_1 (bfun=0x24d70 
<redisplay_window_1>, arg=23101476, handlers=6341941, hfun=0x24ce0 
<redisplay_window_error>) at eval.c:1426
#6  0x0002447c in redisplay_internal (preserve_echo_area=244) at 
xdisp.c:10448
#7  0x000a53a8 in read_char (commandflag=1, nmaps=3, maps=0xbfffed10, 
prev_event=58721281, used_mouse_menu=0xbfffee04) at keyboard.c:2540
#8  0x000ae1c4 in read_key_sequence (keybuf=0xc24bc195, 
bufsize=-2021289069, prompt=-1035222635, 
dont_downcase_last=-2021289069, can_return_switch_frame=1069026791, 
fix_current_buffer=382730240) at keyboard.c:8799
#9  0x000a302c in command_loop_1 () at keyboard.c:1534
#10 0x0010b4cc in internal_condition_case (bfun=0xa2b4c 
<command_loop_1>, handlers=58766425, hfun=0xa243c <cmd_error>) at 
eval.c:1385
#11 0x000a28b0 in command_loop_2 () at keyboard.c:1315
#12 0x0010af28 in internal_catch (tag=244, func=0xa2870 
<command_loop_2>, arg=58721281) at eval.c:1144
#13 0x000a2808 in command_loop () at keyboard.c:1294
#14 0x000a2094 in recursive_edit_1 () at keyboard.c:987
#15 0x000a2244 in Frecursive_edit () at keyboard.c:1048
#16 0x000a0cf4 in main (argc=0, argv=0xbffffc20) at emacs.c:1763
(gdb)

(gdb) p *w
$7 = {
   size = 0,
   vec_next = 0x40020000,
   frame = 1073741824,
   mini_p = 1,
   next = 2699160,
   prev = 2649508,
   hchild = 23079888,
   vchild = 0,
   parent = 23106800,
   left_col = 0,
   top_line = 2649508,
   total_lines = 0,
   total_cols = 23101476,
   buffer = 2649508,
   start = 2649508,
   pointm = 2699160,
   force_start = 2688260,
   optional_new_start = 23101472,
   hscroll = 159140,
   min_hscroll = -1073751360,
   use_time = 1145185314,
   sequence_number = 161444,
   temslot = 1375660,
   last_modified = -1073752080,
   last_overlay_modified = 2,
   last_point = 1375756,
   last_had_star = 0,
   vertical_scroll_bar = 1,
   left_margin_cols = 58721281,
   right_margin_cols = 2677332,
   left_fringe_width = 8,
   right_fringe_width = -1073751984,
   fringes_outside_margins = 2699160,
   scroll_bar_width = 58721281,
   vertical_scroll_bar_type = 1366612,
   last_mark_x = 27,
   last_mark_y = 27,
   window_end_pos = 1366812,
   window_end_vpos = 101,
   window_end_valid = 27,
   update_mode_line = 27,
   start_at_line_beg = -1073751824,
   display_table = 1375964,
   dedicated = 1,
   base_line_number = 1,
   base_line_pos = 1375908,
   region_showing = 0,
   column_number_displayed = 2700588,
   redisplay_end_trigger = 2,
   too_small_ok = 1,
   orig_total_lines = 0,
   orig_top_line = 2700588,
   current_matrix = 0x292f98,
   desired_matrix = 0x0,
   nrows_scale_factor = 2700588,
   ncols_scale_factor = 128948,
   last_cursor = {
     x = 1,
     y = 2650188,
     hpos = 2650188,
     vpos = 1
   },
   cursor = {
     x = -1073751184,
     y = 115944,
     hpos = 1539980,
     vpos = 1
   },
   phys_cursor = {
     x = 1,
     y = -1073751808,
     hpos = 98448,
     vpos = -1073751712
   },
   phys_cursor_type = 604144168,
   phys_cursor_width = 99176,
   phys_cursor_ascent = 8,
   phys_cursor_height = -1,
   overlay_arrow_bitmap = 23079332,
   phys_cursor_on_p = 1,
   cursor_off_p = 0,
   last_cursor_off_p = 1,
   must_be_updated_p = 1,
   pseudo_window_p = 1,
   vscroll = 1375964,
   window_end_bytepos = -1073751872,
   frozen_window_start_p = 0,
   height_fixed_p = 1
}
(gdb) p delta
$8 = 0
(gdb) p delta_bytes
$9 = 58721329
(gdb)

Re: Emacs carbon crash, and beginner question...

[Sébastien Kirche]

Le 11 Feb 2005, Martin Fredriksson s'est exprimé ainsi :

> Is there a quick way to read up on how to get Emacs (particularly
> Carbon) to log more, run it in debug mode, or otherwise helpful things
> to get some more info about intermittent crash problems?

Maybe it's a bit late, but for  Carbon Emacs, you can get some infos about a
crash (threads, call stack, etc...) with "Console" app.

Look into /Applications/Utilities/Console, search in the tree view the crash
logs then Emacs.app and it should display the logs. Last log at the bootom.

HTH.

-- 
Sébastien Kirche

Re: Emacs carbon crash, and beginner question...

[Martin Fredriksson]

On 14 feb 2005, at 10.51, Sébastien Kirche wrote:

> Maybe it's a bit late, but for  Carbon Emacs, you can get some infos 
> about a
> crash (threads, call stack, etc...) with "Console" app.

Yes, that's a good tip.  The problem here was that Emacs didn't crash 
in the way that it produced a crash log (no entry in 
~/Library/Logs/CrashReporter/Emacs.crash.log).  Instead, it's Emacs 
which aborts internally.

/m