This is the mail archive of the cygwin-developers@cygwin.com 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]

Silent "deaths" & cvs cygwin1.dll (was Re: [f]statvfs)


On Thu, 4 Dec 2003, Christopher Faylor wrote:
> On Thu, Dec 04, 2003 at 03:17:37PM -0600, Brian Ford wrote:
> >On Thu, 4 Dec 2003, Christopher Faylor wrote:
> >> On Thu, Dec 04, 2003 at 12:52:31PM -0600, Brian Ford wrote:
> >>>PS. I'm still seeing random silent "deaths" with the current cvs
> >>>cygwin1.dll.  Long configure scripts randomly stop in the middle.
> >>>Re-running them, they might complete, or they might stop in a different
> >>>spot.  Even configuring/compiling Cygwin again is then a hit and miss
> >>>proposition.  Does anyone else see this or have an idea how to debug it?
> >>>
> >>set CYGWIN=error_start=x:\path\gdb
> >>
> >>I doubt that they are just silent exits.
> >>
[snip silent exit example]
> >Did I miss something, or what next?
>
> If I was doing this, I'd 1) make sure that error_start was working
> correctly, 2) run it under strace, or 3) run the configure shell under
> gdb.
>
1.) error_start mostly works.  A test app that dereferences a NULL
pointer causes gdb to spawn, but it can not attach successfully.  It
appears gdb is getting only a pid as its argument, and gdb assumes that is
a file in the current directory.  This is not a request for action, just a
comment.

That asside, error_start is not triggered by the "silent death".

2.) I thought the strace output would be huge and difficult to parse given
the magnitude of the problem (large configure script/make).  On my puny
machine, strace takes eons per configure test.  This is not practical.

3.) Running the shell inside of gdb showed the process died with exit
status 0200.

> However, I really don't want to get involved in a "now try this" type of
> exercise.  If I have to do all of the thinking for a debugging session I
> might as well try to duplicate the problem myself and debug it myself.
>
Fine.  Sometimes I need a little help, or a push to get started.  Usually,
thinking on your part is only required in the tough spots.  This was not a
well defined problem, so I didn't know where to start.  Sorry.

But, this was really more of a heads up with an offer to help.  I'd rather
have you debug it anyway (assuming you will... eventually).

I'll look further when I have more time or ideas if I haven't heard about
a fix yet.

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444


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