Re: Segfault in current bzr

[David Kastrup <dak@gnu.org>]

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