unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#3605: Crash in ns_index_color (nsterm.m:1305)
@ 2009-07-23 14:46 Adrian Robert
  2009-07-23 14:59 ` David Reitter
  2009-07-23 15:16 ` David Reitter
  0 siblings, 2 replies; 15+ messages in thread
From: Adrian Robert @ 2009-07-23 14:46 UTC (permalink / raw)
  To: 3605; +Cc: Ben Lowery, David Reitter

http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3605

Hi,

If you could please retest this against the latest branch or trunk,  
I've checked in some robustness improvement to the indexed color stuff  
that may clear this up.

thanks.






^ permalink raw reply	[flat|nested] 15+ messages in thread
* bug#3605: Crash in ns_index_color (nsterm.m:1305)
@ 2009-10-20  6:27 Mike
  0 siblings, 0 replies; 15+ messages in thread
From: Mike @ 2009-10-20  6:27 UTC (permalink / raw)
  To: 3605

I'm seeing this crash somewhat frequently in recent builds (GNU Emacs
23.1.50.6 (i386-apple-darwin9.8.0, NS apple-appkit-949.54)
 of 2009-10-19 on Macintosh-8.local)

I poked around a bit and didn't have much luck finding a root cause.

Here's a typical stack trace:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xc0000023
0x942eb688 in objc_msgSend ()
(gdb)
(gdb)
(gdb) bt
#0  0x942eb688 in objc_msgSend ()
#1  0x900b6e1f in -[NSCalibratedRGBColor isEqual:] ()
#2  0x0016c09c in ns_index_color (color=0x175d8830, f=0x175d8830) at
nsterm.m:1249
#3  0x0016cc82 in ns_defined_color (f=0x8e7060, name=0x175d8830
"\003", color_def=0xbfffc4e4, alloc=1, makeIndex=1 '\001') at
nsterm.m:1529
#4  0x000881bc in defined_color (f=0x8e7060, color_name=0x17a16114
"#9b9b9b", color_def=0xbfffc4e4, alloc=1) at xfaces.c:1266
#5  0x000884de in load_color (f=0x8e7060, face=0x175b0bf0,
name=396153139, target_index=LFACE_FOREGROUND_INDEX) at xfaces.c:1439
#6  0x0008e45a in load_face_colors [inlined] () at xfaces.c:1528
#7  0x0008e45a in realize_face (cache=0x16a3310, attrs=0xbfffc69c,
former_face_id=<value temporarily unavailable, due to optimizations>)
at xfaces.c:5913
#8  0x0008f21d in lookup_face (f=0x175d8830, attr=0xbfffc69c) at xfaces.c:4722
#9  0x00090892 in face_at_buffer_position (w=0x8e7200, pos=898,
region_beg=-1, region_end=-1, endptr=0xbfffc76c, limit=998, mouse=0,
base_face_id=0) at xfaces.c:6359
#10 0x0001ad97 in handle_face_prop (it=0xbfffd338) at xdisp.c:3440
#11 0x0001d908 in handle_stop (it=0xbfffd338) at xdisp.c:3127
#12 0x00020d07 in next_element_from_buffer (it=0xbfffd338) at xdisp.c:6511
#13 0x0001ecbf in get_next_display_element (it=0xbfffd338) at xdisp.c:5670
#14 0x000296ac in display_line (it=0xbfffd338) at xdisp.c:16565
#15 0x0002ac76 in try_window (window=9335300, pos={charpos = 331,
bytepos = 331}, check_margins=1) at xdisp.c:14023
#16 0x00032bec in redisplay_window (window=9335300, just_this_one_p=0)
at xdisp.c:13646
#17 0x000347cd in redisplay_window_0 (window=9335300) at xdisp.c:12278
#18 0x001092a3 in internal_condition_case_1 (bfun=0x347a0
<redisplay_window_0>, arg=9335300, handlers=5297461, hfun=0x25570
<redisplay_window_error>) at eval.c:1573
#19 0x00025291 in redisplay_windows (window=<value temporarily
unavailable, due to optimizations>) at xdisp.c:12257
#20 0x00025235 in redisplay_windows (window=<value temporarily
unavailable, due to optimizations>) at xdisp.c:12251
#21 0x00025235 in redisplay_windows (window=<value temporarily
unavailable, due to optimizations>) at xdisp.c:12251
#22 0x00036bcc in redisplay_internal (preserve_echo_area=<value
temporarily unavailable, due to optimizations>) at xdisp.c:11829
#23 0x0009fbf5 in read_char (commandflag=1, nmaps=4, maps=0xbfffeb80,
prev_event=25165833, used_mouse_menu=0xbfffec88, end_time=0x0) at
keyboard.c:2707
#24 0x000a26c4 in read_key_sequence (keybuf=0xbfffed48, bufsize=30,
prompt=25165833, dont_downcase_last=0, can_return_switch_frame=1,
fix_current_buffer=1) at keyboard.c:9461
#25 0x000a4cea in command_loop_1 () at keyboard.c:1640
#26 0x0010963d in internal_condition_case (bfun=0xa4ac0
<command_loop_1>, handlers=25205425, hfun=0x9ad40 <cmd_error>) at
eval.c:1525
#27 0x000948a8 in command_loop_2 () at keyboard.c:1357
#28 0x0010951c in internal_catch (tag=392005680, func=0x94860
<command_loop_2>, arg=25165833) at eval.c:1261
#29 0x000945fe in command_loop () at keyboard.c:1336
#30 0x000946c2 in recursive_edit_1 () at keyboard.c:951
#31 0x00094841 in Frecursive_edit () at keyboard.c:1013
#32 0x0009337a in main (argc=1, argv=0xbffff1ec) at emacs.c:1827

