Mysterious random crashes with latest snapshots

Thu Jun 30 15:22:00 GMT 2005

----Original Message----
>From: Igor Pechtchanski
>Sent: 30 June 2005 15:18

> On 2005年6月30日, Dave Korn wrote:
>>> ----Original Message----
>>> From: Igor Pechtchanski
>>> Sent: 30 June 2005 05:51

>>> I know this isn't much of a bug report,
>>>> I should drop a hippo on you!
>> I'll take a hippo over these crashes any day. Or are you saying this is
> TITTTL fodder?

 Well, do you *hear* any chickens? Huh? Do ya? Do ya?
 No?
 Then I must not be saying so!
>> Oh, not so kewl! No source!
>> Heh, of course -- this is a snapshot we're talking about. It *should*
> refer to the filenames in the builder's build tree. I have a local CVS
> copy -- the mapping isn't *that* convoluted...
>>>> BTW, for some reason addr2line only decodes the first address:
>> Any ideas on that? Is this a bug in addr2line? After all, gdb does find
> the source info for the second stack entry as well. It doesn't look like
> it's coming from another DLL. Also, any ideas why the gdb stack is
> screwed up?

 I think I remember noticing that backtracing across sigfe doesn't always
work too well. Then again, there could be a problem with the debug info:
>#3 0x00435d27 in fhandler_pipe::get_guard ()

makes no sense. But I would imagine the peculiarity is down to sigfe; it
does something unexpected to the stack frame, that the debug info doesn't
reflect.
> In case you haven't noticed, I'm running a snapshot, which, IIUC, *is* a
> debug build. And that doesn't help much, as you can see.

 Debug yes; unoptimised, I think not, although we'd need cgf or cv to
confirm how the snapshot process works.
> On second thought, do you mean actually compiling with --enable-debugging?
> Does this produce extra debug information, or is it just about better
> traces and being able to run alongside other Cygwin versions?

 I don't know what --enable-debugging does myself, never having used it.
What I'm saying is that you really have to build the dll yourself. The
snapshots are probably built with the standard -O2 setting. (I don't ever
expect debugging to work when I start moving executables around; I build and
debug on the same machine with all my source and binaries in one place.)
> Ah, now that makes sense. Though inline functions from headers will still
> be inlined, IIUC, and this is what we're looking at here.

 I think the operator-> isn't the real source of the problem... it's what
leads up to it.
>> something like
>>>> NEWLIB_CFLAGS='-g -O0 -DHAVE_OPENDIR -DHAVE_RENAME -DSIGNAL_PROVIDED
>> -D_COMPILING_NEWLIB -DHAVE_FCNTL -DMALLOC_PROVIDED -fno-builtin' 
>>>> although to be really certain I'd say after configuring look in
>> $objdir/i686-pc-cygwin/newlib/Makefile for the existing value and modify
>> that.
>> Hopefully it won't come to that.

 Yeh, I really just mention that one for the archives. I had to figure it
out for myself the other day.
 cheers,
 DaveK
-- 
Can't think of a witty .sigline today....
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/