Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com
Date: Sat, 10 Jul 1999 13:31:56 -0400
From: Chris Faylor <cgf AT cygnus DOT com>
To: cygwin-developers <cygwin-developers AT sourceware DOT cygnus DOT com>
Subject: Re: 19990705 snapshot
Message-ID: <19990710133156.A1241@cygnus.com>
References: <19990708172005 DOT A3884 AT cygnus DOT com> <6840 DOT 990710 AT logos-m DOT ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.3i
In-Reply-To: <6840.990710@logos-m.ru>; from Egor Duda on Sat, Jul 10, 1999 at 08:10:34PM +0400

On Sat, Jul 10, 1999 at 08:10:34PM +0400, Egor Duda wrote:
>>>Another question: has the CYGWIN=strace=1,somefile functionality been
>>>deprecated with the advent of the strace program?
>
>CF> It hasn't been deprecated.  It has been removed.  You have to use
>CF> the strace program.
>
>I've got some problems with new strace mechanism too :( Issuing
>command
>
>strace -otrace.dump -f man man
>
>leads to some strange results.
>
>At least one thing that had to be added to strace.cc code is to make
>it handle EVENT_EXCEPTION. Sometimes stracing "man man" just freezes
>because /usr/local/bin/tbl (called by man) traps and starts to send
>EXCEPTION event to strace process over and over again.
>
>Would you consider making selection between new and old tracing scheme
>to be an option at dll build time?

strace.exe is only a few weeks old.  I don't see any reason to give
up yet because people are finding bugs.

I would like to stick with this mechanism for a few reasons:  1) It
is more UNIX-like, 2) It removes some ugly synchronization code from
the DLL, simplifying such things as signal handling, and 3) it shrinks
the size of the DLL.

>I've even built strace.exe under mingw, but results was the same. :(

Did you have to patch strace to do this?  If so, I'd be interested in
the patches.  Either way, could you tell me what you did to do this.  I
think that strace (and cygcheck for that matter) should be mingw by
default.

>Sometimes strace.exe just got killed by kernel (i've inserted debug
>printf at the exit from main cycle at proc_child, but it didn't show
>up), and groff, had been left alone and popped a dialog window that
>noone can handle his breakpoint. Can it have something to do with
>reparenting?

Thanks for the bug report.  I duplicated the problem and hopefully
the attached patch fixes it.  It was dying here because strace couldn't
read the memory from one of the child processes for some reason.  Then
when it went to report the error the error was never actually printed.
The attached patch may fix these problems.  It works for me.

I plan on improving strace in the coming months.  There are some speedups
possible and I would like to eventually be able to perform an strace on
another process.  Eventually, I would like to add the ability to
auto-strace a specific process to allow easier debugging of processes
started as services.

cgf