(gdb) bt full
#0  0x942eb688 in objc_msgSend ()
No symbol table info available.
#1  0x900b6e1f in -[NSCalibratedRGBColor isEqual:] ()
No symbol table info available.
#2  0x0016c09c in ns_index_color (color=0x175d8830, f=0x175d8830) at
nsterm.m:1249
    i = 392005680
    color_table = (struct ns_color_table *) 0x838b80
    idx = <value temporarily unavailable, due to optimizations>
#3  0x0016cc82 in ns_defined_color (f=0x8e7060, name=0x175d8830
"\003", color_def=0xbfffc4e4, alloc=1, makeIndex=1 '\001') at
nsterm.m:1529
    temp = (NSColor *) 0x175d8830
    notFound = <value temporarily unavailable, due to optimizations>
#4  0x000881bc in defined_color (f=0x8e7060, color_name=0x17a16114
"#9b9b9b", color_def=0xbfffc4e4, alloc=1) at xfaces.c:1266
No locals.
#5  0x000884de in load_color (f=0x8e7060, face=0x175b0bf0,
name=396153139, target_index=LFACE_FOREGROUND_INDEX) at xfaces.c:1439
    color = {
  pixel = 1,
  red = 65535,
  green = 65535,
  blue = 65535,
  flags = -114 '?',
  pad = 0 '\0'
}
#6  0x0008e45a in load_face_colors [inlined] () at xfaces.c:1528
    attrs = (Lisp_Object *) Cannot access memory at address 0x0
(gdb)





^ permalink raw reply	[flat|nested] 15+ messages in thread
* bug#3605: Crash in ns_index_color (nsterm.m:1305)
@ 2009-10-22  0:05 Mike
  0 siblings, 0 replies; 15+ messages in thread
From: Mike @ 2009-10-22  0:05 UTC (permalink / raw)
  To: 3605

I spent some more time looking at this, and I think I've found the problem:

ns_defined_color needs to block input around its calls to ns_get_color
and (at least) ns_index_color.  ns_get_color calls UNBLOCK_INPUT after
allocating an autorelease NSColor.  Because the outer autorelease pool
is flushed every time through the event loop, sometimes the color gets
freed before ns_index_color has a chance to retain it.

As a reliable test case, try loading the color palette from
http://www.emacswiki.org/cgi-bin/wiki/palette.el





^ permalink raw reply	[flat|nested] 15+ messages in thread
end of thread, other threads:[~2010-01-31  5:24 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <9ee8c1eb0906180743s4cfa6986ic78af206a15e2ce6@mail.gmail.com>
2009-06-18 14:58 ` bug#3605: Crash in ns_index_color (nsterm.m:1305) David Reitter
2009-06-18 15:04   ` bug#3606: " Ben Lowery
2009-09-22 22:54     ` bug#4530: " Adrian Robert
2009-09-23  1:58       ` bug#4532: " Ben Lowery
2009-09-23  4:35         ` Glenn Morris
2009-09-23  4:40           ` Processed: " Emacs bug Tracking System
2009-06-18 18:08   ` bug#3605: " Glenn Morris
2010-01-31  5:24   ` Chong Yidong
2009-07-23 14:46 Adrian Robert
2009-07-23 14:59 ` David Reitter
2009-07-29 14:39   ` Ben Lowery
2009-07-23 15:16 ` David Reitter
2009-07-23 15:36   ` Adrian Robert
  -- strict thread matches above, loose matches on Subject: below --
2009-10-20  6:27 Mike
2009-10-22  0:05 Mike

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).