* bug#4879: Crash in xmenu_show
@ 2009-11-06 10:49 Juri Linkov
2009-11-06 11:50 ` Eli Zaretskii
0 siblings, 1 reply; 14+ messages in thread
From: Juri Linkov @ 2009-11-06 10:49 UTC (permalink / raw)
To: bug-gnu-emacs
In a non-toolkit X build GNU Emacs 23.1.50 (x86_64-pc-linux-gnu)
steps to reproduce the crash:
1. emacs -Q
2. Type `C-x C-f'
3. Click on the `Minibuf' top-level menu.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f146c4497a0 (LWP 31459)]
0x000000000047028f in xmenu_show (f=0x11abbb0, x=383, y=10, for_click=1,
keymaps=1, title=10721059, error=0x7fff74478630) at xmenu.c:2738
2738 bcopy (SDATA (item_name), item_data,
I've tracked and narrowed the cause of this crash to a change
between 2009-09-10 and 2009-09-11.
--
Juri Linkov
http://www.jurta.org/emacs/
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#4879: Crash in xmenu_show
2009-11-06 10:49 bug#4879: Crash in xmenu_show Juri Linkov
@ 2009-11-06 11:50 ` Eli Zaretskii
2009-11-06 15:11 ` Jan Djärv
2009-11-06 21:10 ` Juri Linkov
0 siblings, 2 replies; 14+ messages in thread
From: Eli Zaretskii @ 2009-11-06 11:50 UTC (permalink / raw)
To: Juri Linkov, 4879
> From: Juri Linkov <juri@jurta.org>
> Date: Fri, 06 Nov 2009 12:49:21 +0200
> Cc:
>
> In a non-toolkit X build GNU Emacs 23.1.50 (x86_64-pc-linux-gnu)
What does it mean, exactly? Why didn't you send the report using "M-x
report-emacs-bug RET", where all this information is automatically
included?
FWIW, I cannot reproduce this neither in the MS-DOS build (which
should generally work like a non-toolkit build on Unix), nor in the
MS-Windows build, both from today's CVS.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#4879: Crash in xmenu_show
2009-11-06 11:50 ` Eli Zaretskii
@ 2009-11-06 15:11 ` Jan Djärv
2009-11-06 21:06 ` Juri Linkov
2009-11-06 21:10 ` Juri Linkov
1 sibling, 1 reply; 14+ messages in thread
From: Jan Djärv @ 2009-11-06 15:11 UTC (permalink / raw)
To: Eli Zaretskii, 4879
Eli Zaretskii skrev:
>> From: Juri Linkov <juri@jurta.org>
>> Date: Fri, 06 Nov 2009 12:49:21 +0200
>> Cc:
>>
>> In a non-toolkit X build GNU Emacs 23.1.50 (x86_64-pc-linux-gnu)
>
> What does it mean, exactly? Why didn't you send the report using "M-x
> report-emacs-bug RET", where all this information is automatically
> included?
>
> FWIW, I cannot reproduce this neither in the MS-DOS build (which
> should generally work like a non-toolkit build on Unix), nor in the
> MS-Windows build, both from today's CVS.
>
>
I can't reproduce it either, on x86_64-pc-linux-gnu, --with-x-toolkit=no
Jan D.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#4879: Crash in xmenu_show
2009-11-06 15:11 ` Jan Djärv
@ 2009-11-06 21:06 ` Juri Linkov
0 siblings, 0 replies; 14+ messages in thread
From: Juri Linkov @ 2009-11-06 21:06 UTC (permalink / raw)
To: Jan Djärv; +Cc: 4879
> I can't reproduce it either, on x86_64-pc-linux-gnu, --with-x-toolkit=no
Sorry, I thought it will be easy to reproduce, but since it's not,
I include maximum information below.
1. Test case 1
1.1. mkdir cvs20090910
1.2. cd cvs20090910
1.3. cvs -z3 -d:pserver:anonymous@cvs.sv.gnu.org:/sources/emacs co -D 2009-09-10 emacs
1.4. cd emacs
1.5. ./configure --with-x-toolkit=no CFLAGS="-g3 -O0 -Wno-pointer-sign -fno-inline -fno-crossjumping"
1.6. make -j3 bootstrap
1.7. cd src
1.8. ./emacs -Q
1.9. Type `C-x C-f'
1.10. Click on the top-level menu "Minibuf"
1.11. No crash
2. Test case 2
2.1. mkdir cvs20090911
2.2. cd cvs20090911
2.3. cvs -z3 -d:pserver:anonymous@cvs.sv.gnu.org:/sources/emacs co -D 2009-09-11 emacs
2.4. cd emacs
2.5. ./configure --with-x-toolkit=no CFLAGS="-g3 -O0 -Wno-pointer-sign -fno-inline -fno-crossjumping"
2.6. make -j3 bootstrap
2.7. cd src
2.8. ./emacs -Q
2.9. Type `C-x C-f'
2.10. Click on the top-level menu "Minibuf"
2.11. Crash with the backtrace below
In GNU Emacs 23.1.50.1 (x86_64-unknown-linux-gnu) of 2009-09-11 (CVS date)
Windowing system distributor `The X.Org Foundation', version 11.0.10400090
configured using `configure '--with-x-toolkit=no' 'CFLAGS=-g3 -O0 -Wno-pointer-sign -fno-inline -fno-crossjumping''
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: en_DK.utf8
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: @im=SCIM
locale-coding-system: utf-8-unix
default enable-multibyte-characters: t
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
tool-bar-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
global-auto-composition-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 <tab> <return>
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Load-path shadows:
None found.
Configured for `x86_64-unknown-linux-gnu'.
What operating system and machine description files should Emacs use?
`s/gnu-linux.h' and `m/amdx86-64.h'
What compiler should emacs be built with? gcc -g3 -O0 -Wno-pointer-sign -fno-inline -fno-crossjumping
Should Emacs use the GNU version of malloc? yes
(Using Doug Lea's new malloc from the GNU C Library.)
Should Emacs use a relocating allocator for buffers? yes
Should Emacs use mmap(2) for buffer allocation? no
What window system should Emacs use? x11
What toolkit should Emacs use? none
Where do we find X Windows header files? Standard dirs
Where do we find X Windows libraries? Standard dirs
Does Emacs use -lXaw3d? no
Does Emacs use -lXpm? yes
Does Emacs use -ljpeg? yes
Does Emacs use -ltiff? yes
Does Emacs use a gif library? yes -lgif
Does Emacs use -lpng? yes
Does Emacs use -lrsvg-2? yes
Does Emacs use -lgpm? yes
Does Emacs use -ldbus? yes
Does Emacs use -lfreetype? yes
Does Emacs use -lm17n-flt? no
Does Emacs use -lotf? no
Does Emacs use -lxft? yes
Does Emacs use toolkit scroll bars? no
If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
`bt full' and `xbacktrace'.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fb3746be7a0 (LWP 19530)]
0x00000000004701c7 in xmenu_show (f=0x11c46e0, x=227, y=29, for_click=1, keymaps=1, title=12708355, error=0x7fff7c6ed8c0) at xmenu.c:2735
2735 bcopy (SDATA (item_name), item_data,
(gdb) bt full
#0 0x00000000004701c7 in xmenu_show (f=0x11c46e0, x=227, y=29, for_click=1, keymaps=1, title=12708355, error=0x7fff7c6ed8c0) at xmenu.c:2735
gap = 19
item_name = 12452995
help_string = 0x1074da0 "Terminate input and exit minibuffer"
enable = 11890497
descrip = 13638049
help = 12458691
item_data = (unsigned char *) 0x7fff7bda3920 <Address 0x7fff7bda3920 out of bounds>
root = 315
menu = (XMenu *) 0x12879b0
pane = 0
selidx = 17331797
lpane = 0
status = 2087639072
entry = 141733920778
pane_prefix = 11890401
datap = 0xb56ee1 ""
ulx = 1
uly = 0
width = 4
height = 2087639040
dispwidth = 0
dispheight = 4645596
i = 59
j = 24
lines = 7
maxlines = 0
maxwidth = 24
dummy_int = 0
dummy_uint = 24
specpdl_count = 33
#1 0x000000000046f2fa in Fx_popup_menu (position=17488549, menu=17488613) at xmenu.c:505
keymap = 17331781
tem = 11890401
xpos = 223
ypos = 4
title = 12708355
error_name = 0x0
selection = 11890401
f = (FRAME_PTR) 0x11c46e0
x = 1784
y = 32
window = 18630372
keymaps = 1
for_click = 1
specpdl_count = 33
gcpro1 = {
next = 0x100000001,
var = 0x800000006,
nvars = 2
}
#2 0x000000000054f57e in read_char_x_menu_prompt (nmaps=2, maps=0x7fff7c6edd90, prev_event=17488549, used_mouse_menu=0x7fff7c6ee1d8) at keyboard.c:8613
realmaps = (Lisp_Object *) 0x7fff7c6ed930
value = 140408669737242
nmaps1 = 1
mapno = 2
name = 12708355
#3 0x00000000005444e6 in read_char (commandflag=1, nmaps=2, maps=0x7fff7c6edd90, prev_event=17488549, used_mouse_menu=0x7fff7c6ee1d8, end_time=0x0) at keyboard.c:2912
c = 11890401
count = 0
jmpcount = 33
local_getcjmp = {{
__jmpbuf = {11890401, 4079779853910592874, 0, 140735281040048, 0, 0, 4079779853793152362, -4080065152552612502},
__mask_was_saved = 0,
__saved_mask = {
__val = {11890401, 0, 17331909, 140735281028000, 5549673, 11890401, 16403009, 17332117, 17332021, 140735281028256, 5608643, 16403009, 11890401, 4311370305,
4294967296, 16403009}
}
}}
save_jump = {{
__jmpbuf = {0, 11890401, 140735281027744, 5607104, 0, 17332117, 16403009, 17332085},
__mask_was_saved = 0,
__saved_mask = {
__val = {16403009, 11890401, 11890401, 140735281028000, 5608401, 16403009, 17332117, 0, 11890401, 11951393, 17331989, 17331957, 11890401, 140735281027856,
6236616, 11951393}
}
}}
key_already_recorded = 0
tem = 140735281028432
save = 5572172
previous_echo_area_message = 11890401
also_record = 11890401
reread = 0
gcpro1 = {
next = 0xfa4a41,
var = 0x1087625,
nvars = 13463754
}
gcpro2 = {
next = 0xfa4a41,
var = 0x1087645,
nvars = 11890401
}
polling_stopped_here = 0
orig_kboard = (struct kboard *) 0xe70660
#4 0x0000000000551030 in read_key_sequence (keybuf=0x7fff7c6ee380, bufsize=30, prompt=11890401, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1)
at keyboard.c:9464
interrupted_kboard = (KBOARD *) 0xe70660
interrupted_frame = (struct frame *) 0x11c46e0
key = 17488549
used_mouse_menu = 0
echo_local_start = 0
last_real_key_start = 2
keys_local_start = 2
local_first_binding = 0
from_string = 11890401
count = 33
t = 2
echo_start = 0
keys_start = 0
nmaps = 2
nmaps_allocated = 2
defs = (Lisp_Object * volatile) 0x7fff7c6edd70
submaps = (Lisp_Object * volatile) 0x7fff7c6edd90
orig_local_map = 11883477
orig_keymap = 11890401
localized_local_map = 0
first_binding = 0
first_unbound = 31
mock_input = 0
fkey = {
parent = 16696629,
map = 16696629,
start = 2,
end = 2
}
keytran = {
parent = 11882261,
map = 11882261,
start = 2,
end = 2
}
indec = {
parent = 16696661,
map = 16696661,
start = 2,
end = 2
}
shift_translated = 0
delayed_switch_frame = 11890401
original_uppercase = 12110258
original_uppercase_position = -1
dummyflag = 0
starting_buffer = (struct buffer *) 0x1256f20
fake_prefixed_keys = 11890401
gcpro1 = {
next = 0x7fff7c6ee090,
var = 0x5e8fe5,
nvars = 12112401
}
#5 0x0000000000540d6b in command_loop_1 () at keyboard.c:1640
cmd = 6198825
lose = 0
keybuf = {11944033, 17488549, 140735281029856, 4294967299, 39, 140735281029856, 140733193388035, 6703026, 167503724555, 12455656, 140735281030144, 6666026,
12455656, 12455656, 19230500, 4307422952, 140735281029856, 11890401, 24, 11890401, 11890401, 137452549393, 16841589, 11890449, 0, 16841589, 11890401, 11890401,
19251018, 17625633}
i = 9967300
prev_modiff = 0
prev_buffer = (struct buffer *) 0x0
already_adjusted = 0
#6 0x00000000005e5f96 in internal_condition_case (bfun=0x5409d8 <command_loop_1>, handlers=11977489, hfun=0x540309 <cmd_error>) at eval.c:1513
val = 6200100
c = {
tag = 11890401,
val = 11890401,
next = 0x7fff7c6ee680,
gcpro = 0x0,
jmp = {{
__jmpbuf = {11890401, 4079779853136743786, 0, 140735281040048, 0, 0, 4079779853090606442, -4080065238502552214},
__mask_was_saved = 0,
__saved_mask = {
__val = {0, 8601824993, 11890401, 17464005, 11977297, 13595969, 9967300, 12455656, 7400927115773751296, 12195578, 11890401, 140735281030784, 6194157, 408,
11890401, 11890401}
}
}},
backlist = 0x7fff7c6eeb30,
handlerlist = 0x7fff7c6f0430,
lisp_eval_depth = 5,
pdlcount = 33,
poll_suppress_count = 1,
interrupt_input_blocked = 0,
byte_stack = 0x7fff7c6eecf0
}
h = {
handler = 11977489,
var = 11890401,
chosen_clause = 0,
tag = 0x7fff7c6ee500,
next = 0x7fff7c6f0430
}
#7 0x00000000005406f7 in command_loop_2 () at keyboard.c:1357
val = 5
#8 0x00000000005e5972 in internal_catch (tag=12111553, func=0x5406dd <command_loop_2>, arg=11890401) at eval.c:1249
c = {
tag = 12111553,
val = 11890401,
next = 0x7fff7c6f0320,
gcpro = 0x0,
jmp = {{
__jmpbuf = {11890401, 4079779853197561194, 0, 140735281040048, 0, 0, 4079779853140938090, -4080065238711349910},
__mask_was_saved = 0,
__saved_mask = {
__val = {11890401, 140735281031024, 6081208, 140735281031104, 11890401, 12312177, 11890401, 10677577672, 12295274, 12295274, 12295274, 140735281031024,
6079639, 4307079697, 19230496, 12295274}
}
}},
backlist = 0x7fff7c6eeb30,
handlerlist = 0x7fff7c6f0430,
lisp_eval_depth = 5,
pdlcount = 33,
poll_suppress_count = 1,
interrupt_input_blocked = 0,
byte_stack = 0x7fff7c6eecf0
}
#9 0x0000000000540665 in command_loop () at keyboard.c:1322
val = 11890401
#10 0x000000000053fe4f in recursive_edit_1 () at keyboard.c:951
count = 32
val = 12196513
#11 0x000000000057e116 in read_minibuf (map=11883477, initial=12703987, prompt=9576827, backup_n=0, expflag=0, histvar=11993441, histpos=0, defalt=12779427,
allow_props=0, inherit_input_method=0) at minibuf.c:739
val = 11890401
count = 25
mini_frame = 18630372
ambient_dir = 12779427
minibuffer = 19230500
input_method = 11890401
gcpro1 = {
next = 0x7fff7c6ee950,
var = 0x5ccab8,
nvars = 0
}
gcpro2 = {
next = 0xb43670,
var = 0x0,
nvars = 19022128
}
gcpro3 = {
next = 0x10000ffffffff,
var = 0x1,
nvars = 2087643376
}
gcpro4 = {
next = 0xba2dda,
var = 0x27,
nvars = 11930576
}
gcpro5 = {
next = 0x7fff7c6f0ab0,
var = 0x0,
nvars = 19022128
}
enable_multibyte = 11890401
pos = 0
histstring = 12198865
empty_minibuf = 12088996
dummy = 11890401
frame = 18630372
#12 0x00000000005804b5 in Fcompleting_read (prompt=9576827, collection=12198721, predicate=11890401, require_match=13184625, initial_input=12703987, hist=11993441,
def=12779427, inherit_input_method=11890401) at minibuf.c:1823
val = 2
histvar = 11993441
histpos = 0
position = 11890401
init = 12703987
pos = 0
count = 22
gcpro1 = {
next = 0x10a7ac5,
var = 0xc040e1,
nvars = 17464005
}
#13 0x00000000005e8f90 in Ffuncall (nargs=8, args=0x7fff7c6eebb0) at eval.c:3077
fun = 9261604
original_fun = 12203345
funcar = 2
numargs = 7
lisp_numargs = 11977297
val = 17464005
backtrace = {
next = 0x7fff7c6ef080,
function = 0x7fff7c6eebb0,
args = 0x7fff7c6eebb8,
nargs = 7,
evalargs = 0 '\0',
debug_on_exit = 0 '\0'
}
internal_args = (Lisp_Object *) 0x7fff7c6eeab0
i = 8
#14 0x000000000063cbff in Fbyte_code (bytestr=9748715, vector=9748748, maxdepth=72) at bytecode.c:678
count = 14
op = 7
vectorp = (Lisp_Object *) 0x94c118
bytestr_length = 416
stack = {
pc = 0xab4d40 "+\202\377",
top = 0x7fff7c6eebe8,
bottom = 0x7fff7c6eebb0,
byte_string = 9748715,
byte_string_start = 0xab4c8a "\b\204\006",
constants = 9748748,
next = 0x7fff7c6ef220
}
top = (Lisp_Object *) 0x7fff7c6eebb0
result = 12569873
#15 0x00000000005e9619 in funcall_lambda (fun=9748548, nargs=4, arg_vector=0x7fff7c6ef108) at eval.c:3233
val = 17463573
syms_left = 11890401
next = 12569873
count = 8
i = 4
optional = 1
rest = 0
#16 0x00000000005e8fe5 in Ffuncall (nargs=5, args=0x7fff7c6ef100) at eval.c:3092
fun = 9748548
original_fun = 12751457
funcar = 12141633
numargs = 4
lisp_numargs = 12140650
val = 12140650
backtrace = {
next = 0x7fff7c6ef5b0,
function = 0x7fff7c6ef100,
args = 0x7fff7c6ef108,
nargs = 4,
evalargs = 0 '\0',
debug_on_exit = 0 '\0'
}
internal_args = (Lisp_Object *) 0x0
i = 0
#17 0x000000000063cbff in Fbyte_code (bytestr=9576115, vector=9576148, maxdepth=40) at bytecode.c:678
count = 5
op = 4
vectorp = (Lisp_Object *) 0x921ee0
bytestr_length = 29
stack = {
pc = 0xac0d8a "+\315D\207",
top = 0x7fff7c6ef120,
bottom = 0x7fff7c6ef100,
byte_string = 9576115,
byte_string_start = 0xac0d71 "\b\205\a",
constants = 9576148,
next = 0x7fff7c6ef740
}
top = (Lisp_Object *) 0x7fff7c6ef100
result = 12791377
#18 0x00000000005e9619 in funcall_lambda (fun=9576036, nargs=2, arg_vector=0x7fff7c6ef638) at eval.c:3233
val = 13184625
syms_left = 11890401
next = 12791377
count = 3
i = 2
optional = 0
rest = 0
#19 0x00000000005e8fe5 in Ffuncall (nargs=3, args=0x7fff7c6ef630) at eval.c:3092
fun = 9576036
original_fun = 12789473
funcar = 429675
numargs = 2
lisp_numargs = 0
val = 13184625
backtrace = {
next = 0x7fff7c6efab0,
function = 0x7fff7c6ef630,
args = 0x7fff7c6ef638,
nargs = 2,
evalargs = 0 '\0',
debug_on_exit = 0 '\0'
}
internal_args = (Lisp_Object *) 0xb8d211
i = 0
#20 0x000000000063cbff in Fbyte_code (bytestr=9576739, vector=9576788, maxdepth=24) at bytecode.c:678
count = 3
op = 2
vectorp = (Lisp_Object *) 0x922160
bytestr_length = 6
stack = {
pc = 0xac0d38 "\207",
top = 0x7fff7c6ef640,
bottom = 0x7fff7c6ef630,
byte_string = 9576739,
byte_string_start = 0xac0d33 "\300\301\302 \"\207",
constants = 9576788,
next = 0x0
}
top = (Lisp_Object *) 0x7fff7c6ef630
result = 48
#21 0x00000000005e7a7d in Feval (form=9576709) at eval.c:2383
numargs = 24
args_left = 11890401
i = 3
maxargs = 3
argvals = {9576739, 9576788, 24, 140408729115968, 140408729141248, 4222941, 140408669220824, 4210752}
fun = 11418084
val = 11890401
original_fun = 12151281
original_args = 9576725
funcar = 12151761
backtrace = {
next = 0x7fff7c6efed0,
function = 0x7fff7c6efb60,
args = 0x7fff7c6efa70,
nargs = 3,
evalargs = 1 '\001',
debug_on_exit = 0 '\0'
}
gcpro1 = {
next = 0x7fff7c6efb90,
var = 0x5cba25,
nvars = 1
}
gcpro2 = {
next = 0x7fff7c6efb10,
var = 0x5c44f6,
nvars = 9576709
}
gcpro3 = {
next = 0x10a7905,
var = 0x7fff7c6efa70,
nvars = 3
}
#22 0x00000000005e1bc6 in Fcall_interactively (function=12751553, record_flag=11890401, keys=11957412) at callint.c:364
input = 9576709
args = (Lisp_Object *) 0x0
visargs = (Lisp_Object *) 0x0
specs = 9576709
filter_specs = 9576709
teml = 0
up_event = 11890401
enable = 11890401
speccount = 3
next_event = 5549556
prefix_arg = 11890401
string = (unsigned char *) 0x0
tem = (unsigned char *) 0x0
varies = (int *) 0x0
i = 2
j = 0
count = 0
foo = 8192
prompt1 = "AF\266\000\000\000\000\000\371\252T\000\000\000\000\000AF\266\000\000\000\000\000\340\t\017q\263\177\000\000@", '\0' <repeats 15 times>, "\260\no|\377\177\000\000\333\346\177|\377\177\000\000\000\000\000\000\000\000\000\000\270\242\022\001", '\0' <repeats 12 times>, "\214\347\177|\377\177\000\000\000\000\000"
tem1 = 0x0
arg_from_tty = 0
gcpro1 = {
next = 0x0,
var = 0x7fb3746f1000,
nvars = 455
}
gcpro2 = {
next = 0x0,
var = 0x7fff7c6efd00,
nvars = 0
}
gcpro3 = {
next = 0x7fff7c6efd40,
var = 0x7fb3744e8e32,
nvars = 999992
}
gcpro4 = {
next = 0x40,
var = 0x5e83ed,
nvars = 1893315608
}
gcpro5 = {
next = 0x0,
var = 0x7fb3744e2c76,
nvars = 1
}
key_count = 2
record_then_fail = 0
save_this_command = 12751553
save_last_command = 11890401
save_this_original_command = 12751553
save_real_this_command = 12751553
#23 0x00000000005e8d3b in Ffuncall (nargs=4, args=0x7fff7c6eff70) at eval.c:3052
fun = 11405580
original_fun = 12151665
funcar = 0
numargs = 3
lisp_numargs = 0
val = 0
backtrace = {
next = 0x0,
function = 0x7fff7c6eff70,
args = 0x7fff7c6eff78,
nargs = 3,
evalargs = 0 '\0',
debug_on_exit = 0 '\0'
}
internal_args = (Lisp_Object *) 0x7fff7c6eff78
i = 0
#24 0x00000000005e8714 in call3 (fn=12151665, arg1=12751553, arg2=11890401, arg3=11890401) at eval.c:2872
ret_ungc_val = 9576492
gcpro1 = {
next = 0x92202c,
var = 0xb56ee1,
nvars = 4
}
args = {12151665, 12751553, 11890401, 11890401}
#25 0x0000000000553e2b in Fcommand_execute (cmd=12751553, record_flag=11890401, keys=11890401, special=11890401) at keyboard.c:10453
final = 9576492
tem = 11890401
prefixarg = 11890401
#26 0x000000000054267e in command_loop_1 () at keyboard.c:1901
scount = 2
cmd = 12751553
lose = 0
keybuf = {192, 48, 24, 13158437, 2822930839, 140408727136892, 4327615, 140408669165772, 140735281038216, 100677544720, 44108294, 140735281037840, 0,
140735281038000, 140735281037488, 0, 140408729141248, 4223151, 140408669220824, 4210512, 4294967296, 4294968226, 276967387, 140408729310040, 140735281038304,
140735281038224, 2822930839, 140735281038248, 140408729115968, 140408727137423}
i = 2
prev_modiff = 10
prev_buffer = (struct buffer *) 0xb60bd0
already_adjusted = 0
#27 0x00000000005e5f96 in internal_condition_case (bfun=0x5409d8 <command_loop_1>, handlers=11977489, hfun=0x540309 <cmd_error>) at eval.c:1513
val = 12478693
c = {
tag = 11890401,
val = 11890401,
next = 0x7fff7c6f04a0,
gcpro = 0x0,
jmp = {{
__jmpbuf = {140408729316352, 4079779860590021994, 0, 140735281040048, 0, 0, 4079779860560661866, -4080065238502552214},
__mask_was_saved = 0,
__saved_mask = {
__val = {0, 140408669192768, 140408729141248, 0, 4294967295, 0, 9220952, 0, 140735281040048, 0, 0, 0, 140408727153782, 140733193388033, 0, 4312547443}
}
}},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0,
pdlcount = 2,
poll_suppress_count = 1,
interrupt_input_blocked = 0,
byte_stack = 0x0
}
h = {
handler = 11977489,
var = 11890401,
chosen_clause = 12673136,
tag = 0x7fff7c6f0320,
next = 0x0
}
#28 0x00000000005406f7 in command_loop_2 () at keyboard.c:1357
val = 5
#29 0x00000000005e5972 in internal_catch (tag=11958881, func=0x5406dd <command_loop_2>, arg=11890401) at eval.c:1249
c = {
tag = 11958881,
val = 11890401,
next = 0x0,
gcpro = 0x0,
jmp = {{
__jmpbuf = {140408729316352, 4079779860650839402, 0, 140735281040048, 0, 0, 4079779860610993514, -4080065238711349910},
__mask_was_saved = 0,
__saved_mask = {
__val = {18, 140735281038736, 6081208, 140735281038704, 11890401, 12312177, 11890401, 8589934936, 12295274, 12295274, 12295274, 140735281038736, 6079639,
4307055736, 11930576, 12295274}
}
}},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0,
pdlcount = 2,
poll_suppress_count = 1,
interrupt_input_blocked = 0,
byte_stack = 0x0
}
#30 0x00000000005406b1 in command_loop () at keyboard.c:1336
No locals.
#31 0x000000000053fe4f in recursive_edit_1 () at keyboard.c:951
count = 1
val = 11890401
#32 0x000000000053fff2 in Frecursive_edit () at keyboard.c:1013
count = 0
buffer = 11890401
#33 0x000000000053e465 in main (argc=2, argv=0x7fff7c6f0ab8) at emacs.c:1849
dummy = 4240569
stack_bottom_variable = 0 '\0'
do_initial_setlocale = 1
skip_args = 0
rlim = {
rlim_cur = 8720000,
rlim_max = 18446744073709551615
}
no_loadup = 0
junk = 0x0
dname_arg = 0x0
Lisp Backtrace:
"completing-read" (0x7c6eebb8)
"read-file-name" (0x7c6ef108)
"find-file-read-args" (0x7c6ef638)
"byte-code" (0x7c6efa70)
"call-interactively" (0x7c6eff78)
--
Juri Linkov
http://www.jurta.org/emacs/
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#4879: Crash in xmenu_show
2009-11-06 11:50 ` Eli Zaretskii
2009-11-06 15:11 ` Jan Djärv
@ 2009-11-06 21:10 ` Juri Linkov
2009-11-07 9:03 ` Eli Zaretskii
2009-11-11 16:39 ` Stefan Monnier
1 sibling, 2 replies; 14+ messages in thread
From: Juri Linkov @ 2009-11-06 21:10 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 4879
> What does it mean, exactly? Why didn't you send the report using "M-x
> report-emacs-bug RET", where all this information is automatically
> included?
`M-x report-emacs-bug RET' includes irrelevant information - the date
it inserts in the version string is the date of compilation that
provides no help to reproduce the bug. Is it possible to replace it
with the date of the last CVS checkout/update that says exactly what
state of the code repository contains the bug?
--
Juri Linkov
http://www.jurta.org/emacs/
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#4879: Crash in xmenu_show
2009-11-06 21:10 ` Juri Linkov
@ 2009-11-07 9:03 ` Eli Zaretskii
2009-11-11 15:11 ` Kevin Rodgers
2009-11-11 16:39 ` Stefan Monnier
1 sibling, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2009-11-07 9:03 UTC (permalink / raw)
To: Juri Linkov; +Cc: 4879
> From: Juri Linkov <juri@jurta.org>
> Cc: 4879@emacsbugs.donarmstrong.com
> Date: Fri, 06 Nov 2009 23:10:27 +0200
>
> > What does it mean, exactly? Why didn't you send the report using "M-x
> > report-emacs-bug RET", where all this information is automatically
> > included?
>
> `M-x report-emacs-bug RET' includes irrelevant information
OTOH, it includes some very relevant one - the exact way you
configured Emacs for the build, and the language environment in which
you invoked Emacs. These are there for a reason, and if you don't
want to send the whole report for some reason, at least send these
parts of it. How can we possibly educate users to use this facility
if the developers themselves don't?
> the date
> it inserts in the version string is the date of compilation that
> provides no help to reproduce the bug. Is it possible to replace it
> with the date of the last CVS checkout/update that says exactly what
> state of the code repository contains the bug?
Everything's possible -- this is software. You could write code that
looks in the ChangeLog files for the latest log entries in src/,
lisp/, and leim/, for example. Or the code could look at the time
stamp of some CVS/Template file (in any directory) -- but this needs
to be changed for those who use VCs other than CVS, and for everybody
when we switch to bzr.
Personally, I never build without "cvs update", so the build time is
almost exactly the checkout time.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#4879: Crash in xmenu_show
[not found] <87aayzchne.fsf@stupidchicken.com>
@ 2009-11-08 3:43 ` Stefan Monnier
2009-11-08 5:02 ` Chong Yidong
0 siblings, 1 reply; 14+ messages in thread
From: Stefan Monnier @ 2009-11-08 3:43 UTC (permalink / raw)
To: Chong Yidong; +Cc: 4879
>>>>> "Chong" == Chong Yidong <cyd@stupidchicken.com> writes:
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread 0x7fb3746be7a0 (LWP 19530)]
>> 0x00000000004701c7 in xmenu_show (f=0x11c46e0, x=227, y=29, for_click=1, keymaps=1, title=12708355, error=0x7fff7c6ed8c0) at xmenu.c:2735
>> 2735 bcopy (SDATA (item_name), item_data,
> The problem is that
> XVECTOR (menu_items)->contents[i + MENU_ITEMS_ITEM_EQUIV_KEY];
> is now a symbol, but the code (here and in a couple of other places in
> xmenu.c, and maybe elsewhere) assumes that it's a string or nil.
> It's simple to "fix" by adding an additional check for symbols as menu
> descriptors, but we need to understand why the situation has changed.
> Stefan, I'm 99% sure this was caused by your keymap changes around
> 2009-09-11. Could you please debug them?
Hmm... not sure how it relates, but I see one possible trouble spot.
Does the patch below help?
Stefan
--- keyboard.c.~1.1016.~ 2009-10-24 22:39:01.000000000 -0400
+++ keyboard.c 2009-11-07 22:41:50.000000000 -0500
@@ -8118,6 +8118,8 @@
tem = concat2 (build_string (" "), tem);
/* tem = concat3 (build_string (" ("), tem, build_string (")")); */
}
+ else
+ tem = Qnil;
}
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#4879: Crash in xmenu_show
2009-11-08 3:43 ` Stefan Monnier
@ 2009-11-08 5:02 ` Chong Yidong
2009-11-08 15:07 ` Stefan Monnier
0 siblings, 1 reply; 14+ messages in thread
From: Chong Yidong @ 2009-11-08 5:02 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 4879
Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
> Hmm... not sure how it relates, but I see one possible trouble spot.
> Does the patch below help?
It eliminates the bug, yes. Thanks.
(BTW, you left some trailing whitespace when you last changed this part
of the code.)
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#4879: Crash in xmenu_show
2009-11-08 5:02 ` Chong Yidong
@ 2009-11-08 15:07 ` Stefan Monnier
2009-11-09 0:49 ` Juri Linkov
0 siblings, 1 reply; 14+ messages in thread
From: Stefan Monnier @ 2009-11-08 15:07 UTC (permalink / raw)
To: Chong Yidong; +Cc: 4879
>> Hmm... not sure how it relates, but I see one possible trouble spot.
>> Does the patch below help?
> It eliminates the bug, yes. Thanks.
I installed a cosmetically different fix,
Stefan
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#4879: Crash in xmenu_show
2009-11-08 15:07 ` Stefan Monnier
@ 2009-11-09 0:49 ` Juri Linkov
0 siblings, 0 replies; 14+ messages in thread
From: Juri Linkov @ 2009-11-09 0:49 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Chong Yidong, 4879
>>> Hmm... not sure how it relates, but I see one possible trouble spot.
>>> Does the patch below help?
>> It eliminates the bug, yes. Thanks.
>
> I installed a cosmetically different fix,
Thanks, it helped.
--
Juri Linkov
http://www.jurta.org/emacs/
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#4879: Crash in xmenu_show
2009-11-07 9:03 ` Eli Zaretskii
@ 2009-11-11 15:11 ` Kevin Rodgers
0 siblings, 0 replies; 14+ messages in thread
From: Kevin Rodgers @ 2009-11-11 15:11 UTC (permalink / raw)
To: bug-gnu-emacs
Eli Zaretskii wrote:
>> From: Juri Linkov <juri@jurta.org>
>> Cc: 4879@emacsbugs.donarmstrong.com
>> Date: Fri, 06 Nov 2009 23:10:27 +0200
...
>> the date
>> it inserts in the version string is the date of compilation that
>> provides no help to reproduce the bug. Is it possible to replace it
>> with the date of the last CVS checkout/update that says exactly what
>> state of the code repository contains the bug?
>
> Everything's possible -- this is software. You could write code that
> looks in the ChangeLog files for the latest log entries in src/,
> lisp/, and leim/, for example. Or the code could look at the time
> stamp of some CVS/Template file (in any directory) -- but this needs
> to be changed for those who use VCs other than CVS, and for everybody
> when we switch to bzr.
>
> Personally, I never build without "cvs update", so the build time is
> almost exactly the checkout time.
3rd party distributions may not use the same procedure as you, and they seem
to generate a fair number of bug reports.
--
Kevin Rodgers
Denver, Colorado, USA
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#4879: Crash in xmenu_show
2009-11-06 21:10 ` Juri Linkov
2009-11-07 9:03 ` Eli Zaretskii
@ 2009-11-11 16:39 ` Stefan Monnier
2009-11-14 4:39 ` Glenn Morris
1 sibling, 1 reply; 14+ messages in thread
From: Stefan Monnier @ 2009-11-11 16:39 UTC (permalink / raw)
To: Juri Linkov; +Cc: 4879
> Is it possible to replace it with the date of the last CVS
> checkout/update that says exactly what state of the code repository
> contains the bug?
Patches welcome (but they should also work for Bzr checkouts and
probably Git checkouts as well, and for the code not to suck that
basically means it should be VCS-agnostic).
Stefan
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#4879: Crash in xmenu_show
2009-11-11 16:39 ` Stefan Monnier
@ 2009-11-14 4:39 ` Glenn Morris
2009-11-14 7:10 ` Stefan Monnier
0 siblings, 1 reply; 14+ messages in thread
From: Glenn Morris @ 2009-11-14 4:39 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 4879
Stefan Monnier wrote:
>> Is it possible to replace it with the date of the last CVS
>> checkout/update that says exactly what state of the code repository
>> contains the bug?
>
> Patches welcome (but they should also work for Bzr checkouts and
> probably Git checkouts as well, and for the code not to suck that
> basically means it should be VCS-agnostic).
Have a file in the repository that is automatically committed (eg via
cron) on a periodic basis with just a date-stamp?
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#4879: Crash in xmenu_show
2009-11-14 4:39 ` Glenn Morris
@ 2009-11-14 7:10 ` Stefan Monnier
0 siblings, 0 replies; 14+ messages in thread
From: Stefan Monnier @ 2009-11-14 7:10 UTC (permalink / raw)
To: Glenn Morris; +Cc: 4879
>>> Is it possible to replace it with the date of the last CVS
>>> checkout/update that says exactly what state of the code repository
>>> contains the bug?
>> Patches welcome (but they should also work for Bzr checkouts and
>> probably Git checkouts as well, and for the code not to suck that
>> basically means it should be VCS-agnostic).
> Have a file in the repository that is automatically committed (eg via
> cron) on a periodic basis with just a date-stamp?
I'd much rather not clutter the VCS history with umpteen dummy commits.
Stefan
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2009-11-14 7:10 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-11-06 10:49 bug#4879: Crash in xmenu_show Juri Linkov
2009-11-06 11:50 ` Eli Zaretskii
2009-11-06 15:11 ` Jan Djärv
2009-11-06 21:06 ` Juri Linkov
2009-11-06 21:10 ` Juri Linkov
2009-11-07 9:03 ` Eli Zaretskii
2009-11-11 15:11 ` Kevin Rodgers
2009-11-11 16:39 ` Stefan Monnier
2009-11-14 4:39 ` Glenn Morris
2009-11-14 7:10 ` Stefan Monnier
[not found] <87aayzchne.fsf@stupidchicken.com>
2009-11-08 3:43 ` Stefan Monnier
2009-11-08 5:02 ` Chong Yidong
2009-11-08 15:07 ` Stefan Monnier
2009-11-09 0:49 ` Juri Linkov
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).