* Segfault in current bzr
@ 2010-09-27 19:56 Lars Magne Ingebrigtsen
2010-09-27 19:59 ` Lars Magne Ingebrigtsen
2010-09-27 20:16 ` Eli Zaretskii
0 siblings, 2 replies; 15+ messages in thread
From: Lars Magne Ingebrigtsen @ 2010-09-27 19:56 UTC (permalink / raw)
To: emacs-devel
I've now managed to kill Emacs twice. It happened while I was reading a
picture-heavy news group.
Here's what gdb said in the backtrace:
#0 0x00007ffff1e11457 in kill () from /lib/libc.so.6
#1 0x00000000004ebc25 in abort () at emacs.c:427
#2 0x00000000005a5dd9 in wait_reading_process_output (
time_limit=<value optimized out>, microsecs=<value optimized out>,
read_kbd=-1, do_display=<value optimized out>,
wait_for_cell=<value optimized out>, wait_proc=0x0, just_wait_proc=0)
at process.c:5072
#3 0x0000000000418434 in sit_for (timeout=120, reading=1, do_display=1)
at dispnew.c:6107
#4 0x00000000004fc2f9 in read_char (commandflag=<value optimized out>,
nmaps=<value optimized out>, maps=<value optimized out>,
prev_event=<value optimized out>, used_mouse_menu=<value optimized out>,
end_time=<value optimized out>) at keyboard.c:2811
#5 0x00000000004fd4d9 in read_key_sequence (keybuf=<value optimized out>,
bufsize=<value optimized out>, prompt=<value optimized out>,
dont_downcase_last=<value optimized out>,
can_return_switch_frame=<value optimized out>,
fix_current_buffer=<value optimized out>) at keyboard.c:9339
#6 0x00000000004ffa60 in command_loop_1 () at keyboard.c:1618
#7 0x000000000056280e in internal_condition_case (bfun=<value optimized out>,
handlers=<value optimized out>, hfun=<value optimized out>) at eval.c:1460
#8 0x00000000004f8b3e in command_loop_2 (ignore=<value optimized out>)
at keyboard.c:1338
#9 0x0000000000562938 in internal_catch (tag=<value optimized out>,
#10 0x00000000004f8d03 in command_loop () at keyboard.c:1317
#11 0x00000000004f90e8 in recursive_edit_1 () at keyboard.c:940
#12 0x00000000004f9227 in Frecursive_edit () at keyboard.c:1002
#13 0x00000000004ecb85 in main (argc=0, argv=0x7fffffffea68) at emacs.c:1712
Any ideas?
--
(domestic pets only, the antidote for overdose, milk.)
larsi@gnus.org * Lars Magne Ingebrigtsen
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Segfault in current bzr
2010-09-27 19:56 Segfault in current bzr Lars Magne Ingebrigtsen
@ 2010-09-27 19:59 ` Lars Magne Ingebrigtsen
2010-09-27 20:09 ` Lars Magne Ingebrigtsen
2010-09-27 20:14 ` Eli Zaretskii
2010-09-27 20:16 ` Eli Zaretskii
1 sibling, 2 replies; 15+ messages in thread
From: Lars Magne Ingebrigtsen @ 2010-09-27 19:59 UTC (permalink / raw)
To: emacs-devel
Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> #2 0x00000000005a5dd9 in wait_reading_process_output (
> time_limit=<value optimized out>, microsecs=<value optimized out>,
> read_kbd=-1, do_display=<value optimized out>,
> wait_for_cell=<value optimized out>, wait_proc=0x0, just_wait_proc=0)
> at process.c:5072
Which must be this code:
FD_CLR (channel, &connect_wait_mask);
if (--num_pending_connects < 0)
abort ();
--
(domestic pets only, the antidote for overdose, milk.)
larsi@gnus.org * Lars Magne Ingebrigtsen
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Segfault in current bzr
2010-09-27 19:59 ` Lars Magne Ingebrigtsen
@ 2010-09-27 20:09 ` Lars Magne Ingebrigtsen
2010-09-27 20:14 ` Eli Zaretskii
1 sibling, 0 replies; 15+ messages in thread
From: Lars Magne Ingebrigtsen @ 2010-09-27 20:09 UTC (permalink / raw)
To: emacs-devel
Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> Which must be this code:
>
> FD_CLR (channel, &connect_wait_mask);
> if (--num_pending_connects < 0)
> abort ();
Geez. There have been a lot of changes to process.c the past few days.
It's difficult to say which patch is to blame...
--
(domestic pets only, the antidote for overdose, milk.)
larsi@gnus.org * Lars Magne Ingebrigtsen
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Segfault in current bzr
2010-09-27 19:59 ` Lars Magne Ingebrigtsen
2010-09-27 20:09 ` Lars Magne Ingebrigtsen
@ 2010-09-27 20:14 ` Eli Zaretskii
2010-09-27 20:27 ` Lars Magne Ingebrigtsen
2010-09-27 22:29 ` David Kastrup
1 sibling, 2 replies; 15+ messages in thread
From: Eli Zaretskii @ 2010-09-27 20:14 UTC (permalink / raw)
To: Lars Magne Ingebrigtsen; +Cc: emacs-devel
> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Date: Mon, 27 Sep 2010 21:59:11 +0200
>
> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
> > #2 0x00000000005a5dd9 in wait_reading_process_output (
> > time_limit=<value optimized out>, microsecs=<value optimized out>,
> > read_kbd=-1, do_display=<value optimized out>,
> > wait_for_cell=<value optimized out>, wait_proc=0x0, just_wait_proc=0)
> > at process.c:5072
>
> Which must be this code:
>
> FD_CLR (channel, &connect_wait_mask);
> if (--num_pending_connects < 0)
> abort ();
You can't really know, in an optimized build. GCC is very good in
collapsing multiple calls to th same function into a single call.
I suggest to build with -O0, and then trying to crash. At least then
the backtrace and the line numbers won't lie. And you get to actually
see the values of the variables as a bonus, instead of all those
<value optimized out> thingies.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Segfault in current bzr
2010-09-27 19:56 Segfault in current bzr Lars Magne Ingebrigtsen
2010-09-27 19:59 ` Lars Magne Ingebrigtsen
@ 2010-09-27 20:16 ` Eli Zaretskii
1 sibling, 0 replies; 15+ messages in thread
From: Eli Zaretskii @ 2010-09-27 20:16 UTC (permalink / raw)
To: Lars Magne Ingebrigtsen; +Cc: emacs-devel
> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Date: Mon, 27 Sep 2010 21:56:49 +0200
>
> I've now managed to kill Emacs twice. It happened while I was reading a
> picture-heavy news group.
>
> Here's what gdb said in the backtrace:
>
> #0 0x00007ffff1e11457 in kill () from /lib/libc.so.6
> #1 0x00000000004ebc25 in abort () at emacs.c:427
> #2 0x00000000005a5dd9 in wait_reading_process_output (
> time_limit=<value optimized out>, microsecs=<value optimized out>,
> read_kbd=-1, do_display=<value optimized out>,
> wait_for_cell=<value optimized out>, wait_proc=0x0, just_wait_proc=0)
> at process.c:5072
> #3 0x0000000000418434 in sit_for (timeout=120, reading=1, do_display=1)
> at dispnew.c:6107
> #4 0x00000000004fc2f9 in read_char (commandflag=<value optimized out>,
> nmaps=<value optimized out>, maps=<value optimized out>,
> prev_event=<value optimized out>, used_mouse_menu=<value optimized out>,
> end_time=<value optimized out>) at keyboard.c:2811
> #5 0x00000000004fd4d9 in read_key_sequence (keybuf=<value optimized out>,
> bufsize=<value optimized out>, prompt=<value optimized out>,
> dont_downcase_last=<value optimized out>,
> can_return_switch_frame=<value optimized out>,
> fix_current_buffer=<value optimized out>) at keyboard.c:9339
> #6 0x00000000004ffa60 in command_loop_1 () at keyboard.c:1618
Looks really similar to what Thierry Volpiatto reported earlier today.
> Any ideas?
I'd suspect something in the latest changes by Jan. The last change
is the first suspect, right?
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Segfault in current bzr
2010-09-27 20:14 ` Eli Zaretskii
@ 2010-09-27 20:27 ` Lars Magne Ingebrigtsen
2010-09-27 20:37 ` Lars Magne Ingebrigtsen
2010-09-27 20:46 ` Jan Djärv
2010-09-27 22:29 ` David Kastrup
1 sibling, 2 replies; 15+ messages in thread
From: Lars Magne Ingebrigtsen @ 2010-09-27 20:27 UTC (permalink / raw)
To: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
> You can't really know, in an optimized build. GCC is very good in
> collapsing multiple calls to th same function into a single call.
Right. I've now rebuild with -O0, and I get this:
#0 abort () at emacs.c:427
#1 0x0000000000650cc4 in wait_reading_process_output (time_limit=-1,
microsecs=10000, read_kbd=0, do_display=0, wait_for_cell=12552578,
wait_proc=0x1f1c170, just_wait_proc=0) at process.c:4835
#2 0x000000000064f29b in Faccept_process_output (process=0, seconds=27929479,
millisec=40, just_this_one=12552578) at process.c:4188
#3 0x00000000005f7728 in Ffuncall (nargs=4, args=0x7fffffff9d00)
at eval.c:3000
#4 0x0000000000643dff in Fbyte_code (bytestr=22447553, vector=23031829,
maxdepth=28) at bytecode.c:679
#5 0x00000000005f7f9e in funcall_lambda (fun=23033477, nargs=1,
arg_vector=0x7fffffffa178) at eval.c:3174
#6 0x00000000005f78ad in Ffuncall (nargs=2, args=0x7fffffffa170)
at eval.c:3036
#7 0x0000000000643dff in Fbyte_code (bytestr=26821025, vector=26823445,
maxdepth=20) at bytecode.c:679
#8 0x00000000005f7f9e in funcall_lambda (fun=26823813, nargs=1,
arg_vector=0x7fffffffa5d8) at eval.c:3174
#9 0x00000000005f78ad in Ffuncall (nargs=2, args=0x7fffffffa5d0)
at eval.c:3036
#10 0x0000000000643dff in Fbyte_code (bytestr=25621713, vector=26649381,
maxdepth=24) at bytecode.c:679
#11 0x00000000005f62dd in Feval (form=26251318) at eval.c:2358
#12 0x00000000005f440f in internal_lisp_condition_case (var=13455794,
bodyform=26251318, handlers=26635814) at eval.c:1407
#13 0x0000000000644db4 in Fbyte_code (bytestr=25610161, vector=26650277,
maxdepth=32) at bytecode.c:869
#14 0x00000000005f7f9e in funcall_lambda (fun=26650853, nargs=3,
arg_vector=0x7fffffffb098) at eval.c:3174
#15 0x00000000005f78ad in Ffuncall (nargs=4, args=0x7fffffffb090)
at eval.c:3036
#16 0x0000000000643dff in Fbyte_code (bytestr=26419153, vector=26702821,
maxdepth=20) at bytecode.c:679
#17 0x00000000005f7f9e in funcall_lambda (fun=26703125, nargs=0,
arg_vector=0x7fffffffb508) at eval.c:3174
#18 0x00000000005f78ad in Ffuncall (nargs=1, args=0x7fffffffb500)
at eval.c:3036
#19 0x00000000005f6183 in Feval (form=26631350) at eval.c:2324
#20 0x00000000005f440f in internal_lisp_condition_case (var=12552578,
bodyform=26631350, handlers=26631206) at eval.c:1407
#21 0x0000000000644db4 in Fbyte_code (bytestr=25696769, vector=26664709,
maxdepth=16) at bytecode.c:869
#22 0x00000000005f62dd in Feval (form=26632934) at eval.c:2358
#23 0x00000000005f3f22 in internal_catch (tag=26381426, func=0x5f5c9a <Feval>,
arg=26632934) at eval.c:1204
#24 0x0000000000644d13 in Fbyte_code (bytestr=25674961, vector=26664901,
maxdepth=12) at bytecode.c:854
#25 0x00000000005f7f9e in funcall_lambda (fun=26665285, nargs=4,
arg_vector=0x7fffffffc258) at eval.c:3174
#26 0x00000000005f78ad in Ffuncall (nargs=5, args=0x7fffffffc250)
at eval.c:3036
#27 0x0000000000643dff in Fbyte_code (bytestr=26416897, vector=26703253,
maxdepth=20) at bytecode.c:679
#28 0x00000000005f7f9e in funcall_lambda (fun=26703509, nargs=4,
arg_vector=0x7fffffffc6b8) at eval.c:3174
#29 0x00000000005f78ad in Ffuncall (nargs=5, args=0x7fffffffc6b0)
at eval.c:3036
#30 0x0000000000643dff in Fbyte_code (bytestr=24895585, vector=25204309,
maxdepth=20) at bytecode.c:679
#31 0x00000000005f7f9e in funcall_lambda (fun=25204629, nargs=3,
arg_vector=0x7fffffffcb18) at eval.c:3174
#32 0x00000000005f78ad in Ffuncall (nargs=4, args=0x7fffffffcb10)
at eval.c:3036
#33 0x0000000000643dff in Fbyte_code (bytestr=26481233, vector=27489573,
maxdepth=24) at bytecode.c:679
#34 0x00000000005f7f9e in funcall_lambda (fun=27490389, nargs=2,
arg_vector=0x7fffffffcf78) at eval.c:3174
#35 0x00000000005f78ad in Ffuncall (nargs=3, args=0x7fffffffcf70)
at eval.c:3036
#36 0x0000000000643dff in Fbyte_code (bytestr=21560801, vector=26897077,
maxdepth=16) at bytecode.c:679
#37 0x00000000005f7f9e in funcall_lambda (fun=26897845, nargs=2,
arg_vector=0x7fffffffd3c8) at eval.c:3174
#38 0x00000000005f78ad in Ffuncall (nargs=3, args=0x7fffffffd3c0)
at eval.c:3036
#39 0x0000000000643dff in Fbyte_code (bytestr=26149281, vector=26353765,
maxdepth=16) at bytecode.c:679
#40 0x00000000005f7f9e in funcall_lambda (fun=26354197, nargs=1,
arg_vector=0x7fffffffd818) at eval.c:3174
#41 0x00000000005f78ad in Ffuncall (nargs=2, args=0x7fffffffd810)
at eval.c:3036
#42 0x0000000000643dff in Fbyte_code (bytestr=26172961, vector=26355717,
maxdepth=28) at bytecode.c:679
#43 0x00000000005f7f9e in funcall_lambda (fun=26356437, nargs=1,
arg_vector=0x7fffffffdcd8) at eval.c:3174
#44 0x00000000005f78ad in Ffuncall (nargs=2, args=0x7fffffffdcd0)
at eval.c:3036
#45 0x00000000005f1d85 in Fcall_interactively (function=24239010,
record_flag=12552578, keys=12598901) at callint.c:849
#46 0x00000000005f76f5 in Ffuncall (nargs=4, args=0x7fffffffe050)
at eval.c:2996
#47 0x00000000005f70a6 in call3 (fn=12739698, arg1=24239010, arg2=12552578,
arg3=12552578) at eval.c:2820
#48 0x000000000056a320 in Fcommand_execute (cmd=24239010,
record_flag=12552578, keys=12552578, special=12552578) at keyboard.c:10326
#49 0x0000000000558a36 in command_loop_1 () at keyboard.c:1737
#50 0x00000000005f4585 in internal_condition_case (
bfun=0x558220 <command_loop_1>, handlers=12604674,
hfun=0x557b28 <cmd_error>) at eval.c:1460
#51 0x0000000000557f21 in command_loop_2 (ignore=12552578) at keyboard.c:1338
#52 0x00000000005f3f22 in internal_catch (tag=12600738,
func=0x557efb <command_loop_2>, arg=12552578) at eval.c:1204
#53 0x0000000000557ed4 in command_loop () at keyboard.c:1317
#54 0x000000000055765f in recursive_edit_1 () at keyboard.c:940
#55 0x0000000000557812 in Frecursive_edit () at keyboard.c:1002
#56 0x0000000000555b59 in main (argc=1, argv=0x7fffffffea58) at emacs.c:1712
Lisp Backtrace:
"accept-process-output" (0xffff9d08)
"nnheader-accept-process-output" (0xffffa178)
"nntp-accept-process-output" (0xffffa5d8)
"byte-code" (0xffffa950)
"nntp-send-command-and-decode" (0xffffb098)
0x1977515 PVEC_COMPILED
"funcall" (0xffffb500)
"byte-code" (0xffffbb70)
"nntp-with-open-group-function" (0xffffc258)
"nntp-request-article" (0xffffc6b8)
"gnus-request-article" (0xffffcb18)
"gnus-request-article-this-buffer" (0xffffcf78)
"gnus-article-prepare" (0xffffd3c8)
"gnus-summary-display-article" (0xffffd818)
"gnus-summary-next-article" (0xffffdcd8)
"call-interactively" (0xffffe058)
--
(domestic pets only, the antidote for overdose, milk.)
larsi@gnus.org * Lars Magne Ingebrigtsen
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Segfault in current bzr
2010-09-27 20:27 ` Lars Magne Ingebrigtsen
@ 2010-09-27 20:37 ` Lars Magne Ingebrigtsen
2010-09-27 20:45 ` Lars Magne Ingebrigtsen
2010-09-27 20:46 ` Jan Djärv
1 sibling, 1 reply; 15+ messages in thread
From: Lars Magne Ingebrigtsen @ 2010-09-27 20:37 UTC (permalink / raw)
To: emacs-devel
Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> #1 0x0000000000650cc4 in wait_reading_process_output (time_limit=-1,
> microsecs=10000, read_kbd=0, do_display=0, wait_for_cell=12552578,
> wait_proc=0x1f1c170, just_wait_proc=0) at process.c:4835
Which is a EBADF from this, apparently:
nfds = select
#endif
(max (max_process_desc, max_input_desc) + 1,
&Available,
(check_write ? &Writeok : (SELECT_TYPE *)0),
(SELECT_TYPE *)0, &timeout);
}
I'm guessing some of the file descriptors in &Writeok (or &Available)
aren't valid.
--
(domestic pets only, the antidote for overdose, milk.)
larsi@gnus.org * Lars Magne Ingebrigtsen
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Segfault in current bzr
2010-09-27 20:37 ` Lars Magne Ingebrigtsen
@ 2010-09-27 20:45 ` Lars Magne Ingebrigtsen
0 siblings, 0 replies; 15+ messages in thread
From: Lars Magne Ingebrigtsen @ 2010-09-27 20:45 UTC (permalink / raw)
To: emacs-devel
Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> #1 0x0000000000650cc4 in wait_reading_process_output (time_limit=-1,
>> microsecs=10000, read_kbd=0, do_display=0, wait_for_cell=12552578,
>> wait_proc=0x1f1c170, just_wait_proc=0) at process.c:4835
>
> Which is a EBADF from this, apparently:
>
> nfds = select
> #endif
> (max (max_process_desc, max_input_desc) + 1,
> &Available,
> (check_write ? &Writeok : (SELECT_TYPE *)0),
> (SELECT_TYPE *)0, &timeout);
> }
If I
#define SELECT_CANT_DO_WRITE_MASK
which means that check_write is 0, then Emacs doesn't abort.
So that's where the bug lies...
--
(domestic pets only, the antidote for overdose, milk.)
larsi@gnus.org * Lars Magne Ingebrigtsen
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Segfault in current bzr
2010-09-27 20:27 ` Lars Magne Ingebrigtsen
2010-09-27 20:37 ` Lars Magne Ingebrigtsen
@ 2010-09-27 20:46 ` Jan Djärv
2010-09-27 20:54 ` Lars Magne Ingebrigtsen
1 sibling, 1 reply; 15+ messages in thread
From: Jan Djärv @ 2010-09-27 20:46 UTC (permalink / raw)
To: emacs-devel
My bad, there was an FD_CLR missing. Should be OK now.
BTW, don't say segfault when there is an abort. They are two different
classes of errors.
Jan D.
Lars Magne Ingebrigtsen skrev 2010-09-27 22.27:
> Eli Zaretskii<eliz@gnu.org> writes:
>
>> You can't really know, in an optimized build. GCC is very good in
>> collapsing multiple calls to th same function into a single call.
>
> Right. I've now rebuild with -O0, and I get this:
>
> #0 abort () at emacs.c:427
> #1 0x0000000000650cc4 in wait_reading_process_output (time_limit=-1,
> microsecs=10000, read_kbd=0, do_display=0, wait_for_cell=12552578,
> wait_proc=0x1f1c170, just_wait_proc=0) at process.c:4835
> #2 0x000000000064f29b in Faccept_process_output (process=0, seconds=27929479,
> millisec=40, just_this_one=12552578) at process.c:4188
> #3 0x00000000005f7728 in Ffuncall (nargs=4, args=0x7fffffff9d00)
> at eval.c:3000
> #4 0x0000000000643dff in Fbyte_code (bytestr=22447553, vector=23031829,
> maxdepth=28) at bytecode.c:679
> #5 0x00000000005f7f9e in funcall_lambda (fun=23033477, nargs=1,
> arg_vector=0x7fffffffa178) at eval.c:3174
> #6 0x00000000005f78ad in Ffuncall (nargs=2, args=0x7fffffffa170)
> at eval.c:3036
> #7 0x0000000000643dff in Fbyte_code (bytestr=26821025, vector=26823445,
> maxdepth=20) at bytecode.c:679
> #8 0x00000000005f7f9e in funcall_lambda (fun=26823813, nargs=1,
> arg_vector=0x7fffffffa5d8) at eval.c:3174
> #9 0x00000000005f78ad in Ffuncall (nargs=2, args=0x7fffffffa5d0)
> at eval.c:3036
> #10 0x0000000000643dff in Fbyte_code (bytestr=25621713, vector=26649381,
> maxdepth=24) at bytecode.c:679
> #11 0x00000000005f62dd in Feval (form=26251318) at eval.c:2358
> #12 0x00000000005f440f in internal_lisp_condition_case (var=13455794,
> bodyform=26251318, handlers=26635814) at eval.c:1407
> #13 0x0000000000644db4 in Fbyte_code (bytestr=25610161, vector=26650277,
> maxdepth=32) at bytecode.c:869
> #14 0x00000000005f7f9e in funcall_lambda (fun=26650853, nargs=3,
> arg_vector=0x7fffffffb098) at eval.c:3174
> #15 0x00000000005f78ad in Ffuncall (nargs=4, args=0x7fffffffb090)
> at eval.c:3036
> #16 0x0000000000643dff in Fbyte_code (bytestr=26419153, vector=26702821,
> maxdepth=20) at bytecode.c:679
> #17 0x00000000005f7f9e in funcall_lambda (fun=26703125, nargs=0,
> arg_vector=0x7fffffffb508) at eval.c:3174
> #18 0x00000000005f78ad in Ffuncall (nargs=1, args=0x7fffffffb500)
> at eval.c:3036
> #19 0x00000000005f6183 in Feval (form=26631350) at eval.c:2324
> #20 0x00000000005f440f in internal_lisp_condition_case (var=12552578,
> bodyform=26631350, handlers=26631206) at eval.c:1407
> #21 0x0000000000644db4 in Fbyte_code (bytestr=25696769, vector=26664709,
> maxdepth=16) at bytecode.c:869
> #22 0x00000000005f62dd in Feval (form=26632934) at eval.c:2358
> #23 0x00000000005f3f22 in internal_catch (tag=26381426, func=0x5f5c9a<Feval>,
> arg=26632934) at eval.c:1204
> #24 0x0000000000644d13 in Fbyte_code (bytestr=25674961, vector=26664901,
> maxdepth=12) at bytecode.c:854
> #25 0x00000000005f7f9e in funcall_lambda (fun=26665285, nargs=4,
> arg_vector=0x7fffffffc258) at eval.c:3174
> #26 0x00000000005f78ad in Ffuncall (nargs=5, args=0x7fffffffc250)
> at eval.c:3036
> #27 0x0000000000643dff in Fbyte_code (bytestr=26416897, vector=26703253,
> maxdepth=20) at bytecode.c:679
> #28 0x00000000005f7f9e in funcall_lambda (fun=26703509, nargs=4,
> arg_vector=0x7fffffffc6b8) at eval.c:3174
> #29 0x00000000005f78ad in Ffuncall (nargs=5, args=0x7fffffffc6b0)
> at eval.c:3036
> #30 0x0000000000643dff in Fbyte_code (bytestr=24895585, vector=25204309,
> maxdepth=20) at bytecode.c:679
> #31 0x00000000005f7f9e in funcall_lambda (fun=25204629, nargs=3,
> arg_vector=0x7fffffffcb18) at eval.c:3174
> #32 0x00000000005f78ad in Ffuncall (nargs=4, args=0x7fffffffcb10)
> at eval.c:3036
> #33 0x0000000000643dff in Fbyte_code (bytestr=26481233, vector=27489573,
> maxdepth=24) at bytecode.c:679
> #34 0x00000000005f7f9e in funcall_lambda (fun=27490389, nargs=2,
> arg_vector=0x7fffffffcf78) at eval.c:3174
> #35 0x00000000005f78ad in Ffuncall (nargs=3, args=0x7fffffffcf70)
> at eval.c:3036
> #36 0x0000000000643dff in Fbyte_code (bytestr=21560801, vector=26897077,
> maxdepth=16) at bytecode.c:679
> #37 0x00000000005f7f9e in funcall_lambda (fun=26897845, nargs=2,
> arg_vector=0x7fffffffd3c8) at eval.c:3174
> #38 0x00000000005f78ad in Ffuncall (nargs=3, args=0x7fffffffd3c0)
> at eval.c:3036
> #39 0x0000000000643dff in Fbyte_code (bytestr=26149281, vector=26353765,
> maxdepth=16) at bytecode.c:679
> #40 0x00000000005f7f9e in funcall_lambda (fun=26354197, nargs=1,
> arg_vector=0x7fffffffd818) at eval.c:3174
> #41 0x00000000005f78ad in Ffuncall (nargs=2, args=0x7fffffffd810)
> at eval.c:3036
> #42 0x0000000000643dff in Fbyte_code (bytestr=26172961, vector=26355717,
> maxdepth=28) at bytecode.c:679
> #43 0x00000000005f7f9e in funcall_lambda (fun=26356437, nargs=1,
> arg_vector=0x7fffffffdcd8) at eval.c:3174
> #44 0x00000000005f78ad in Ffuncall (nargs=2, args=0x7fffffffdcd0)
> at eval.c:3036
> #45 0x00000000005f1d85 in Fcall_interactively (function=24239010,
> record_flag=12552578, keys=12598901) at callint.c:849
> #46 0x00000000005f76f5 in Ffuncall (nargs=4, args=0x7fffffffe050)
> at eval.c:2996
> #47 0x00000000005f70a6 in call3 (fn=12739698, arg1=24239010, arg2=12552578,
> arg3=12552578) at eval.c:2820
> #48 0x000000000056a320 in Fcommand_execute (cmd=24239010,
> record_flag=12552578, keys=12552578, special=12552578) at keyboard.c:10326
> #49 0x0000000000558a36 in command_loop_1 () at keyboard.c:1737
> #50 0x00000000005f4585 in internal_condition_case (
> bfun=0x558220<command_loop_1>, handlers=12604674,
> hfun=0x557b28<cmd_error>) at eval.c:1460
> #51 0x0000000000557f21 in command_loop_2 (ignore=12552578) at keyboard.c:1338
> #52 0x00000000005f3f22 in internal_catch (tag=12600738,
> func=0x557efb<command_loop_2>, arg=12552578) at eval.c:1204
> #53 0x0000000000557ed4 in command_loop () at keyboard.c:1317
> #54 0x000000000055765f in recursive_edit_1 () at keyboard.c:940
> #55 0x0000000000557812 in Frecursive_edit () at keyboard.c:1002
> #56 0x0000000000555b59 in main (argc=1, argv=0x7fffffffea58) at emacs.c:1712
>
> Lisp Backtrace:
> "accept-process-output" (0xffff9d08)
> "nnheader-accept-process-output" (0xffffa178)
> "nntp-accept-process-output" (0xffffa5d8)
> "byte-code" (0xffffa950)
> "nntp-send-command-and-decode" (0xffffb098)
> 0x1977515 PVEC_COMPILED
> "funcall" (0xffffb500)
> "byte-code" (0xffffbb70)
> "nntp-with-open-group-function" (0xffffc258)
> "nntp-request-article" (0xffffc6b8)
> "gnus-request-article" (0xffffcb18)
> "gnus-request-article-this-buffer" (0xffffcf78)
> "gnus-article-prepare" (0xffffd3c8)
> "gnus-summary-display-article" (0xffffd818)
> "gnus-summary-next-article" (0xffffdcd8)
> "call-interactively" (0xffffe058)
>
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Segfault in current bzr
2010-09-27 20:46 ` Jan Djärv
@ 2010-09-27 20:54 ` Lars Magne Ingebrigtsen
0 siblings, 0 replies; 15+ messages in thread
From: Lars Magne Ingebrigtsen @ 2010-09-27 20:54 UTC (permalink / raw)
To: emacs-devel
Jan Djärv <jan.h.d@swipnet.se> writes:
> My bad, there was an FD_CLR missing. Should be OK now.
Yup; works fine now.
--
(domestic pets only, the antidote for overdose, milk.)
larsi@gnus.org * Lars Magne Ingebrigtsen
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Segfault in current bzr
2010-09-27 20:14 ` Eli Zaretskii
2010-09-27 20:27 ` Lars Magne Ingebrigtsen
@ 2010-09-27 22:29 ` David Kastrup
1 sibling, 0 replies; 15+ messages in thread
From: David Kastrup @ 2010-09-27 22:29 UTC (permalink / raw)
To: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
>> Date: Mon, 27 Sep 2010 21:59:11 +0200
>>
>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>>
>> > #2 0x00000000005a5dd9 in wait_reading_process_output (
>> > time_limit=<value optimized out>, microsecs=<value optimized out>,
>> > read_kbd=-1, do_display=<value optimized out>,
>> > wait_for_cell=<value optimized out>, wait_proc=0x0, just_wait_proc=0)
>> > at process.c:5072
>>
>> Which must be this code:
>>
>> FD_CLR (channel, &connect_wait_mask);
>> if (--num_pending_connects < 0)
>> abort ();
>
> You can't really know, in an optimized build. GCC is very good in
> collapsing multiple calls to th same function into a single call.
At least that can be avoided without letting go of optimization:
cf. C-h C-d
** When you are trying to analyze failed assertions, it will be
essential to compile Emacs either completely without optimizations or
at least (when using GCC) with the -fno-crossjumping option. Failure
to do so may make the compiler recycle the same abort call for all
assertions in a given function, rendering the stack backtrace useless
for identifying the specific failed assertion.
> I suggest to build with -O0, and then trying to crash. At least then
> the backtrace and the line numbers won't lie. And you get to actually
> see the values of the variables as a bonus, instead of all those
> <value optimized out> thingies.
With -ggdb you should be getting pretty good information. Execution
will not necessarily be in-order, but gdb will have a pretty good clue
where the values can be found when optimized away from their dedicated
stack frame location.
--
David Kastrup
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Segfault in current bzr
@ 2010-09-28 11:10 grischka
2010-09-28 16:07 ` Eli Zaretskii
0 siblings, 1 reply; 15+ messages in thread
From: grischka @ 2010-09-28 11:10 UTC (permalink / raw)
To: dak; +Cc: emacs-devel
> At least that can be avoided without letting go of optimization:
> cf. C-h C-d
>
> ** When you are trying to analyze failed assertions, it will be
> essential to compile Emacs either completely without optimizations or
> at least (when using GCC) with the -fno-crossjumping option. Failure
> to do so may make the compiler recycle the same abort call for all
> assertions in a given function, rendering the stack backtrace useless
> for identifying the specific failed assertion.
Typically emacs: They're rather able to give people a lecture about
gcc options than to add a simple one-line wrapper for abort to print
the file:linenumber.
--- grischka
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Segfault in current bzr
2010-09-28 11:10 grischka
@ 2010-09-28 16:07 ` Eli Zaretskii
2010-09-28 17:19 ` grischka
0 siblings, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2010-09-28 16:07 UTC (permalink / raw)
To: grischka; +Cc: dak, emacs-devel
> Date: Tue, 28 Sep 2010 13:10:23 +0200
> From: grischka <grishka@gmx.de>
> Cc: emacs-devel@gnu.org
>
> Typically emacs: They're rather able to give people a lecture about
> gcc options than to add a simple one-line wrapper for abort to print
> the file:linenumber.
Aha, and then we will see something like this:
#1 0x00000000004ebc25 in abort () at emacs.c:427
#2 0x00000000deadbeef in abort_wrapper (file=<value optimized out>,
line=<value optimized out>) at grishka.c:1234
#3 0x00000000005a5dd9 in wait_reading_process_output (
time_limit=<value optimized out>, microsecs=<value optimized out>,
read_kbd=-1, do_display=<value optimized out>,
wait_for_cell=<value optimized out>, wait_proc=0x0, just_wait_proc=0)
at process.c:5072
(gdb) frame 2
#2 0x000000000045babe in abort_wrapper (file=<value optimized out>,
line=<value optimized out>) at grishka.c:1234
(gdb) print file
No symbol "file" in current context.
(gdb) print line
No symbol "line" in current context.
(gdb)
Very useful, very informative.
Debugging an optimized build is practically impossible, with current
versions of GCC. End of story.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Segfault in current bzr
2010-09-28 16:07 ` Eli Zaretskii
@ 2010-09-28 17:19 ` grischka
2010-09-28 17:30 ` Eli Zaretskii
0 siblings, 1 reply; 15+ messages in thread
From: grischka @ 2010-09-28 17:19 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: dak, emacs-devel
Eli Zaretskii wrote:
>> Date: Tue, 28 Sep 2010 13:10:23 +0200
>> From: grischka <grishka@gmx.de>
>> Cc: emacs-devel@gnu.org
>>
>> Typically emacs: They're rather able to give people a lecture about
>> gcc options than to add a simple one-line wrapper for abort to print
>> the file:linenumber.
>
> Aha, and then we will see something like this:
>
> #1 0x00000000004ebc25 in abort () at emacs.c:427
> #2 0x00000000deadbeef in abort_wrapper (file=<value optimized out>,
> line=<value optimized out>) at grishka.c:1234
> #3 0x00000000005a5dd9 in wait_reading_process_output (
> time_limit=<value optimized out>, microsecs=<value optimized out>,
> read_kbd=-1, do_display=<value optimized out>,
> wait_for_cell=<value optimized out>, wait_proc=0x0, just_wait_proc=0)
> at process.c:5072
No, you'd see:
emax: internal error at process.c:5072. Aborting.
Which while you just started to preach the user how to use gcc and gdb
might very well suffice for someone else to be done with the problem
already.
--- grischka
>
> (gdb) frame 2
> #2 0x000000000045babe in abort_wrapper (file=<value optimized out>,
> line=<value optimized out>) at grishka.c:1234
> (gdb) print file
> No symbol "file" in current context.
> (gdb) print line
> No symbol "line" in current context.
> (gdb)
>
> Very useful, very informative.
>
> Debugging an optimized build is practically impossible, with current
> versions of GCC. End of story.
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Segfault in current bzr
2010-09-28 17:19 ` grischka
@ 2010-09-28 17:30 ` Eli Zaretskii
0 siblings, 0 replies; 15+ messages in thread
From: Eli Zaretskii @ 2010-09-28 17:30 UTC (permalink / raw)
To: grischka; +Cc: dak, emacs-devel
> Date: Tue, 28 Sep 2010 19:19:14 +0200
> From: grischka <grishka@gmx.de>
> CC: dak@gnu.org, emacs-devel@gnu.org
>
> No, you'd see:
> emax: internal error at process.c:5072. Aborting.
_If_ stderr is connected to something other than /dev/null, and _if_
that something is visible, and _if_ this is on Unix, and _if_...
And how will this help when the user reports a backtrace from a core
file?
Useless.
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2010-09-28 17:30 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-09-27 19:56 Segfault in current bzr Lars Magne Ingebrigtsen
2010-09-27 19:59 ` Lars Magne Ingebrigtsen
2010-09-27 20:09 ` Lars Magne Ingebrigtsen
2010-09-27 20:14 ` Eli Zaretskii
2010-09-27 20:27 ` Lars Magne Ingebrigtsen
2010-09-27 20:37 ` Lars Magne Ingebrigtsen
2010-09-27 20:45 ` Lars Magne Ingebrigtsen
2010-09-27 20:46 ` Jan Djärv
2010-09-27 20:54 ` Lars Magne Ingebrigtsen
2010-09-27 22:29 ` David Kastrup
2010-09-27 20:16 ` Eli Zaretskii
-- strict thread matches above, loose matches on Subject: below --
2010-09-28 11:10 grischka
2010-09-28 16:07 ` Eli Zaretskii
2010-09-28 17:19 ` grischka
2010-09-28 17:30 ` Eli Zaretskii
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.