This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
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