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: Process command lines for Cygwin processes no longer viewable in Windows task manager as of Cygwin 1.7.21

On 07/25/2013 11:10 AM, Christopher Faylor wrote:
On Thu, Jul 25, 2013 at 10:19:16AM -0400, Tom Honermann wrote:
On 07/25/2013 09:21 AM, Charles Wilson wrote:
On 7/25/2013 4:28 AM, Corinna Vinschen wrote:
On Jul 24 22:38, Tom Honermann wrote:
My suspicion that this started with 1.7.21 is based on Corinna's
comments in and
other anecdotal evidence of new problems occurring as of that

This is by design now as described in the aforementioned posting.  If
you want to see the command line of a Cygwin application called by
another Cygwin application, see /proc/$pid/cmdline.

Would a patch to restore the previous operation based on a $CYGWIN
variable setting be acceptable?

I think this change should be reverted.

You were relying on a bug in Cygwin.

Regardless if this behavior was intentional or not, the ability to retrieve the process command line from non-Cygwin processes is crucial for me. Please work with me on this to come up with a solution.

Older versions of the DLL did not
provide the full command line.  It was only after the bug entered into
the source code that it did.  Not providing the windows command line is
an optimization for Cygwin programs.

As far as I can tell, the command line has been provided to CreateProcess going back at least as far as the Cygwin 1.5.x releases.

Given the cost of starting a new process, it seems unlikely that omitting the full command line offers much of a performance improvement. Was there something about the construction of the command line that was particularly expensive? Perhaps that could be optimized instead?

In my case, I need to be able to retrieve the command line for a Cygwin
process from a non-Cygwin process.  Reading /proc/$pid/cmdline is not an
option in that case.  I depend on the ability to, for example,
differentiate gcc processes that are running based on their command line

Note that strace is currently broken as well.  Running it against a
'make' invocation:

It's not strace that's broken.  That's just a simple fix to the DLL.

Ok, the user experience is that strace is not working as expected.


Problem reports:
Unsubscribe info:

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