Segfault in current bzr

Segfault in current bzr

[Lars Magne Ingebrigtsen]

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

Re: Segfault in current bzr

[Lars Magne Ingebrigtsen]

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

Re: Segfault in current bzr

[Lars Magne Ingebrigtsen]

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

Re: Segfault in current bzr

[Eli Zaretskii]

> 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.

Re: Segfault in current bzr

[Lars Magne Ingebrigtsen]

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

Re: Segfault in current bzr

[Lars Magne Ingebrigtsen]

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

Re: Segfault in current bzr

[Lars Magne Ingebrigtsen]

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

Re: Segfault in current bzr

[Jan Djärv]

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)
>
>

Re: Segfault in current bzr

[Lars Magne Ingebrigtsen]

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

Re: Segfault in current bzr

[David Kastrup]

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

Re: Segfault in current bzr

[Eli Zaretskii]

> 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?

Re: Segfault in current bzr

[grischka]

 > 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

Re: Segfault in current bzr

[Eli Zaretskii]

> 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.

Re: Segfault in current bzr

[grischka]

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.
> 

Re: Segfault in current bzr

[Eli Zaretskii]

> 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.