Reported by: David Engster <deng <at> randomsample.de>
Date: Wed, 31 Mar 2010 10:28:01 UTC
Severity: normal
Done: Chong Yidong <cyd <at> stupidchicken.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 5811 in the body.
You can then email your comments to 5811 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:bug#5811; Package emacs.
(Wed, 31 Mar 2010 10:28:01 GMT) Full text and rfc822 format available.David Engster <deng <at> randomsample.de>:bug-gnu-emacs <at> gnu.org.
(Wed, 31 Mar 2010 10:28:01 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: David Engster <deng <at> randomsample.de> To: bug-gnu-emacs <at> gnu.org Subject: 23.1.94; Emacs Nextstep port crashes after graphical yes-or-no-p Date: Wed, 31 Mar 2010 12:26:15 +0200
I've notice that Emacs didn't seem to correctly deal with graphical
'yes-or-no-p' question. When I've tried to further investigate this
issue, I've got Emacs to crash upon the following code:
* Emacs -Q
* Evalute the following:
(let ((last-nonmenu-event nil))
(yes-or-no-p "Question"))
* Click on "No"
Emacs crashes with EXC_BAD_ACCESS.
The above code runs fine when running Emacs under X11 on the same system.
I'm using the latest pretest (23.1.94), configured only with
"--with-ns", on Mac OS X 10.6.3., using the following gcc:
Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5646.1~2/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5646) (dot 1)
Here are the backtraces from running in gdb:
-------------------------- Normal backtrace -------------------------------------
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000001800010
print_object (obj=25165834, printcharfun=4320133130, escapeflag=1) at print.c:1739
1739 register unsigned char *p = SDATA (SYMBOL_NAME (obj));
(gdb) bt
#0 print_object (obj=25165834, printcharfun=4320133130, escapeflag=1) at print.c:1739
#1 0x00000001001300f3 in Fprin1_to_string (object=25165834, noescape=4320133130) at print.c:792
#2 0x0000000100111431 in Ffuncall (nargs=2, args=<value temporarily unavailable, due to optimizations>) at eval.c:3027
#3 0x000000010014dc1e in Fbyte_code (bytestr=<value temporarily unavailable, due to optimizations>, vector=<value temporarily unavailable, due to optimizations>, maxdepth=<value temporarily unavailable, due to optimizations>) at bytecode.c:680
#4 0x0000000100110d8c in funcall_lambda (fun=4298756909, nargs=1, arg_vector=0x7fff5fbfda18) at eval.c:3211
#5 0x00000001001111d2 in Ffuncall (nargs=2, args=<value temporarily unavailable, due to optimizations>) at eval.c:3081
#6 0x000000010014dc1e in Fbyte_code (bytestr=<value temporarily unavailable, due to optimizations>, vector=<value temporarily unavailable, due to optimizations>, maxdepth=<value temporarily unavailable, due to optimizations>) at bytecode.c:680
#7 0x0000000100110d8c in funcall_lambda (fun=4298756709, nargs=1, arg_vector=0x7fff5fbfdbf8) at eval.c:3211
#8 0x00000001001111d2 in Ffuncall (nargs=2, args=<value temporarily unavailable, due to optimizations>) at eval.c:3081
#9 0x000000010014dc1e in Fbyte_code (bytestr=<value temporarily unavailable, due to optimizations>, vector=<value temporarily unavailable, due to optimizations>, maxdepth=<value temporarily unavailable, due to optimizations>) at bytecode.c:680
#10 0x0000000100110d8c in funcall_lambda (fun=4298757197, nargs=1, arg_vector=0x7fff5fbfde28) at eval.c:3211
#11 0x00000001001111d2 in Ffuncall (nargs=2, args=<value temporarily unavailable, due to optimizations>) at eval.c:3081
#12 0x000000010010dd6e in Fcall_interactively (function=4321163482, record_flag=4320133130, keys=4317002904) at callint.c:869
#13 0x000000010011141c in Ffuncall (nargs=4, args=<value temporarily unavailable, due to optimizations>) at eval.c:3030
#14 0x00000001001115c6 in call3 (fn=<value temporarily unavailable, due to optimizations>, arg1=<value temporarily unavailable, due to optimizations>, arg2=<value temporarily unavailable, due to optimizations>, arg3=<value temporarily unavailable, due to optimizations>) at eval.c:2850
#15 0x00000001000ab987 in command_loop_1 () at keyboard.c:1904
#16 0x000000010010f8a7 in internal_condition_case (bfun=0x1000ab4c0 <command_loop_1>, handlers=4320204218, hfun=0x1000a3770 <cmd_error>) at eval.c:1490
#17 0x00000001000a2af7 in command_loop_2 () at keyboard.c:1360
#18 0x000000010010f9b0 in internal_catch (tag=<value temporarily unavailable, due to optimizations>, func=0x1000a2ac0 <command_loop_2>, arg=4320133130) at eval.c:1226
#19 0x00000001000a3586 in command_loop () at keyboard.c:1339
#20 0x00000001000a39ef in recursive_edit_1 () at keyboard.c:954
#21 0x00000001000a3b8f in Frecursive_edit () at keyboard.c:1016
#22 0x0000000100099147 in main (argc=2, argv=0x7fff5fbfe688) at emacs.c:1833
---------------------------------------------------------------------------------
---------------------------- Full Backtrace -------------------------------------
(gdb) bt full
#0 print_object (obj=25165834, printcharfun=4320133130, escapeflag=1) at print.c:1739
end = <value temporarily unavailable, due to optimizations>
c = <value temporarily unavailable, due to optimizations>
i_byte = <value temporarily unavailable, due to optimizations>
confusing = <value temporarily unavailable, due to optimizations>
p = <value temporarily unavailable, due to optimizations>
size_byte = <value temporarily unavailable, due to optimizations>
buf = "@Ö¿_ÿ\000\000hf4ÿ\000\000Ö¿_ÿ\000\000è\003\000\000\000\000\000\000`Ö¿_\001\000\000"
#1 0x00000001001300f3 in Fprin1_to_string (object=25165834, noescape=4320133130) at print.c:792
old = (struct buffer *) 0x101502ac8
start_point = -1
start_point_byte = -1
free_print_buffer = 1
old_point = -1
old_point_byte = -1
printcharfun = 4320133130
save_deactivate_mark = 4320133130
previous = <value temporarily unavailable, due to optimizations>
#2 0x0000000100111431 in Ffuncall (nargs=2, args=<value temporarily unavailable, due to optimizations>) at eval.c:3027
fun = <value temporarily unavailable, due to optimizations>
original_fun = <value temporarily unavailable, due to optimizations>
funcar = <value temporarily unavailable, due to optimizations>
numargs = 1
val = <value temporarily unavailable, due to optimizations>
backtrace = {
next = 0x7fff5fbfd9a0,
function = 0x7fff5fbfd800,
args = 0x7fff5fbfd808,
nargs = 1,
evalargs = 0 '\0',
debug_on_exit = 0 '\0'
}
internal_args = (Lisp_Object *) 0x7fff5fbfd750
i = <value temporarily unavailable, due to optimizations>
#3 0x000000010014dc1e in Fbyte_code (bytestr=<value temporarily unavailable, due to optimizations>, vector=<value temporarily unavailable, due to optimizations>, maxdepth=<value temporarily unavailable, due to optimizations>) at bytecode.c:680
count = 10
op = <value temporarily unavailable, due to optimizations>
vectorp = (Lisp_Object *) 0x10039d398
stack = {
pc = 0x100469da7 "*\v\f`Æ\035\036\016\030\031\036\017È\n!É\n!\036\020$",
top = 0x7fff5fbfd808,
bottom = 0x7fff5fbfd800,
byte_string = 4298756969,
byte_string_start = 0x100469da0 "Æ\030\031Ç\n!*\v\f`Æ\035\036\016\030\031\036\017È\n!É\n!\036\020$",
constants = 4298757005,
next = 0x7fff5fbfda60
}
top = (Lisp_Object *) 0x7fff5fbfd800
result = <value temporarily unavailable, due to optimizations>
#4 0x0000000100110d8c in funcall_lambda (fun=4298756909, nargs=1, arg_vector=0x7fff5fbfda18) at eval.c:3211
val = <value temporarily unavailable, due to optimizations>
syms_left = <value temporarily unavailable, due to optimizations>
next = <value temporarily unavailable, due to optimizations>
i = 1
optional = 0
rest = 0
#5 0x00000001001111d2 in Ffuncall (nargs=2, args=<value temporarily unavailable, due to optimizations>) at eval.c:3081
fun = <value temporarily unavailable, due to optimizations>
original_fun = 4324698170
funcar = <value temporarily unavailable, due to optimizations>
numargs = 1
val = <value temporarily unavailable, due to optimizations>
backtrace = {
next = 0x7fff5fbfdb80,
function = 0x7fff5fbfda10,
args = 0x7fff5fbfda18,
nargs = 1,
evalargs = 0 '\0',
debug_on_exit = 0 '\0'
}
internal_args = (Lisp_Object *) 0x7fff5fbfda18
i = <value temporarily unavailable, due to optimizations>
#6 0x000000010014dc1e in Fbyte_code (bytestr=<value temporarily unavailable, due to optimizations>, vector=<value temporarily unavailable, due to optimizations>, maxdepth=<value temporarily unavailable, due to optimizations>) at bytecode.c:680
count = 8
op = <value temporarily unavailable, due to optimizations>
vectorp = (Lisp_Object *) 0x10039d2d8
stack = {
pc = 0x100469e10 ")",
top = 0x7fff5fbfda18,
bottom = 0x7fff5fbfda10,
byte_string = 4298756777,
byte_string_start = 0x100469e00 "\b\b",
constants = 4298756813,
next = 0x7fff5fbfdc40
}
top = (Lisp_Object *) 0x7fff5fbfda10
result = <value temporarily unavailable, due to optimizations>
#7 0x0000000100110d8c in funcall_lambda (fun=4298756709, nargs=1, arg_vector=0x7fff5fbfdbf8) at eval.c:3211
val = <value temporarily unavailable, due to optimizations>
syms_left = <value temporarily unavailable, due to optimizations>
next = <value temporarily unavailable, due to optimizations>
i = 1
optional = 0
rest = 0
#8 0x00000001001111d2 in Ffuncall (nargs=2, args=<value temporarily unavailable, due to optimizations>) at eval.c:3081
fun = <value temporarily unavailable, due to optimizations>
original_fun = 4324684746
funcar = <value temporarily unavailable, due to optimizations>
numargs = 1
val = <value temporarily unavailable, due to optimizations>
backtrace = {
next = 0x7fff5fbfdd60,
function = 0x7fff5fbfdbf0,
args = 0x7fff5fbfdbf8,
nargs = 1,
evalargs = 0 '\0',
debug_on_exit = 0 '\0'
}
internal_args = (Lisp_Object *) 0x7fff5fbfdbf8
i = <value temporarily unavailable, due to optimizations>
#9 0x000000010014dc1e in Fbyte_code (bytestr=<value temporarily unavailable, due to optimizations>, vector=<value temporarily unavailable, due to optimizations>, maxdepth=<value temporarily unavailable, due to optimizations>) at bytecode.c:680
count = 6
op = <value temporarily unavailable, due to optimizations>
vectorp = (Lisp_Object *) 0x10039d4c8
stack = {
pc = 0x100469d73 "\v)B\034A\n=
\033",
top = 0x7fff5fbfdbf8,
bottom = 0x7fff5fbfdbf0,
byte_string = 4298757273,
byte_string_start = 0x100469d66 "\b
\b",
constants = 4298757309,
next = 0x0
}
top = (Lisp_Object *) 0x7fff5fbfdbf0
result = <value temporarily unavailable, due to optimizations>
#10 0x0000000100110d8c in funcall_lambda (fun=4298757197, nargs=1, arg_vector=0x7fff5fbfde28) at eval.c:3211
val = <value temporarily unavailable, due to optimizations>
syms_left = <value temporarily unavailable, due to optimizations>
next = <value temporarily unavailable, due to optimizations>
i = 1
optional = 0
rest = 0
#11 0x00000001001111d2 in Ffuncall (nargs=2, args=<value temporarily unavailable, due to optimizations>) at eval.c:3081
fun = <value temporarily unavailable, due to optimizations>
original_fun = 4321163482
funcar = <value temporarily unavailable, due to optimizations>
numargs = 1
val = <value temporarily unavailable, due to optimizations>
backtrace = {
next = 0x7fff5fbfe000,
function = 0x7fff5fbfde20,
args = 0x7fff5fbfde28,
nargs = 1,
evalargs = 0 '\0',
debug_on_exit = 0 '\0'
}
internal_args = (Lisp_Object *) 0x7fff5fbfde28
i = <value temporarily unavailable, due to optimizations>
#12 0x000000010010dd6e in Fcall_interactively (function=4321163482, record_flag=4320133130, keys=4317002904) at callint.c:869
val = <value temporarily unavailable, due to optimizations>
args = (Lisp_Object *) 0x7fff5fbfde20
visargs = (Lisp_Object *) 0x7fff5fbfde00
specs = 4320133130
filter_specs = <value temporarily unavailable, due to optimizations>
teml = 1
up_event = 4320133130
enable = 4320133130
speccount = 3
next_event = 2
prefix_arg = 4320133130
string = <value temporarily unavailable, due to optimizations>
tem = (unsigned char *) 0x10019edf0 ""
varies = (int *) 0x7fff5fbfdde0
i = 1
j = 1
foo = <value temporarily unavailable, due to optimizations>
prompt1 = '\0' <repeats 99 times>
arg_from_tty = 0
key_count = 2
record_then_fail = 0
save_this_command = 4321163482
save_last_command = 4320190778
save_this_original_command = 4321163482
save_real_this_command = 4321163482
#13 0x000000010011141c in Ffuncall (nargs=4, args=<value temporarily unavailable, due to optimizations>) at eval.c:3030
fun = <value temporarily unavailable, due to optimizations>
original_fun = <value temporarily unavailable, due to optimizations>
funcar = <value temporarily unavailable, due to optimizations>
numargs = 3
val = <value temporarily unavailable, due to optimizations>
backtrace = {
next = 0x0,
function = 0x7fff5fbfe070,
args = 0x7fff5fbfe078,
nargs = 3,
evalargs = 0 '\0',
debug_on_exit = 0 '\0'
}
internal_args = (Lisp_Object *) 0x7fff5fbfe078
i = <value temporarily unavailable, due to optimizations>
#14 0x00000001001115c6 in call3 (fn=<value temporarily unavailable, due to optimizations>, arg1=<value temporarily unavailable, due to optimizations>, arg2=<value temporarily unavailable, due to optimizations>, arg3=<value temporarily unavailable, due to optimizations>) at eval.c:2850
ret_ungc_val = 4296201300
args = {4320305978, 4321163482, 4320133130, 4320133130}
#15 0x00000001000ab987 in command_loop_1 () at keyboard.c:1904
cmd = <value temporarily unavailable, due to optimizations>
lose = <value temporarily unavailable, due to optimizations>
keybuf = {96, 20, 140734799798792, 4297574704, 4611686018427404288, 4611686018427389952, 4300458264, 4300480048, 140734799798736, 4296082611, 140734799798592, 140734799861322, 0, 3, 140734799798792, 0, 140734800084000, 0, 140734799798688, 140734799883712, 0, 140734800069792, 0, 140734799798672, 140734799798416, 0, 4300526552, 4320133130, 4321264154, -8680165209918493533}
i = <value temporarily unavailable, due to optimizations>
prev_modiff = 264
prev_buffer = (struct buffer *) 0x101502ac8
already_adjusted = 0
#16 0x000000010010f8a7 in internal_condition_case (bfun=0x1000ab4c0 <command_loop_1>, handlers=4320204218, hfun=0x1000a3770 <cmd_error>) at eval.c:1490
val = <value temporarily unavailable, due to optimizations>
c = {
tag = 4320133130,
val = 4320133130,
next = 0x7fff5fbfe360,
gcpro = 0x0,
jmp = {5512632, 1, 1606411040, 32767, 1606410720, 32767, 5512472, 1, 5489576, 1, 5490968, 1, 5512752, 1, 1112097, 1, 530, 0, 8096, 895, 1606411136, 32767, 668720, 1, 5513384, 1, 5513328, 1, 2, 0, 0, 0, 0, 0, 6886400, 1, 0},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0,
pdlcount = 2,
poll_suppress_count = 0,
interrupt_input_blocked = 0,
byte_stack = 0x0
}
h = {
handler = 4320204218,
var = 4320133130,
chosen_clause = 3418355679867659105,
tag = 0x7fff5fbfe200,
next = 0x0
}
#17 0x00000001000a2af7 in command_loop_2 () at keyboard.c:1360
val = 4296201300
#18 0x000000010010f9b0 in internal_catch (tag=<value temporarily unavailable, due to optimizations>, func=0x1000a2ac0 <command_loop_2>, arg=4320133130) at eval.c:1226
c = {
tag = 4320197482,
val = 4320133130,
next = 0x0,
gcpro = 0x0,
jmp = {5512632, 1, 1606411328, 32767, 1606411088, 32767, 5512768, 1, 5489576, 1, 5490968, 1, 5512752, 1, 1112479, 1, 534, 0, 8096, 895, 0, 0, 344, 0, 1606411264, 22, -2026609048, 32767, 0, 10, 25412515, 1, 25416952, 1, 25412512, 1, 22031048},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0,
pdlcount = 2,
poll_suppress_count = 0,
interrupt_input_blocked = 0,
byte_stack = 0x0
}
#19 0x00000001000a3586 in command_loop () at keyboard.c:1339
No locals.
#20 0x00000001000a39ef in recursive_edit_1 () at keyboard.c:954
val = <value temporarily unavailable, due to optimizations>
#21 0x00000001000a3b8f in Frecursive_edit () at keyboard.c:1016
count = <value temporarily unavailable, due to optimizations>
buffer = 4320133130
#22 0x0000000100099147 in main (argc=2, argv=0x7fff5fbfe688) at emacs.c:1833
dummy = 0
stack_bottom_variable = -106 ''
do_initial_setlocale = <value temporarily unavailable, due to optimizations>
skip_args = 0
rlim = {
rlim_cur = 8720000,
rlim_max = 67104768
}
no_loadup = 0
junk = 0x0
dname_arg = 0x0
dname_arg2 = "\000\000\000\000\000\000\000\000æ¿_ÿ\000\000\000\000\000\000\002\000\000\000\000\000\000\000\001\000\000\000\000\000À_ÿ\000\000\000\000\000\000\000\000\000\000ø\005À_ÿ\000\000\t\000\000\000\t\000\000\000¨ç¿_ÿ\000\000`\aÀ_ÿ\000"
----------------------------------------------------------------------------------
Glenn Morris <rgm <at> gnu.org>
to control <at> debbugs.gnu.org.
(Wed, 31 Mar 2010 18:01:01 GMT) Full text and rfc822 format available.owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:bug#5811; Package emacs,ns.
(Thu, 01 Apr 2010 15:32:01 GMT) Full text and rfc822 format available.Message #10 received at 5811 <at> debbugs.gnu.org (full text, mbox):
From: Chong Yidong <cyd <at> stupidchicken.com> To: Adrian Robert <adrian.b.robert <at> gmail.com> Cc: 5811 <at> debbugs.gnu.org, David Engster <deng <at> randomsample.de> Subject: Re: bug#5811: 23.1.94; Emacs Nextstep port crashes after graphical yes-or-no-p Date: Thu, 01 Apr 2010 11:31:47 -0400
Could you take a look at this bug report? Thanks.
David, it would help if you compile Emacs without optimizations. That
makes the stack trace easier to read.
David Engster <deng <at> randomsample.de> writes:
> I've notice that Emacs didn't seem to correctly deal with graphical
> 'yes-or-no-p' question. When I've tried to further investigate this
> issue, I've got Emacs to crash upon the following code:
>
> * Emacs -Q
>
> * Evalute the following:
>
> (let ((last-nonmenu-event nil))
> (yes-or-no-p "Question"))
>
> * Click on "No"
>
> Emacs crashes with EXC_BAD_ACCESS.
>
> The above code runs fine when running Emacs under X11 on the same system.
>
> I'm using the latest pretest (23.1.94), configured only with
> "--with-ns", on Mac OS X 10.6.3., using the following gcc:
>
> Using built-in specs.
> Target: i686-apple-darwin10
> Configured with: /var/tmp/gcc/gcc-5646.1~2/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10
> Thread model: posix
> gcc version 4.2.1 (Apple Inc. build 5646) (dot 1)
>
> Here are the backtraces from running in gdb:
>
> -------------------------- Normal backtrace -------------------------------------
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0x0000000001800010
> print_object (obj=25165834, printcharfun=4320133130, escapeflag=1) at print.c:1739
> 1739 register unsigned char *p = SDATA (SYMBOL_NAME (obj));
> (gdb) bt
> #0 print_object (obj=25165834, printcharfun=4320133130, escapeflag=1) at print.c:1739
> #1 0x00000001001300f3 in Fprin1_to_string (object=25165834, noescape=4320133130) at print.c:792
> #2 0x0000000100111431 in Ffuncall (nargs=2, args=<value temporarily unavailable, due to optimizations>) at eval.c:3027
> #3 0x000000010014dc1e in Fbyte_code (bytestr=<value temporarily unavailable, due to optimizations>, vector=<value temporarily unavailable, due to optimizations>, maxdepth=<value temporarily unavailable, due to optimizations>) at bytecode.c:680
> #4 0x0000000100110d8c in funcall_lambda (fun=4298756909, nargs=1, arg_vector=0x7fff5fbfda18) at eval.c:3211
> #5 0x00000001001111d2 in Ffuncall (nargs=2, args=<value temporarily unavailable, due to optimizations>) at eval.c:3081
> #6 0x000000010014dc1e in Fbyte_code (bytestr=<value temporarily unavailable, due to optimizations>, vector=<value temporarily unavailable, due to optimizations>, maxdepth=<value temporarily unavailable, due to optimizations>) at bytecode.c:680
> #7 0x0000000100110d8c in funcall_lambda (fun=4298756709, nargs=1, arg_vector=0x7fff5fbfdbf8) at eval.c:3211
> #8 0x00000001001111d2 in Ffuncall (nargs=2, args=<value temporarily unavailable, due to optimizations>) at eval.c:3081
> #9 0x000000010014dc1e in Fbyte_code (bytestr=<value temporarily unavailable, due to optimizations>, vector=<value temporarily unavailable, due to optimizations>, maxdepth=<value temporarily unavailable, due to optimizations>) at bytecode.c:680
> #10 0x0000000100110d8c in funcall_lambda (fun=4298757197, nargs=1, arg_vector=0x7fff5fbfde28) at eval.c:3211
> #11 0x00000001001111d2 in Ffuncall (nargs=2, args=<value temporarily unavailable, due to optimizations>) at eval.c:3081
> #12 0x000000010010dd6e in Fcall_interactively (function=4321163482, record_flag=4320133130, keys=4317002904) at callint.c:869
> #13 0x000000010011141c in Ffuncall (nargs=4, args=<value temporarily unavailable, due to optimizations>) at eval.c:3030
> #14 0x00000001001115c6 in call3 (fn=<value temporarily unavailable, due to optimizations>, arg1=<value temporarily unavailable, due to optimizations>, arg2=<value temporarily unavailable, due to optimizations>, arg3=<value temporarily unavailable, due to optimizations>) at eval.c:2850
> #15 0x00000001000ab987 in command_loop_1 () at keyboard.c:1904
> #16 0x000000010010f8a7 in internal_condition_case (bfun=0x1000ab4c0 <command_loop_1>, handlers=4320204218, hfun=0x1000a3770 <cmd_error>) at eval.c:1490
> #17 0x00000001000a2af7 in command_loop_2 () at keyboard.c:1360
> #18 0x000000010010f9b0 in internal_catch (tag=<value temporarily unavailable, due to optimizations>, func=0x1000a2ac0 <command_loop_2>, arg=4320133130) at eval.c:1226
> #19 0x00000001000a3586 in command_loop () at keyboard.c:1339
> #20 0x00000001000a39ef in recursive_edit_1 () at keyboard.c:954
> #21 0x00000001000a3b8f in Frecursive_edit () at keyboard.c:1016
> #22 0x0000000100099147 in main (argc=2, argv=0x7fff5fbfe688) at emacs.c:1833
> ---------------------------------------------------------------------------------
>
>
> ---------------------------- Full Backtrace -------------------------------------
> (gdb) bt full
> #0 print_object (obj=25165834, printcharfun=4320133130, escapeflag=1) at print.c:1739
> end = <value temporarily unavailable, due to optimizations>
> c = <value temporarily unavailable, due to optimizations>
> i_byte = <value temporarily unavailable, due to optimizations>
> confusing = <value temporarily unavailable, due to optimizations>
> p = <value temporarily unavailable, due to optimizations>
> size_byte = <value temporarily unavailable, due to optimizations>
> buf = "@Ö¿_ÿ\000\000hf4ÿ\000\000Ö¿_ÿ\000\000è\003\000\000\000\000\000\000`Ö¿_\001\000\000"
> #1 0x00000001001300f3 in Fprin1_to_string (object=25165834, noescape=4320133130) at print.c:792
> old = (struct buffer *) 0x101502ac8
> start_point = -1
> start_point_byte = -1
> free_print_buffer = 1
> old_point = -1
> old_point_byte = -1
> printcharfun = 4320133130
> save_deactivate_mark = 4320133130
> previous = <value temporarily unavailable, due to optimizations>
> #2 0x0000000100111431 in Ffuncall (nargs=2, args=<value temporarily unavailable, due to optimizations>) at eval.c:3027
> fun = <value temporarily unavailable, due to optimizations>
> original_fun = <value temporarily unavailable, due to optimizations>
> funcar = <value temporarily unavailable, due to optimizations>
> numargs = 1
> val = <value temporarily unavailable, due to optimizations>
> backtrace = {
> next = 0x7fff5fbfd9a0,
> function = 0x7fff5fbfd800,
> args = 0x7fff5fbfd808,
> nargs = 1,
> evalargs = 0 '\0',
> debug_on_exit = 0 '\0'
> }
> internal_args = (Lisp_Object *) 0x7fff5fbfd750
> i = <value temporarily unavailable, due to optimizations>
> #3 0x000000010014dc1e in Fbyte_code (bytestr=<value temporarily unavailable, due to optimizations>, vector=<value temporarily unavailable, due to optimizations>, maxdepth=<value temporarily unavailable, due to optimizations>) at bytecode.c:680
> count = 10
> op = <value temporarily unavailable, due to optimizations>
> vectorp = (Lisp_Object *) 0x10039d398
> stack = {
> pc = 0x100469da7 "*\v\f`Æ\035\036\016\030\031\036\017È\n!É\n!\036\020$",
> top = 0x7fff5fbfd808,
> bottom = 0x7fff5fbfd800,
> byte_string = 4298756969,
> byte_string_start = 0x100469da0 "Æ\030\031Ç\n!*\v\f`Æ\035\036\016\030\031\036\017È\n!É\n!\036\020$",
> constants = 4298757005,
> next = 0x7fff5fbfda60
> }
> top = (Lisp_Object *) 0x7fff5fbfd800
> result = <value temporarily unavailable, due to optimizations>
> #4 0x0000000100110d8c in funcall_lambda (fun=4298756909, nargs=1, arg_vector=0x7fff5fbfda18) at eval.c:3211
> val = <value temporarily unavailable, due to optimizations>
> syms_left = <value temporarily unavailable, due to optimizations>
> next = <value temporarily unavailable, due to optimizations>
> i = 1
> optional = 0
> rest = 0
> #5 0x00000001001111d2 in Ffuncall (nargs=2, args=<value temporarily unavailable, due to optimizations>) at eval.c:3081
> fun = <value temporarily unavailable, due to optimizations>
> original_fun = 4324698170
> funcar = <value temporarily unavailable, due to optimizations>
> numargs = 1
> val = <value temporarily unavailable, due to optimizations>
> backtrace = {
> next = 0x7fff5fbfdb80,
> function = 0x7fff5fbfda10,
> args = 0x7fff5fbfda18,
> nargs = 1,
> evalargs = 0 '\0',
> debug_on_exit = 0 '\0'
> }
> internal_args = (Lisp_Object *) 0x7fff5fbfda18
> i = <value temporarily unavailable, due to optimizations>
> #6 0x000000010014dc1e in Fbyte_code (bytestr=<value temporarily unavailable, due to optimizations>, vector=<value temporarily unavailable, due to optimizations>, maxdepth=<value temporarily unavailable, due to optimizations>) at bytecode.c:680
> count = 8
> op = <value temporarily unavailable, due to optimizations>
> vectorp = (Lisp_Object *) 0x10039d2d8
> stack = {
> pc = 0x100469e10 ")",
> top = 0x7fff5fbfda18,
> bottom = 0x7fff5fbfda10,
> byte_string = 4298756777,
> byte_string_start = 0x100469e00 "\b\b",
> constants = 4298756813,
> next = 0x7fff5fbfdc40
> }
> top = (Lisp_Object *) 0x7fff5fbfda10
> result = <value temporarily unavailable, due to optimizations>
> #7 0x0000000100110d8c in funcall_lambda (fun=4298756709, nargs=1, arg_vector=0x7fff5fbfdbf8) at eval.c:3211
> val = <value temporarily unavailable, due to optimizations>
> syms_left = <value temporarily unavailable, due to optimizations>
> next = <value temporarily unavailable, due to optimizations>
> i = 1
> optional = 0
> rest = 0
> #8 0x00000001001111d2 in Ffuncall (nargs=2, args=<value temporarily unavailable, due to optimizations>) at eval.c:3081
> fun = <value temporarily unavailable, due to optimizations>
> original_fun = 4324684746
> funcar = <value temporarily unavailable, due to optimizations>
> numargs = 1
> val = <value temporarily unavailable, due to optimizations>
> backtrace = {
> next = 0x7fff5fbfdd60,
> function = 0x7fff5fbfdbf0,
> args = 0x7fff5fbfdbf8,
> nargs = 1,
> evalargs = 0 '\0',
> debug_on_exit = 0 '\0'
> }
> internal_args = (Lisp_Object *) 0x7fff5fbfdbf8
> i = <value temporarily unavailable, due to optimizations>
> #9 0x000000010014dc1e in Fbyte_code (bytestr=<value temporarily unavailable, due to optimizations>, vector=<value temporarily unavailable, due to optimizations>, maxdepth=<value temporarily unavailable, due to optimizations>) at bytecode.c:680
> count = 6
> op = <value temporarily unavailable, due to optimizations>
> vectorp = (Lisp_Object *) 0x10039d4c8
> stack = {
> pc = 0x100469d73 "\v)B\034A\n=
> \033",
> top = 0x7fff5fbfdbf8,
> bottom = 0x7fff5fbfdbf0,
> byte_string = 4298757273,
> byte_string_start = 0x100469d66 "\b
> \b",
> constants = 4298757309,
> next = 0x0
> }
> top = (Lisp_Object *) 0x7fff5fbfdbf0
> result = <value temporarily unavailable, due to optimizations>
> #10 0x0000000100110d8c in funcall_lambda (fun=4298757197, nargs=1, arg_vector=0x7fff5fbfde28) at eval.c:3211
> val = <value temporarily unavailable, due to optimizations>
> syms_left = <value temporarily unavailable, due to optimizations>
> next = <value temporarily unavailable, due to optimizations>
> i = 1
> optional = 0
> rest = 0
> #11 0x00000001001111d2 in Ffuncall (nargs=2, args=<value temporarily unavailable, due to optimizations>) at eval.c:3081
> fun = <value temporarily unavailable, due to optimizations>
> original_fun = 4321163482
> funcar = <value temporarily unavailable, due to optimizations>
> numargs = 1
> val = <value temporarily unavailable, due to optimizations>
> backtrace = {
> next = 0x7fff5fbfe000,
> function = 0x7fff5fbfde20,
> args = 0x7fff5fbfde28,
> nargs = 1,
> evalargs = 0 '\0',
> debug_on_exit = 0 '\0'
> }
> internal_args = (Lisp_Object *) 0x7fff5fbfde28
> i = <value temporarily unavailable, due to optimizations>
> #12 0x000000010010dd6e in Fcall_interactively (function=4321163482, record_flag=4320133130, keys=4317002904) at callint.c:869
> val = <value temporarily unavailable, due to optimizations>
> args = (Lisp_Object *) 0x7fff5fbfde20
> visargs = (Lisp_Object *) 0x7fff5fbfde00
> specs = 4320133130
> filter_specs = <value temporarily unavailable, due to optimizations>
> teml = 1
> up_event = 4320133130
> enable = 4320133130
> speccount = 3
> next_event = 2
> prefix_arg = 4320133130
> string = <value temporarily unavailable, due to optimizations>
> tem = (unsigned char *) 0x10019edf0 ""
> varies = (int *) 0x7fff5fbfdde0
> i = 1
> j = 1
> foo = <value temporarily unavailable, due to optimizations>
> prompt1 = '\0' <repeats 99 times>
> arg_from_tty = 0
> key_count = 2
> record_then_fail = 0
> save_this_command = 4321163482
> save_last_command = 4320190778
> save_this_original_command = 4321163482
> save_real_this_command = 4321163482
> #13 0x000000010011141c in Ffuncall (nargs=4, args=<value temporarily unavailable, due to optimizations>) at eval.c:3030
> fun = <value temporarily unavailable, due to optimizations>
> original_fun = <value temporarily unavailable, due to optimizations>
> funcar = <value temporarily unavailable, due to optimizations>
> numargs = 3
> val = <value temporarily unavailable, due to optimizations>
> backtrace = {
> next = 0x0,
> function = 0x7fff5fbfe070,
> args = 0x7fff5fbfe078,
> nargs = 3,
> evalargs = 0 '\0',
> debug_on_exit = 0 '\0'
> }
> internal_args = (Lisp_Object *) 0x7fff5fbfe078
> i = <value temporarily unavailable, due to optimizations>
> #14 0x00000001001115c6 in call3 (fn=<value temporarily unavailable, due to optimizations>, arg1=<value temporarily unavailable, due to optimizations>, arg2=<value temporarily unavailable, due to optimizations>, arg3=<value temporarily unavailable, due to optimizations>) at eval.c:2850
> ret_ungc_val = 4296201300
> args = {4320305978, 4321163482, 4320133130, 4320133130}
> #15 0x00000001000ab987 in command_loop_1 () at keyboard.c:1904
> cmd = <value temporarily unavailable, due to optimizations>
> lose = <value temporarily unavailable, due to optimizations>
> keybuf = {96, 20, 140734799798792, 4297574704, 4611686018427404288, 4611686018427389952, 4300458264, 4300480048, 140734799798736, 4296082611, 140734799798592, 140734799861322, 0, 3, 140734799798792, 0, 140734800084000, 0, 140734799798688, 140734799883712, 0, 140734800069792, 0, 140734799798672, 140734799798416, 0, 4300526552, 4320133130, 4321264154, -8680165209918493533}
> i = <value temporarily unavailable, due to optimizations>
> prev_modiff = 264
> prev_buffer = (struct buffer *) 0x101502ac8
> already_adjusted = 0
> #16 0x000000010010f8a7 in internal_condition_case (bfun=0x1000ab4c0 <command_loop_1>, handlers=4320204218, hfun=0x1000a3770 <cmd_error>) at eval.c:1490
> val = <value temporarily unavailable, due to optimizations>
> c = {
> tag = 4320133130,
> val = 4320133130,
> next = 0x7fff5fbfe360,
> gcpro = 0x0,
> jmp = {5512632, 1, 1606411040, 32767, 1606410720, 32767, 5512472, 1, 5489576, 1, 5490968, 1, 5512752, 1, 1112097, 1, 530, 0, 8096, 895, 1606411136, 32767, 668720, 1, 5513384, 1, 5513328, 1, 2, 0, 0, 0, 0, 0, 6886400, 1, 0},
> backlist = 0x0,
> handlerlist = 0x0,
> lisp_eval_depth = 0,
> pdlcount = 2,
> poll_suppress_count = 0,
> interrupt_input_blocked = 0,
> byte_stack = 0x0
> }
> h = {
> handler = 4320204218,
> var = 4320133130,
> chosen_clause = 3418355679867659105,
> tag = 0x7fff5fbfe200,
> next = 0x0
> }
> #17 0x00000001000a2af7 in command_loop_2 () at keyboard.c:1360
> val = 4296201300
> #18 0x000000010010f9b0 in internal_catch (tag=<value temporarily unavailable, due to optimizations>, func=0x1000a2ac0 <command_loop_2>, arg=4320133130) at eval.c:1226
> c = {
> tag = 4320197482,
> val = 4320133130,
> next = 0x0,
> gcpro = 0x0,
> jmp = {5512632, 1, 1606411328, 32767, 1606411088, 32767, 5512768, 1, 5489576, 1, 5490968, 1, 5512752, 1, 1112479, 1, 534, 0, 8096, 895, 0, 0, 344, 0, 1606411264, 22, -2026609048, 32767, 0, 10, 25412515, 1, 25416952, 1, 25412512, 1, 22031048},
> backlist = 0x0,
> handlerlist = 0x0,
> lisp_eval_depth = 0,
> pdlcount = 2,
> poll_suppress_count = 0,
> interrupt_input_blocked = 0,
> byte_stack = 0x0
> }
> #19 0x00000001000a3586 in command_loop () at keyboard.c:1339
> No locals.
> #20 0x00000001000a39ef in recursive_edit_1 () at keyboard.c:954
> val = <value temporarily unavailable, due to optimizations>
> #21 0x00000001000a3b8f in Frecursive_edit () at keyboard.c:1016
> count = <value temporarily unavailable, due to optimizations>
> buffer = 4320133130
> #22 0x0000000100099147 in main (argc=2, argv=0x7fff5fbfe688) at emacs.c:1833
> dummy = 0
> stack_bottom_variable = -106 ''
> do_initial_setlocale = <value temporarily unavailable, due to optimizations>
> skip_args = 0
> rlim = {
> rlim_cur = 8720000,
> rlim_max = 67104768
> }
> no_loadup = 0
> junk = 0x0
> dname_arg = 0x0
> dname_arg2 = "\000\000\000\000\000\000\000\000æ¿_ÿ\000\000\000\000\000\000\002\000\000\000\000\000\000\000\001\000\000\000\000\000À_ÿ\000\000\000\000\000\000\000\000\000\000ø\005À_ÿ\000\000\t\000\000\000\t\000\000\000¨ç¿_ÿ\000\000`\aÀ_ÿ\000"
> ----------------------------------------------------------------------------------
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:bug#5811; Package emacs,ns.
(Thu, 01 Apr 2010 20:32:02 GMT) Full text and rfc822 format available.Message #13 received at 5811 <at> debbugs.gnu.org (full text, mbox):
From: David Engster <deng <at> randomsample.de> To: Chong Yidong <cyd <at> stupidchicken.com> Cc: Adrian Robert <adrian.b.robert <at> gmail.com>, 5811 <at> debbugs.gnu.org Subject: Re: bug#5811: 23.1.94; Emacs Nextstep port crashes after graphical yes-or-no-p Date: Thu, 01 Apr 2010 22:30:56 +0200
Chong Yidong <cyd <at> stupidchicken.com> writes: > Could you take a look at this bug report? Thanks. > > David, it would help if you compile Emacs without optimizations. That > makes the stack trace easier to read. Currently, I only have access to a machine running Mac OS X 10.5.8, and there the crash does not happen. I should be able to run a non-optimized build with 10.6.3. on Tuesday. Regards, David
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:bug#5811; Package emacs,ns.
(Fri, 02 Apr 2010 06:00:03 GMT) Full text and rfc822 format available.Message #16 received at 5811 <at> debbugs.gnu.org (full text, mbox):
From: Adrian Robert <adrian.b.robert <at> gmail.com> To: David Engster <deng <at> randomsample.de> Cc: Chong Yidong <cyd <at> stupidchicken.com>, 5811 <at> debbugs.gnu.org Subject: Re: bug#5811: 23.1.94; Emacs Nextstep port crashes after graphical yes-or-no-p Date: Fri, 2 Apr 2010 08:58:53 +0300
> > Currently, I only have access to a machine running Mac OS X 10.5.8, and > there the crash does not happen. I should be able to run a non-optimized > build with 10.6.3. on Tuesday. Don't worry about it, I can reproduce it here on 10.6.2. I'm not sure whether it was something in Emacs that changed, or something in one of the point releases, as I'm pretty sure I debugged and fixed this same issue this past summer (cause was a missing function prototype) working under 10.6.1. I'm not sure at the moment when I will have time to dig into this though. -Adrian
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:bug#5811; Package emacs,ns.
(Tue, 06 Apr 2010 11:38:02 GMT) Full text and rfc822 format available.Message #19 received at 5811 <at> debbugs.gnu.org (full text, mbox):
From: David Engster <deng <at> randomsample.de> To: Adrian Robert <adrian.b.robert <at> gmail.com> Cc: Chong Yidong <cyd <at> stupidchicken.com>, 5811 <at> debbugs.gnu.org Subject: Re: bug#5811: 23.1.94; Emacs Nextstep port crashes after graphical yes-or-no-p Date: Tue, 06 Apr 2010 13:37:07 +0200
Adrian Robert <adrian.b.robert <at> gmail.com> writes:
>> Currently, I only have access to a machine running Mac OS X 10.5.8, and
>> there the crash does not happen. I should be able to run a non-optimized
>> build with 10.6.3. on Tuesday.
>
> Don't worry about it, I can reproduce it here on 10.6.2. I'm not sure whether it was something in Emacs that changed, or something in one of the point releases, as I'm pretty sure I debugged and fixed this same issue this past summer (cause was a missing function prototype) working under 10.6.1.
Do you mean this fix?
revno: 97065
committer: Adrian Robert <Adrian.B.Robert <at> gmail.com>
timestamp: Fri 2009-08-21 19:29:31 +0000
message:
nsfns.m (EmacsDialogPanel-runDialogAt): Add declaration of
timer_check() to avoid crash on Leopard/PPC. Bug #2154.
I cannot build a 64bit binary from this revision under 10.6.3.
FWIW, the earliest pretest I can actually compile under Snow Leopard is
23.1.91, and the bug already exists there.
Regards,
David
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:bug#5811; Package emacs,ns.
(Tue, 06 Apr 2010 12:31:02 GMT) Full text and rfc822 format available.Message #22 received at 5811 <at> debbugs.gnu.org (full text, mbox):
From: Adrian Robert <adrian.b.robert <at> gmail.com> To: David Engster <deng <at> randomsample.de> Cc: Chong Yidong <cyd <at> stupidchicken.com>, 5811 <at> debbugs.gnu.org Subject: Re: bug#5811: 23.1.94; Emacs Nextstep port crashes after graphical yes-or-no-p Date: Tue, 6 Apr 2010 15:30:40 +0300
>> >> Don't worry about it, I can reproduce it here on 10.6.2. I'm not sure whether it was something in Emacs that changed, or something in one of the point releases, as I'm pretty sure I debugged and fixed this same issue this past summer (cause was a missing function prototype) working under 10.6.1. > > Do you mean this fix? > > revno: 97065 > committer: Adrian Robert <Adrian.B.Robert <at> gmail.com> > timestamp: Fri 2009-08-21 19:29:31 +0000 > message: > nsfns.m (EmacsDialogPanel-runDialogAt): Add declaration of > timer_check() to avoid crash on Leopard/PPC. Bug #2154. OK -- I guess this was before my computer crash and forced upgrade to Snow Leopard then. I thought for sure I'd tested this stuff after that, but I guess not. ;-( -Adrian
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:bug#5811; Package emacs,ns.
(Tue, 06 Apr 2010 13:13:01 GMT) Full text and rfc822 format available.Message #25 received at 5811 <at> debbugs.gnu.org (full text, mbox):
From: David Engster <deng <at> randomsample.de> To: Adrian Robert <adrian.b.robert <at> gmail.com> Cc: Chong Yidong <cyd <at> stupidchicken.com>, 5811 <at> debbugs.gnu.org Subject: Re: bug#5811: 23.1.94; Emacs Nextstep port crashes after graphical yes-or-no-p Date: Tue, 06 Apr 2010 15:12:26 +0200
Adrian Robert <adrian.b.robert <at> gmail.com> writes: >>> >>> Don't worry about it, I can reproduce it here on 10.6.2. I'm not sure whether it was something in Emacs that changed, or something in one of the point releases, as I'm pretty sure I debugged and fixed this same issue this past summer (cause was a missing function prototype) working under 10.6.1. >> >> Do you mean this fix? >> >> revno: 97065 >> committer: Adrian Robert <Adrian.B.Robert <at> gmail.com> >> timestamp: Fri 2009-08-21 19:29:31 +0000 >> message: >> nsfns.m (EmacsDialogPanel-runDialogAt): Add declaration of >> timer_check() to avoid crash on Leopard/PPC. Bug #2154. > > OK -- I guess this was before my computer crash and forced upgrade to Snow Leopard then. > > I thought for sure I'd tested this stuff after that, but I guess not. ;-( Maybe you made a 32bit binary? When I compile with CC="gcc -arch i386" ./configure --with-ns the resulting binary does not crash on the test case. So it appears to be a problem with 64bit only. -David
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:bug#5811; Package emacs,ns.
(Tue, 06 Apr 2010 13:19:01 GMT) Full text and rfc822 format available.Message #28 received at 5811 <at> debbugs.gnu.org (full text, mbox):
From: Adrian Robert <adrian.b.robert <at> gmail.com> To: David Engster <deng <at> randomsample.de> Cc: Chong Yidong <cyd <at> stupidchicken.com>, 5811 <at> debbugs.gnu.org Subject: Re: bug#5811: 23.1.94; Emacs Nextstep port crashes after graphical yes-or-no-p Date: Tue, 6 Apr 2010 16:17:55 +0300
> Maybe you made a 32bit binary? > > When I compile with > > CC="gcc -arch i386" ./configure --with-ns > > the resulting binary does not crash on the test case. So it appears to > be a problem with 64bit only. Hmm, possibly. Anyway this suggests maybe it is also some sort of signature and/or argument-passing issue. The previous fix just corrected some kind misalignment problem due to the wrong size for the return type being allocated on the stack. -Adrian
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:bug#5811; Package emacs,ns.
(Sat, 10 Apr 2010 06:12:02 GMT) Full text and rfc822 format available.Message #31 received at 5811 <at> debbugs.gnu.org (full text, mbox):
From: Adrian Robert <adrian.b.robert <at> gmail.com> To: David Engster <deng <at> randomsample.de>, Chong Yidong <cyd <at> stupidchicken.com>, 5811 <at> debbugs.gnu.org Subject: Re: bug#5811: 23.1.94; Emacs Nextstep port crashes after graphical yes-or-no-p Date: Sat, 10 Apr 2010 09:11:43 +0300
[Message part 1 (text/plain, inline)]
On Apr 6, 2010, at 4:17 PM, Adrian Robert wrote:
>> Maybe you made a 32bit binary?
>>
>> When I compile with
>>
>> CC="gcc -arch i386" ./configure --with-ns
>>
>> the resulting binary does not crash on the test case. So it appears to
>> be a problem with 64bit only.
>
> Hmm, possibly. Anyway this suggests maybe it is also some sort of signature and/or argument-passing issue. The previous fix just corrected some kind misalignment problem due to the wrong size for the return type being allocated on the stack.
This is roughly what it seemed to be. Here is a patch that fixes this issue for me running 10.6.2 64-bit. (I tried to look for other problems of this sort in the source but did not find any -- though that doesn't mean they don't exist!)
-Adrian
Index: nsmenu.m
===================================================================
RCS file: /sources/emacs/emacs/src/nsmenu.m,v
retrieving revision 1.31
diff -u -p -r1.31 nsmenu.m
--- nsmenu.m 9 Nov 2009 06:21:03 -0000 1.31
+++ nsmenu.m 10 Apr 2010 06:09:44 -0000
@@ -1709,7 +1709,7 @@ void process_dialog (id window, Lisp_Obj
- (Lisp_Object)runDialogAt: (NSPoint)p
{
- int ret;
+ NSInteger ret;
extern EMACS_TIME timer_check (int do_it_now); /* TODO: add to a header */
/* initiate a session that will be ended by pop_down_menu */
[snowLeopard_dialog.patch (application/octet-stream, attachment)]
[Message part 3 (text/plain, inline)]
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:bug#5811; Package emacs,ns.
(Sat, 10 Apr 2010 15:16:02 GMT) Full text and rfc822 format available.Message #34 received at 5811 <at> debbugs.gnu.org (full text, mbox):
From: Chong Yidong <cyd <at> stupidchicken.com> To: Adrian Robert <adrian.b.robert <at> gmail.com> Cc: 5811 <at> debbugs.gnu.org, David Engster <deng <at> randomsample.de> Subject: Re: bug#5811: 23.1.94; Emacs Nextstep port crashes after graphical yes-or-no-p Date: Sat, 10 Apr 2010 11:15:21 -0400
Adrian Robert <adrian.b.robert <at> gmail.com> writes: > This is roughly what it seemed to be. Here is a patch that fixes this > issue for me running 10.6.2 64-bit. (I tried to look for other > problems of this sort in the source but did not find any -- though > that doesn't mean they don't exist!) Please go ahead and check this in. Thanks.
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:bug#5811; Package emacs,ns.
(Tue, 20 Apr 2010 08:33:01 GMT) Full text and rfc822 format available.Message #37 received at 5811 <at> debbugs.gnu.org (full text, mbox):
From: David Engster <deng <at> randomsample.de> To: Adrian Robert <adrian.b.robert <at> gmail.com> Cc: Chong Yidong <cyd <at> stupidchicken.com>, 5811 <at> debbugs.gnu.org Subject: Re: bug#5811: 23.1.94; Emacs Nextstep port crashes after graphical yes-or-no-p Date: Tue, 20 Apr 2010 10:33:16 +0200
Adrian Robert <adrian.b.robert <at> gmail.com> writes: > On Apr 6, 2010, at 4:17 PM, Adrian Robert wrote: > >>> Maybe you made a 32bit binary? >>> >>> When I compile with >>> >>> CC="gcc -arch i386" ./configure --with-ns >>> >>> the resulting binary does not crash on the test case. So it appears to >>> be a problem with 64bit only. >> >> Hmm, possibly. Anyway this suggests maybe it is also some sort of signature and/or argument-passing issue. The previous fix just corrected some kind misalignment problem due to the wrong size for the return type being allocated on the stack. > > > This is roughly what it seemed to be. Here is a patch that fixes this issue for me running 10.6.2 64-bit. (I tried to look for other problems of this sort in the source but did not find any -- though that doesn't mean they don't exist!) Sorry for the late reply. I just checked with the latest pretest (23.1.96) and the bug is gone. Thanks! -David
Chong Yidong <cyd <at> stupidchicken.com>
to control <at> debbugs.gnu.org.
(Tue, 20 Apr 2010 12:55:03 GMT) Full text and rfc822 format available.Debbugs Internal Request <help-debbugs <at> gnu.org>
to internal_control <at> debbugs.gnu.org.
(Wed, 19 May 2010 11:24:04 GMT) Full text and rfc822 format available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.