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: /proc/*/cmdline corrupted

On Oct 17 00:41, jan.kolar wrote:
> defaria wrote:
> > 
> > Why wouldn't exec(1) be responsible for setting up /proc and therefore 
> > fill in cmdline with effectively $0 *before* the program itself ever got 
> > around to calling XrmParseCommand? (I'm not well versed in the 
> > underlying mechanics here and I have not reviewed the code but I would 
> > have thought that something like exec would have examined argv/argc 
> > before the program was ever able to modify it).
> > 
> The command line is in the memory space of the process.
> Exec does set it at the beginning but the program can change it.
> On ancient unix, program 'ps' was looking in the memory of each process
> (and therefore it was running setuid root).
> On modern unix, kernel provides /proc filesystem whose implementation 
> is looking into (I suppose) the memory of each process.
> On cygwin, the library cygwin1.dll (it is 2011 this year) provides
> filesystem, whose implementation
> asks each other cygwin process about content of command line.
> In the process, a separate thread created by cygwin1.dll assemblies the
> answer.
> * Might be, it would be reasonable to set a suitable timeoutsfor IPC
> connected to /proc
>    so that programs likes procps (I do not know about ps) will not get stack
>    instead of reporting problem, when there is non-responding process,

In CVS the /proc communication pipe has a timeout value of 0.5 secs


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Problem reports:
Unsubscribe info:

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