This is the mail archive of the
mailing list for the Cygwin project.
Re: /proc/*/cmdline corrupted
> 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
* 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,
either corrupted or held
for example in debuger.
I suppose that 'kernel' proc IPC (infinite timeouts) and 'user' proc IPC
(timeouts of several seconds?)
should be distinguished.
(On windows, I suppose CreateProcess (besides putting the command line in
memory space) writes the command line to a kernel table
where from taskmanager.exe queries its content forever unchanged.)
View this message in context: http://old.nabble.com/-proc-*-cmdline-corrupted-tp32639066p32665088.html
Sent from the Cygwin list mailing list archive at Nabble.com.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple