This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Mysterious random crashes with latest snapshots


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

> On Thu, 30 Jun 2005, 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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]