* /proc/*/cmdline corrupted
@ 2011-10-12 15:08 Jon Clugston
2011-10-13 12:56 ` jan.kolar
` (2 more replies)
0 siblings, 3 replies; 17+ messages in thread
From: Jon Clugston @ 2011-10-12 15:08 UTC (permalink / raw)
To: cygwin
[-- Attachment #1: Type: text/plain, Size: 1252 bytes --]
Greetings,
When I run "procps -ef" I get corrupted command line parameters:
jc807j@~>procps -ef
UID PID PPID C STIME TTY TIME CMD
jc807j 5852 1 0 08:59 tty0 00:00:03 X :0 -multiwindow
jc807j 2668 1 0 08:59 tty0 00:00:00 xterm -e ssh server
80x72+285+0 -e ssh server
jc807j 3004 1 0 08:59 tty0 00:00:00 xterm -e ssh server
80x72-8+0 -e ssh server
jc807j 3392 3004 0 08:59 tty0 00:00:00 ssh server
jc807j 5960 2668 0 08:59 tty1 00:00:00 ssh server
jc807j 2928 5852 0 09:12 ? 00:00:00 xterm 20000 +tb
jc807j 4608 2928 0 09:12 tty2 00:00:00 bash
jc807j 5800 4608 1 10:57 tty2 00:00:00 procps -ef
The actual command lines for the 3 xterm processes are:
C:\cygwin\bin\xterm.exe -sl 20000 +tb -geometry 80x72+285+0 -e ssh server
C:\cygwin\bin\xterm.exe -sl 20000 +tb -geometry 80x72-8+0 -e ssh server
C:\cygwin\bin\xterm.exe -sl 20000 +tb
as reported by the "listdlls" tool.
I have verified that the "/proc/*/cmdline" is the source of the
corrupted information. "cmdline" from PID 2928 is:
jc807j@~>od -c /proc/2928/cmdline
0000000 x t e r m \0 \0 2 0 0 0 0 \0 + t b
0000020 \0
0000021
[-- Attachment #2: cygcheck.out --]
[-- Type: text/plain, Size: 30039 bytes --]
Cygwin Configuration Diagnostics
Current System Time: Wed Oct 12 10:47:48 2011
Windows 7 Professional N Ver 6.1 Build 7600
Path: C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\Windows\system32
C:\Windows
C:\Windows\System32\Wbem
C:\Windows\System32\WindowsPowerShell\v1.0
C:\Program Files\Enterprise Vault\EVClient
C:\Program Files\ATI Technologies\ATI.ACE\Core-Static
Output from C:\cygwin\bin\id.exe
UID: 3091510(jc807j) GID: 10513(domusers)
10513(domusers) 545(Users)
SysDir: C:\Windows\system32
WinDir: C:\Windows
USER = 'jc807j'
PWD = '/home/jc807j'
HOME = '/home/jc807j'
HOMEPATH = '\Users\jc807j'
MANPATH = '/usr/local/man:/usr/share/man:/usr/man:'
APPDATA = 'C:\Users\jc807j\AppData\Roaming'
HOSTNAME = 'MDCDTD01JC807J'
SHELL = '/bin/bash'
TERM = 'xterm'
PROCESSOR_IDENTIFIER = 'x86 Family 16 Model 6 Stepping 3, AuthenticAMD'
WINDIR = 'C:\Windows'
WINDOWID = '12582942'
PUBLIC = 'C:\Users\Public'
USERDOMAIN = 'ITSERVICES'
UATDATA = 'C:\Windows\system32\CCM\UATData\D9F8C395-CAB8-491d-B8AC-179A1FE1BE77'
OS = 'Windows_NT'
ALLUSERSPROFILE = 'C:\ProgramData'
XTERM_SHELL = '/bin/bash'
TEMP = '/tmp'
DEFLOGDIR = 'C:\ProgramData\McAfee\DesktopProtection'
COMMONPROGRAMFILES = 'C:\Program Files\Common Files'
USERNAME = 'JC807J'
PROCESSOR_LEVEL = '16'
PSModulePath = 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\'
%FavoritesDir% = 'C:\Users\jc807j\Favorites'
XWINLOGFILE = '/var/log/xwin/XWin.0.log'
DRU_APP_DIR = 'C:\Program Files\DRU'
FP_NO_HOST_CHECK = 'NO'
SYSTEMDRIVE = 'C:'
LANG = 'C.UTF-8'
USERPROFILE = 'C:\Users\jc807j'
LOGONSERVER = '\\GAALPA1ADSSRV91'
DRU_BIN_DIR = 'C:\Program Files\DRU\BIN'
PROCESSOR_ARCHITECTURE = 'x86'
LOCALAPPDATA = 'C:\Users\jc807j\AppData\Local'
XTERM_LOCALE = 'C.UTF-8'
XTERM_VERSION = 'XTerm(276)'
ProgramData = 'C:\ProgramData'
SHLVL = '3'
USERDNSDOMAIN = 'ITSERVICES.SBC.COM'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC'
HOMEDRIVE = 'C:'
COMSPEC = 'C:\Windows\system32\cmd.exe'
LOGNAME = 'jc807j'
TMP = '/tmp'
SYSTEMROOT = 'C:\Windows'
PRINTER = 'AT&T PDF Writer'
PROCESSOR_REVISION = '0603'
INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:'
PROGRAMFILES = 'C:\Program Files'
DISPLAY = ':0.0'
NUMBER_OF_PROCESSORS = '2'
VSEDEFLOGDIR = 'C:\ProgramData\McAfee\DesktopProtection'
SESSIONNAME = 'Console'
COMPUTERNAME = 'MDCDTD01JC807J'
_ = '/usr/bin/cygcheck'
OLDPWD = '/proc/2668'
HKEY_CURRENT_USER\Software\Cygwin
HKEY_CURRENT_USER\Software\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Cygwin\setup
(default) = 'C:\cygwin'
HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE\Cygwin
HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE\Cygwin\Installations
(default) = '\??\C:\cygwin'
HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE\Cygwin\setup
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Installations
(default) = '\??\C:\cygwin'
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup
obcaseinsensitive set to 1
Cygwin installations found in the registry:
System: Key: c5e39b7a9d22bafb Path: C:\cygwin
c: hd NTFS 152624Mb 19% CP CS UN PA FC SYSTEM
d: cd N/A N/A
C:\cygwin / system binary,auto
C:\cygwin\bin /usr/bin system binary,auto
C:\cygwin\lib /usr/lib system binary,auto
cygdrive prefix /cygdrive user binary,auto
Found: C:\cygwin\bin\awk
-> C:\cygwin\bin\gawk.exe
Found: C:\cygwin\bin\bash.exe
Found: C:\cygwin\bin\cat.exe
Found: C:\cygwin\bin\cp.exe
Found: C:\cygwin\bin\cpp.exe
-> C:\cygwin\etc\alternatives\cpp
-> C:\cygwin\bin\cpp-4.exe
Found: C:\cygwin\bin\crontab.exe
Found: C:\cygwin\bin\find.exe
Found: C:\Windows\system32\find.exe
Warning: C:\cygwin\bin\find.exe hides C:\Windows\system32\find.exe
Found: C:\cygwin\bin\gcc.exe
-> C:\cygwin\etc\alternatives\gcc
-> C:\cygwin\bin\gcc-4.exe
Found: C:\cygwin\bin\gdb.exe
Found: C:\cygwin\bin\grep.exe
Found: C:\cygwin\bin\kill.exe
Found: C:\cygwin\bin\ld.exe
Found: C:\cygwin\bin\ls.exe
Found: C:\cygwin\bin\make.exe
Found: C:\cygwin\bin\mv.exe
Found: C:\cygwin\bin\patch.exe
Found: C:\cygwin\bin\perl.exe
Found: C:\cygwin\bin\rm.exe
Found: C:\cygwin\bin\sed.exe
Found: C:\cygwin\bin\ssh.exe
Found: C:\cygwin\bin\sh.exe
Found: C:\cygwin\bin\tar.exe
Found: C:\cygwin\bin\test.exe
Found: C:\cygwin\bin\vi
-> C:\cygwin\bin\vim-nox.exe
Found: C:\cygwin\bin\vim
-> C:\cygwin\etc\alternatives\vim
-> C:\cygwin\bin\vim-nox.exe
15k 2011/10/11 C:\cygwin\bin\cygattr-1.dll - os=4.0 img=1.0 sys=4.0
"cygattr-1.dll" v0.0 ts=2009/11/18 7:52
95k 2011/10/11 C:\cygwin\bin\cygblkid-1.dll - os=4.0 img=1.0 sys=4.0
"cygblkid-1.dll" v0.0 ts=2010/6/24 15:20
62k 2011/10/11 C:\cygwin\bin\cygbz2-1.dll - os=4.0 img=1.0 sys=4.0
"cygbz2-1.dll" v0.0 ts=2011/5/21 15:16
678k 2011/10/11 C:\cygwin\bin\cygcairo-2.dll - os=4.0 img=1.0 sys=4.0
"cygcairo-2.dll" v0.0 ts=2010/12/29 1:16
20k 2011/10/11 C:\cygwin\bin\cygcairo-gobject-2.dll - os=4.0 img=1.0 sys=4.0
"cygcairo-gobject-2.dll" v0.0 ts=2010/12/29 1:17
98k 2011/10/11 C:\cygwin\bin\cygcairo-script-interpreter-2.dll - os=4.0 img=1.0 sys=4.0
"cygcairo-script-interpreter-2.dll" v0.0 ts=2010/12/29 1:17
108k 2011/10/11 C:\cygwin\bin\cygcloog-0.dll - os=4.0 img=1.0 sys=4.0
"cygcloog-0.dll" v0.0 ts=2010/1/4 19:45
7k 2011/10/11 C:\cygwin\bin\cygcrypt-0.dll - os=4.0 img=1.0 sys=4.0
"cygcrypt-0.dll" v0.0 ts=2003/10/19 3:57
1147k 2011/10/11 C:\cygwin\bin\cygcrypto-0.9.8.dll - os=4.0 img=1.0 sys=4.0
"cygcrypto-0.9.8.dll" v0.0 ts=2011/3/16 16:54
943k 2011/10/11 C:\cygwin\bin\cygdb-4.5.dll - os=4.0 img=1.0 sys=4.0
"cygdb-4.5.dll" v0.0 ts=2007/12/17 8:12
1296k 2011/10/11 C:\cygwin\bin\cygdb_cxx-4.5.dll - os=4.0 img=1.0 sys=4.0
"cygdb_cxx-4.5.dll" v0.0 ts=2007/12/17 8:12
511k 2011/10/11 C:\cygwin\bin\cygedit-0.dll - os=4.0 img=1.0 sys=4.0
"cygedit-0.dll" v0.0 ts=2010/6/17 7:42
118k 2011/10/11 C:\cygwin\bin\cygexpat-1.dll - os=4.0 img=1.0 sys=4.0
"cygexpat-1.dll" v0.0 ts=2008/5/9 0:03
29k 2011/10/11 C:\cygwin\bin\cygfam-0.dll - os=4.0 img=1.0 sys=4.0
"cygfam-0.dll" v0.0 ts=2010/5/12 6:26
103k 2011/10/11 C:\cygwin\bin\cygffi-4.dll - os=4.0 img=1.0 sys=4.0
"cygffi-4.dll" v0.0 ts=2011/8/31 9:07
176k 2011/10/11 C:\cygwin\bin\cygfontconfig-1.dll - os=4.0 img=1.0 sys=4.0
"cygfontconfig-1.dll" v0.0 ts=2010/1/28 17:12
20k 2011/10/11 C:\cygwin\bin\cygfontenc-1.dll - os=4.0 img=1.0 sys=4.0
"cygfontenc-1.dll" v0.0 ts=2010/10/31 15:19
43k 2011/10/11 C:\cygwin\bin\cygform-10.dll - os=4.0 img=1.0 sys=4.0
"cygform-10.dll" v0.0 ts=2010/1/2 9:49
40k 2011/10/11 C:\cygwin\bin\cygform-8.dll - os=4.0 img=1.0 sys=4.0
"cygform-8.dll" v0.0 ts=2009/3/1 1:32
43k 2011/10/11 C:\cygwin\bin\cygform-9.dll - os=4.0 img=1.0 sys=4.0
"cygform-9.dll" v0.0 ts=2009/11/20 14:14
47k 2011/10/11 C:\cygwin\bin\cygformw-10.dll - os=4.0 img=1.0 sys=4.0
"cygformw-10.dll" v0.0 ts=2010/1/2 12:31
496k 2011/10/11 C:\cygwin\bin\cygfreetype-6.dll - os=4.0 img=1.0 sys=4.0
"cygfreetype-6.dll" v0.0 ts=2011/7/26 15:41
442k 2011/10/11 C:\cygwin\bin\cyggcc_s-1.dll - os=4.0 img=1.0 sys=4.0
"cyggcc_s-1.dll" v0.0 ts=2011/8/31 8:51
449k 2011/10/11 C:\cygwin\bin\cyggcrypt-11.dll - os=4.0 img=1.0 sys=4.0
"cyggcrypt-11.dll" v0.0 ts=2011/5/19 22:29
19k 2011/10/11 C:\cygwin\bin\cyggdbm-4.dll - os=4.0 img=1.0 sys=4.0
"cyggdbm-4.dll" v0.0 ts=2009/2/26 2:58
8k 2011/10/11 C:\cygwin\bin\cyggdbm_compat-4.dll - os=4.0 img=1.0 sys=4.0
"cyggdbm_compat-4.dll" v0.0 ts=2009/2/26 2:58
552k 2011/10/11 C:\cygwin\bin\cyggio-2.0-0.dll - os=4.0 img=1.0 sys=4.0
"cyggio-2.0-0.dll" v0.0 ts=2010/6/14 23:25
377k 2011/10/11 C:\cygwin\bin\cygGL-1.dll - os=4.0 img=1.0 sys=4.0
"cygGL-1.dll" v0.0 ts=2011/7/19 21:19
764k 2011/10/11 C:\cygwin\bin\cygglib-2.0-0.dll - os=4.0 img=1.0 sys=4.0
"cygglib-2.0-0.dll" v0.0 ts=2010/6/14 23:22
141k 2011/10/11 C:\cygwin\bin\cygglitz-1.dll - os=4.0 img=1.0 sys=4.0
"cygglitz-1.dll" v0.0 ts=2009/3/30 12:22
21k 2011/10/11 C:\cygwin\bin\cygglitz-glx-1.dll - os=4.0 img=1.0 sys=4.0
"cygglitz-glx-1.dll" v0.0 ts=2009/3/30 12:23
14k 2011/10/11 C:\cygwin\bin\cyggmodule-2.0-0.dll - os=4.0 img=1.0 sys=4.0
"cyggmodule-2.0-0.dll" v0.0 ts=2010/6/14 23:23
317k 2011/10/11 C:\cygwin\bin\cyggmp-3.dll - os=4.0 img=1.0 sys=4.0
"cyggmp-3.dll" v0.0 ts=2011/7/31 1:14
14k 2011/10/11 C:\cygwin\bin\cyggmpxx-4.dll - os=4.0 img=1.0 sys=4.0
"cyggmpxx-4.dll" v0.0 ts=2011/7/31 6:31
233k 2011/10/11 C:\cygwin\bin\cyggobject-2.0-0.dll - os=4.0 img=1.0 sys=4.0
"cyggobject-2.0-0.dll" v0.0 ts=2010/6/14 23:23
265k 2011/10/11 C:\cygwin\bin\cyggomp-1.dll - os=4.0 img=1.0 sys=4.0
"cyggomp-1.dll" v0.0 ts=2011/8/31 8:55
14k 2011/10/11 C:\cygwin\bin\cyggpg-error-0.dll - os=4.0 img=1.0 sys=4.0
"cyggpg-error-0.dll" v0.0 ts=2011/5/19 22:04
5491k 2011/10/11 C:\cygwin\bin\cyggs-8.dll - os=4.0 img=1.0 sys=4.0
"cyggs-8.dll" v0.0 ts=2008/11/27 8:24
17k 2011/10/11 C:\cygwin\bin\cyggthread-2.0-0.dll - os=4.0 img=1.0 sys=4.0
"cyggthread-2.0-0.dll" v0.0 ts=2010/6/14 23:23
24k 2009/06/23 C:\cygwin\bin\cyghistory6.dll - os=4.0 img=1.0 sys=4.0
"cyghistory6.dll" v0.0 ts=2009/6/23 8:20
25k 2011/01/26 C:\cygwin\bin\cyghistory7.dll - os=4.0 img=1.0 sys=4.0
"cyghistory7.dll" v0.0 ts=2011/1/25 22:25
74k 2011/10/11 C:\cygwin\bin\cygICE-6.dll - os=4.0 img=1.0 sys=4.0
"cygICE-6.dll" v0.0 ts=2010/10/31 15:18
358k 2011/10/11 C:\cygwin\bin\cygicons-0.dll - os=4.0 img=1.4 sys=4.0
"cygicons-0.dll" v0.0 ts=2011/4/29 0:37
986k 2011/10/11 C:\cygwin\bin\cygiconv-2.dll - os=4.0 img=1.0 sys=4.0
"cygiconv-2.dll" v0.0 ts=2011/8/28 19:59
193k 2011/10/11 C:\cygwin\bin\cygidn-11.dll - os=4.0 img=1.0 sys=4.0
"cygidn-11.dll" v0.0 ts=2010/5/16 9:37
45k 2011/10/11 C:\cygwin\bin\cygintl-8.dll - os=4.0 img=1.0 sys=4.0
"cygintl-8.dll" v0.0 ts=2011/8/28 16:39
246k 2011/10/11 C:\cygwin\bin\cygjasper-1.dll - os=4.0 img=1.0 sys=4.0
"cygjasper-1.dll" v0.0 ts=2010/5/20 1:04
125k 2011/10/11 C:\cygwin\bin\cygjpeg-62.dll - os=4.0 img=1.0 sys=4.0
"cygjpeg-62.dll" v0.0 ts=2009/8/8 16:48
193k 2011/10/11 C:\cygwin\bin\cygjpeg-7.dll - os=4.0 img=1.0 sys=4.0
"cygjpeg-7.dll" v0.0 ts=2009/8/8 15:39
5k 2011/10/11 C:\cygwin\bin\cyglsa.dll - os=4.0 img=1.0 sys=4.0
"cyglsa.dll" v0.0 ts=2011/3/28 17:14
9k 2011/03/29 C:\cygwin\bin\cyglsa64.dll - os=5.2 img=0.0 sys=5.2
123k 2011/10/11 C:\cygwin\bin\cyglzma-5.dll - os=4.0 img=1.0 sys=4.0
"cyglzma-5.dll" v0.0 ts=2011/5/18 22:41
103k 2011/10/11 C:\cygwin\bin\cygmagic-1.dll - os=4.0 img=1.0 sys=4.0
"cygmagic-1.dll" v0.0 ts=2011/2/3 4:47
25k 2011/10/11 C:\cygwin\bin\cygmenu-10.dll - os=4.0 img=1.0 sys=4.0
"cygmenu-10.dll" v0.0 ts=2010/1/2 9:48
21k 2011/10/11 C:\cygwin\bin\cygmenu-8.dll - os=4.0 img=1.0 sys=4.0
"cygmenu-8.dll" v0.0 ts=2009/3/1 1:31
25k 2011/10/11 C:\cygwin\bin\cygmenu-9.dll - os=4.0 img=1.0 sys=4.0
"cygmenu-9.dll" v0.0 ts=2009/11/20 14:13
25k 2011/10/11 C:\cygwin\bin\cygmenuw-10.dll - os=4.0 img=1.0 sys=4.0
"cygmenuw-10.dll" v0.0 ts=2010/1/2 12:30
213k 2011/10/11 C:\cygwin\bin\cygmp-3.dll - os=4.0 img=1.0 sys=4.0
"cygmp-3.dll" v0.0 ts=2011/7/31 1:12
64k 2011/10/11 C:\cygwin\bin\cygmpc-1.dll - os=4.0 img=1.0 sys=4.0
"cygmpc-1.dll" v0.0 ts=2009/11/8 20:21
269k 2011/10/11 C:\cygwin\bin\cygmpfr-1.dll - os=4.0 img=1.0 sys=4.0
"cygmpfr-1.dll" v0.0 ts=2009/6/7 17:10
1102k 2011/10/11 C:\cygwin\bin\cygmpfr-4.dll - os=4.0 img=1.0 sys=4.0
"cygmpfr-4.dll" v0.0 ts=2011/8/6 21:47
63k 2011/10/11 C:\cygwin\bin\cygncurses++-10.dll - os=4.0 img=1.0 sys=4.0
"cygncurses++-10.dll" v0.0 ts=2010/1/2 10:00
66k 2011/10/11 C:\cygwin\bin\cygncurses++-8.dll - os=4.0 img=1.0 sys=4.0
"cygncurses++-8.dll" v0.0 ts=2009/3/1 1:39
63k 2011/10/11 C:\cygwin\bin\cygncurses++-9.dll - os=4.0 img=1.0 sys=4.0
"cygncurses++-9.dll" v0.0 ts=2009/11/20 14:25
63k 2011/10/11 C:\cygwin\bin\cygncurses++w-10.dll - os=4.0 img=1.0 sys=4.0
"cygncurses++w-10.dll" v0.0 ts=2010/1/2 12:41
195k 2011/10/11 C:\cygwin\bin\cygncurses-10.dll - os=4.0 img=1.0 sys=4.0
"cygncurses-10.dll" v0.0 ts=2010/1/2 9:45
237k 2011/10/11 C:\cygwin\bin\cygncurses-8.dll - os=4.0 img=1.0 sys=4.0
"cygncurses-8.dll" v0.0 ts=2009/3/1 1:28
198k 2011/10/11 C:\cygwin\bin\cygncurses-9.dll - os=4.0 img=1.0 sys=4.0
"cygncurses-9.dll" v0.0 ts=2009/11/20 14:10
244k 2011/10/11 C:\cygwin\bin\cygncursesw-10.dll - os=4.0 img=1.0 sys=4.0
"cygncursesw-10.dll" v0.0 ts=2010/1/2 12:28
13k 2011/10/11 C:\cygwin\bin\cygpanel-10.dll - os=4.0 img=1.0 sys=4.0
"cygpanel-10.dll" v0.0 ts=2010/1/2 9:47
11k 2011/10/11 C:\cygwin\bin\cygpanel-8.dll - os=4.0 img=1.0 sys=4.0
"cygpanel-8.dll" v0.0 ts=2009/3/1 1:30
13k 2011/10/11 C:\cygwin\bin\cygpanel-9.dll - os=4.0 img=1.0 sys=4.0
"cygpanel-9.dll" v0.0 ts=2009/11/20 14:12
13k 2011/10/11 C:\cygwin\bin\cygpanelw-10.dll - os=4.0 img=1.0 sys=4.0
"cygpanelw-10.dll" v0.0 ts=2010/1/2 11:30
257k 2011/10/11 C:\cygwin\bin\cygpcre-0.dll - os=4.0 img=1.0 sys=4.0
"cygpcre-0.dll" v0.0 ts=2011/9/27 1:41
8k 2011/10/11 C:\cygwin\bin\cygpcreposix-0.dll - os=4.0 img=1.0 sys=4.0
"cygpcreposix-0.dll" v0.0 ts=2011/9/27 1:41
1627k 2010/08/29 C:\cygwin\bin\cygperl5_10.dll - os=4.0 img=1.0 sys=4.0
"cygperl5_10.dll" v0.0 ts=2010/8/28 14:17
428k 2011/10/11 C:\cygwin\bin\cygpixman-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygpixman-1-0.dll" v0.0 ts=2011/8/22 4:39
249k 2011/10/11 C:\cygwin\bin\cygpng12.dll - os=4.0 img=1.0 sys=4.0
"cygpng12.dll" v0.0 ts=2011/7/28 1:20
129k 2011/10/11 C:\cygwin\bin\cygpng14-14.dll - os=4.0 img=1.0 sys=4.0
"cygpng14-14.dll" v0.0 ts=2011/7/28 1:55
22k 2011/10/11 C:\cygwin\bin\cygpopt-0.dll - os=4.0 img=1.0 sys=4.0
"cygpopt-0.dll" v0.0 ts=2002/6/9 1:45
695k 2011/10/11 C:\cygwin\bin\cygppl-7.dll - os=4.0 img=1.0 sys=4.0
"cygppl-7.dll" v0.0 ts=2009/4/18 8:44
2481k 2011/10/11 C:\cygwin\bin\cygppl_c-2.dll - os=4.0 img=1.0 sys=4.0
"cygppl_c-2.dll" v0.0 ts=2009/4/18 8:47
18k 2011/10/11 C:\cygwin\bin\cygpwl-4.dll - os=4.0 img=1.0 sys=4.0
"cygpwl-4.dll" v0.0 ts=2009/4/18 8:44
155k 2009/06/23 C:\cygwin\bin\cygreadline6.dll - os=4.0 img=1.0 sys=4.0
"cygreadline6.dll" v0.0 ts=2009/6/23 8:20
164k 2011/01/26 C:\cygwin\bin\cygreadline7.dll - os=4.0 img=1.0 sys=4.0
"cygreadline7.dll" v0.0 ts=2011/1/25 22:25
8k 2011/10/11 C:\cygwin\bin\cygsigsegv-2.dll - os=4.0 img=1.0 sys=4.0
"cygsigsegv-2.dll" v0.0 ts=2011/5/5 3:33
25k 2011/10/11 C:\cygwin\bin\cygSM-6.dll - os=4.0 img=1.0 sys=4.0
"cygSM-6.dll" v0.0 ts=2010/10/31 15:24
263k 2011/10/11 C:\cygwin\bin\cygssl-0.9.8.dll - os=4.0 img=1.0 sys=4.0
"cygssl-0.9.8.dll" v0.0 ts=2011/3/16 16:54
52k 2011/10/11 C:\cygwin\bin\cygssp-0.dll - os=4.0 img=1.0 sys=4.0
"cygssp-0.dll" v0.0 ts=2011/8/31 9:07
5698k 2011/10/11 C:\cygwin\bin\cygstdc++-6.dll - os=4.0 img=1.0 sys=4.0
"cygstdc++-6.dll" v0.0 ts=2011/8/31 9:25
48k 2011/10/11 C:\cygwin\bin\cygtic-10.dll - os=4.0 img=1.0 sys=4.0
"cygtic-10.dll" v0.0 ts=2010/1/2 9:45
48k 2011/10/11 C:\cygwin\bin\cygtic-9.dll - os=4.0 img=1.0 sys=4.0
"cygtic-9.dll" v0.0 ts=2009/11/20 14:10
48k 2011/10/11 C:\cygwin\bin\cygticw-10.dll - os=4.0 img=1.0 sys=4.0
/usr/bin/cygrunsrv: warning: OpenService failed for 'DcomLaunch': Win32 error 5
Access is denied.
/usr/bin/cygrunsrv: warning: OpenService failed for 'odserv': Win32 error 5
Access is denied.
/usr/bin/cygrunsrv: warning: OpenService failed for 'ose': Win32 error 5
Access is denied.
/usr/bin/cygrunsrv: warning: OpenService failed for 'pla': Win32 error 5
Access is denied.
/usr/bin/cygrunsrv: warning: OpenService failed for 'QWAVE': Win32 error 5
Access is denied.
/usr/bin/cygrunsrv: warning: OpenService failed for 'RpcEptMapper': Win32 error 5
Access is denied.
/usr/bin/cygrunsrv: warning: OpenService failed for 'RpcSs': Win32 error 5
Access is denied.
"cygticw-10.dll" v0.0 ts=2010/1/2 12:28
16k 2011/10/11 C:\cygwin\bin\cyguuid-1.dll - os=4.0 img=1.0 sys=4.0
"cyguuid-1.dll" v0.0 ts=2010/6/24 15:19
28k 2011/10/11 C:\cygwin\bin\cygwrap-0.dll - os=4.0 img=1.0 sys=4.0
"cygwrap-0.dll" v0.0 ts=2010/3/28 5:02
1045k 2011/10/11 C:\cygwin\bin\cygX11-6.dll - os=4.0 img=1.0 sys=4.0
"cygX11-6.dll" v0.0 ts=2011/8/22 4:25
6k 2011/10/11 C:\cygwin\bin\cygX11-xcb-1.dll - os=4.0 img=1.0 sys=4.0
"cygX11-xcb-1.dll" v0.0 ts=2011/8/22 4:26
11k 2011/10/11 C:\cygwin\bin\cygXau-6.dll - os=4.0 img=1.0 sys=4.0
"cygXau-6.dll" v0.0 ts=2010/8/2 20:32
337k 2011/10/11 C:\cygwin\bin\cygXaw-7.dll - os=4.0 img=1.0 sys=4.0
"cygXaw-7.dll" v0.0 ts=2011/2/4 2:02
75k 2011/10/11 C:\cygwin\bin\cygxcb-1.dll - os=4.0 img=1.0 sys=4.0
"cygxcb-1.dll" v0.0 ts=2010/12/20 20:36
12k 2011/10/11 C:\cygwin\bin\cygxcb-atom-1.dll - os=4.0 img=1.0 sys=4.0
"cygxcb-atom-1.dll" v0.0 ts=2009/9/3 1:23
51k 2011/10/11 C:\cygwin\bin\cygxcb-glx-0.dll - os=4.0 img=1.0 sys=4.0
"cygxcb-glx-0.dll" v0.0 ts=2010/12/20 20:36
22k 2011/10/11 C:\cygwin\bin\cygxcb-render-0.dll - os=4.0 img=1.0 sys=4.0
"cygxcb-render-0.dll" v0.0 ts=2010/12/20 20:36
11k 2011/10/11 C:\cygwin\bin\cygxcb-render-util-0.dll - os=4.0 img=1.0 sys=4.0
"cygxcb-render-util-0.dll" v0.0 ts=2011/5/23 4:25
8k 2011/10/11 C:\cygwin\bin\cygxcb-shm-0.dll - os=4.0 img=1.0 sys=4.0
"cygxcb-shm-0.dll" v0.0 ts=2010/12/20 20:36
17k 2011/10/11 C:\cygwin\bin\cygXdmcp-6.dll - os=4.0 img=1.0 sys=4.0
"cygXdmcp-6.dll" v0.0 ts=2010/10/31 15:29
52k 2011/10/11 C:\cygwin\bin\cygXext-6.dll - os=4.0 img=1.0 sys=4.0
"cygXext-6.dll" v0.0 ts=2011/5/23 4:32
66k 2011/10/11 C:\cygwin\bin\cygXft-2.dll - os=4.0 img=1.0 sys=4.0
"cygXft-2.dll" v0.0 ts=2010/10/31 21:10
119k 2011/10/11 C:\cygwin\bin\cygxkbfile-1.dll - os=4.0 img=1.0 sys=4.0
"cygxkbfile-1.dll" v0.0 ts=2010/10/31 21:33
75k 2011/10/11 C:\cygwin\bin\cygXmu-6.dll - os=4.0 img=1.0 sys=4.0
"cygXmu-6.dll" v0.0 ts=2010/10/31 21:19
11k 2011/10/11 C:\cygwin\bin\cygXmuu-1.dll - os=4.0 img=1.0 sys=4.0
"cygXmuu-1.dll" v0.0 ts=2010/10/31 21:19
53k 2011/10/11 C:\cygwin\bin\cygXpm-4.dll - os=4.0 img=1.0 sys=4.0
"cygXpm-4.dll" v0.0 ts=2010/10/31 21:19
32k 2011/10/11 C:\cygwin\bin\cygXrender-1.dll - os=4.0 img=1.0 sys=4.0
"cygXrender-1.dll" v0.0 ts=2010/8/3 0:48
278k 2011/10/11 C:\cygwin\bin\cygXt-6.dll - os=4.0 img=1.0 sys=4.0
"cygXt-6.dll" v0.0 ts=2011/6/6 23:40
76k 2011/10/11 C:\cygwin\bin\cygz.dll - os=4.0 img=1.0 sys=4.0
"cygz.dll" v0.0 ts=2010/8/1 17:04
2604k 2011/03/29 C:\cygwin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0
"cygwin1.dll" v0.0 ts=2011/3/29 4:10
Cygwin DLL version info:
DLL version: 1.7.9
DLL epoch: 19
DLL old termios: 5
DLL malloc env: 28
Cygwin conv: 181
API major: 0
API minor: 237
Shared data: 5
DLL identifier: cygwin1
Mount registry: 3
Cygwin registry name: Cygwin
Program options name: Program Options
Installations name: Installations
Cygdrive default prefix:
Build date:
Shared id: cygwin1S5
No Cygwin services found.
Cygwin Package Information
Last downloaded files to: C:\Users\jc807j\Desktop\Cygwin
Last downloaded files from: http://cygwin.mirrors.pair.com/
Package Version Status
_update-info-dir 00985-1 OK
alternatives 1.3.30c-10 OK
base-cygwin 3.0-1 OK
base-files 4.0-6 OK
bash 4.1.10-4 OK
bc 1.06-2 OK
binutils 2.21.53-2 OK
bzip2 1.0.6-2 OK
cabextract 1.4-1 OK
coreutils 8.10-1 OK
cron 4.1-59 OK
crypt 1.1-1 OK
csih 0.9.4-1 OK
cygrunsrv 1.34-1 OK
cygutils 1.4.6-1 OK
cygwin 1.7.9-1 OK
cygwin-doc 1.7-1 OK
cygwin-x-doc 1.1.1-1 OK
dash 0.5.6.1-2 OK
diffutils 2.9-1 OK
dos2unix 5.3.1-1 OK
editrights 1.01-2 OK
file 5.05-1 OK
findutils 4.5.9-2 OK
font-adobe-dpi75 1.0.2-1 OK
font-alias 1.0.3-1 OK
font-encodings 1.0.4-1 OK
font-misc-misc 1.1.1-1 OK
fontconfig 2.8.0-1 OK
gamin 0.1.10-11 OK
gawk 4.0.0-1 OK
gcc4-core 4.5.3-2 OK
gcc4-g++ 4.5.3-2 OK
gdb 7.3.50-2 OK
gettext 0.18.1.1-1 OK
ghostscript 8.63-2 OK
ghostscript-fonts-other 6.0-1 OK
ghostscript-fonts-std 8.11-1 OK
grep 2.6.3-1 OK
groff 1.20.1-2 OK
gzip 1.4-1 OK
ipc-utils 1.0-1 OK
less 444-1 OK
libattr1 2.4.43-1 OK
libblkid1 2.17.2-1 OK
libbz2_1 1.0.6-2 OK
libcairo2 1.10.2-1 OK
libcloog0 0.15.7-1 OK
libdb4.5 4.5.20.2-2 OK
libedit0 20090923-1 OK
libexpat1 2.0.1-1 OK
libfam0 0.1.10-11 OK
libffi4 4.5.3-2 OK
libfontconfig1 2.8.0-1 OK
libfontenc1 1.1.0-1 OK
libfreetype6 2.4.5-1 OK
libgcc1 4.5.3-2 OK
libgcrypt11 1.4.6-1 OK
libgdbm4 1.8.3-20 OK
libGL1 7.10.3-1 OK
libglib2.0_0 2.24.1-1 OK
libglitz1 0.5.6-10 OK
libgmp3 4.3.2-1 OK
libgmpxx4 4.3.2-1 OK
libgomp1 4.5.3-2 OK
libgpg-error0 1.10-1 OK
libgs8 8.63-2 OK
libICE6 1.0.7-1 OK
libiconv2 1.14-1 OK
libidn11 1.18-1 OK
libintl8 0.18.1.1-1 OK
libjasper1 1.900.1-11 OK
libjpeg62 6b-21 OK
libjpeg7 7-10 OK
liblzma5 5.0.2_20110517-1 OK
libmpc1 0.8-1 OK
libmpfr1 2.4.1-4 OK
libmpfr4 3.0.1-1 OK
libncurses10 5.7-18 OK
libncurses8 5.5-10 OK
libncurses9 5.7-16 OK
libncursesw10 5.7-18 OK
libopenssl098 0.9.8r-2 OK
libpcre0 8.13-1 OK
libpixman1_0 0.22.2-1 OK
libpng12 1.2.46-1 OK
libpng14 1.4.8-1 OK
libpopt0 1.6.4-4 OK
libppl 0.10.2-1 OK
libreadline6 5.2.14-12 OK
libreadline7 6.1.2-2 OK
libsigsegv2 2.10-1 OK
libSM6 1.2.0-1 OK
libssp0 4.5.3-2 OK
libstdc++6 4.5.3-2 OK
libstdc++6-devel 4.5.3-2 OK
libuuid1 2.17.2-1 OK
libwrap0 7.6-21 OK
libX11-xcb1 1.4.4-1 OK
libX11_6 1.4.4-1 OK
libXau6 1.0.6-1 OK
libXaw7 1.0.9-1 OK
libxcb-atom1 0.3.6-1 OK
libxcb-glx0 1.7-2 OK
libxcb-render-util0 0.3.8-1 OK
libxcb-render0 1.7-2 OK
libxcb-shm0 1.7-2 OK
libxcb1 1.7-2 OK
libXdmcp6 1.1.0-1 OK
libXext6 1.3.0-1 OK
libXft2 2.2.0-1 OK
libxkbfile1 1.0.7-1 OK
libXmu6 1.1.0-1 OK
libXmuu1 1.1.0-1 OK
libXpm4 3.5.9-1 OK
libXrender1 0.9.6-1 OK
libXt6 1.1.1-1 OK
login 1.10-10 OK
luit 1.1.0-1 OK
make 3.81-2 OK
man 1.6f-1 OK
Empty package mesa
mesa 7.10.3-1 OK
mesa-demos 8.0.1-1 OK
mintty 1.0.1-1 OK
mkfontdir 1.0.6-1 OK
mkfontscale 1.0.9-1 OK
oclock 1.0.2-1 OK
opengl 1.1.0-10 OK
openssh 5.9p1-1 OK
patch 2.5.8-9 OK
pdftk 1.41-1 OK
perl 5.10.1-5 OK
ping 1.0-1 OK
procps 3.2.7-1 OK
psmisc 22.14-1 OK
rebase 3.0.1-1 OK
run 1.1.13-1 OK
screen 4.0.3-7 OK
sed 4.2.1-1 OK
tar 1.25-1 OK
tcltk 20080420-1 OK
terminfo 5.7_20091114-14 OK
terminfo0 5.5_20061104-12 OK
texinfo 4.13-4 OK
time 1.7-2 OK
tzcode 2010j-1 OK
units 1.87-1 OK
unzip 6.0-10 OK
util-linux 2.17.2-1 OK
vim 7.3.003-1 OK
w32api 3.17-2 OK
wget 1.12-1 OK
which 2.20-2 OK
wtf 0.0.4-7 OK
X-start-menu-icons 1.0.4-1 OK
xauth 1.0.6-1 OK
xcursor-themes 1.0.3-1 OK
xinit 1.3.1-1 OK
xkbcomp 1.2.3-1 OK
xkeyboard-config 2.3-1 OK
xlsclients 1.1.2-1 OK
xlsfonts 1.0.3-1 OK
xmodmap 1.0.5-1 OK
xorg-server 1.10.3-12 OK
xrdb 1.0.9-1 OK
xterm 275b-1 OK
xz 5.0.2_20110517-1 OK
zip 3.0-11 OK
zlib 1.2.5-1 OK
zlib-devel 1.2.5-1 OK
zlib0 1.2.5-1 OK
Use -h to see help about each section
[-- Attachment #3: Type: text/plain, Size: 218 bytes --]
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: /proc/*/cmdline corrupted
2011-10-12 15:08 /proc/*/cmdline corrupted Jon Clugston
@ 2011-10-13 12:56 ` jan.kolar
2011-10-13 13:02 ` Christopher Faylor
2011-10-13 18:02 ` Jon Clugston
2011-10-16 21:31 ` jan.kolar
2 siblings, 1 reply; 17+ messages in thread
From: jan.kolar @ 2011-10-13 12:56 UTC (permalink / raw)
To: cygwin
The content /proc/<pid>/cmdline is created by the proces <pid> itself, in a
separate thread.
Since you use memory intensive application (xterm -sl 20000) we can
speculate
it might be caused by memory corruption in xterm.
Observe whether the processes with corrupted /proc/<pid>/cmdline behave
properly
and try avoiding '-sl 20000' as a work-arround.
Unless there is another application with the same problem, this is not a
topic for this list, I think.
--
View this message in context: http://old.nabble.com/-proc-*-cmdline-corrupted-tp32639066p32645081.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: /proc/*/cmdline corrupted
2011-10-13 12:56 ` jan.kolar
@ 2011-10-13 13:02 ` Christopher Faylor
0 siblings, 0 replies; 17+ messages in thread
From: Christopher Faylor @ 2011-10-13 13:02 UTC (permalink / raw)
To: cygwin
On Thu, Oct 13, 2011 at 05:55:41AM -0700, jan.kolar wrote:
>
>
>The content /proc/<pid>/cmdline is created by the proces <pid> itself, in a
>separate thread.
>Since you use memory intensive application (xterm -sl 20000) we can
>speculate
>it might be caused by memory corruption in xterm.
>
>Observe whether the processes with corrupted /proc/<pid>/cmdline behave
>properly
>and try avoiding '-sl 20000' as a work-arround.
>
>Unless there is another application with the same problem, this is not a
>topic for this list, I think.
If /proc/<pid>/cmdline is shown to be corrupted it certainly is a topic
for this list. As always a simple test case would allow us to debug the
problem.
cgf
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: /proc/*/cmdline corrupted
2011-10-12 15:08 /proc/*/cmdline corrupted Jon Clugston
2011-10-13 12:56 ` jan.kolar
@ 2011-10-13 18:02 ` Jon Clugston
2011-10-13 18:14 ` Andrew DeFaria
2011-10-17 16:47 ` jan.kolar
2011-10-16 21:31 ` jan.kolar
2 siblings, 2 replies; 17+ messages in thread
From: Jon Clugston @ 2011-10-13 18:02 UTC (permalink / raw)
To: cygwin
On Wed, Oct 12, 2011 at 11:07 AM, Jon Clugston <jon.clugston@gmail.com> wrote:
> Greetings,
>
> When I run "procps -ef" I get corrupted command line parameters:
>
> jc807j@~>procps -ef
> UID PID PPID C STIME TTY TIME CMD
> jc807j 5852 1 0 08:59 tty0 00:00:03 X :0 -multiwindow
> jc807j 2668 1 0 08:59 tty0 00:00:00 xterm -e ssh server
> 80x72+285+0 -e ssh server
> jc807j 3004 1 0 08:59 tty0 00:00:00 xterm -e ssh server
> 80x72-8+0 -e ssh server
> jc807j 3392 3004 0 08:59 tty0 00:00:00 ssh server
> jc807j 5960 2668 0 08:59 tty1 00:00:00 ssh server
> jc807j 2928 5852 0 09:12 ? 00:00:00 xterm 20000 +tb
> jc807j 4608 2928 0 09:12 tty2 00:00:00 bash
> jc807j 5800 4608 1 10:57 tty2 00:00:00 procps -ef
>
> The actual command lines for the 3 xterm processes are:
>
> C:\cygwin\bin\xterm.exe -sl 20000 +tb -geometry 80x72+285+0 -e ssh server
> C:\cygwin\bin\xterm.exe -sl 20000 +tb -geometry 80x72-8+0 -e ssh server
> C:\cygwin\bin\xterm.exe -sl 20000 +tb
>
> as reported by the "listdlls" tool.
>
> I have verified that the "/proc/*/cmdline" is the source of the
> corrupted information. "cmdline" from PID 2928 is:
>
> jc807j@~>od -c /proc/2928/cmdline
> 0000000 x t e r m \0 \0 2 0 0 0 0 \0 + t b
> 0000020 \0
> 0000021
>
I am able to reproduce the problem by simply executing the following
command line:
xterm -sl 20000 +tb -geometry 80x72+285+0 -e ssh server
(obviously w/ X running). I wrote a simple shell script which does
nothing except sleep and I called it with the same command line
parameters and it didn't have the problem. So, it appears that the
problem is related to "xterm" or something that "xterm" does.
I also shortened/simplified the command line (to "xterm") and it was
still corrupted (the "-sl" was missing):
xterm -sl 20000 +tb -geometry 80x72+285+0
I tried to reproduce by creating long command lines to other commands
and none were corrupted.
Does "xterm" step on its command line?
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: /proc/*/cmdline corrupted
2011-10-13 18:02 ` Jon Clugston
@ 2011-10-13 18:14 ` Andrew DeFaria
2011-10-17 16:47 ` jan.kolar
1 sibling, 0 replies; 17+ messages in thread
From: Andrew DeFaria @ 2011-10-13 18:14 UTC (permalink / raw)
To: cygwin
On 10/13/2011 11:02 AM, Jon Clugston wrote:
> On Wed, Oct 12, 2011 at 11:07 AM, Jon Clugston<jon.clugston@gmail.com> wrote:
>> Greetings,
>>
>> When I run "procps -ef" I get corrupted command line parameters:
>>
>> jc807j@~>procps -ef
>> UID PID PPID C STIME TTY TIME CMD
>> jc807j 5852 1 0 08:59 tty0 00:00:03 X :0 -multiwindow
>> jc807j 2668 1 0 08:59 tty0 00:00:00 xterm -e ssh server
>> 80x72+285+0 -e ssh server
>> jc807j 3004 1 0 08:59 tty0 00:00:00 xterm -e ssh server
>> 80x72-8+0 -e ssh server
>> jc807j 3392 3004 0 08:59 tty0 00:00:00 ssh server
>> jc807j 5960 2668 0 08:59 tty1 00:00:00 ssh server
>> jc807j 2928 5852 0 09:12 ? 00:00:00 xterm 20000 +tb
>> jc807j 4608 2928 0 09:12 tty2 00:00:00 bash
>> jc807j 5800 4608 1 10:57 tty2 00:00:00 procps -ef
>>
>> The actual command lines for the 3 xterm processes are:
>>
>> C:\cygwin\bin\xterm.exe -sl 20000 +tb -geometry 80x72+285+0 -e ssh server
>> C:\cygwin\bin\xterm.exe -sl 20000 +tb -geometry 80x72-8+0 -e ssh server
>> C:\cygwin\bin\xterm.exe -sl 20000 +tb
>>
>> as reported by the "listdlls" tool.
>>
>> I have verified that the "/proc/*/cmdline" is the source of the
>> corrupted information. "cmdline" from PID 2928 is:
>>
>> jc807j@~>od -c /proc/2928/cmdline
>> 0000000 x t e r m \0 \0 2 0 0 0 0 \0 + t b
>> 0000020 \0
>> 0000021
>>
> I am able to reproduce the problem by simply executing the following
> command line:
>
> xterm -sl 20000 +tb -geometry 80x72+285+0 -e ssh server
>
> (obviously w/ X running). I wrote a simple shell script which does
> nothing except sleep and I called it with the same command line
> parameters and it didn't have the problem. So, it appears that the
> problem is related to "xterm" or something that "xterm" does.
>
> I also shortened/simplified the command line (to "xterm") and it was
> still corrupted (the "-sl" was missing):
>
> xterm -sl 20000 +tb -geometry 80x72+285+0
>
> I tried to reproduce by creating long command lines to other commands
> and none were corrupted.
>
> Does "xterm" step on its command line?
While not an answer to your question, why not just put the following in
your ~/.Xdefaults:
serverTerm*saveLines: 20000
serverTerm*toolBar: false
serverTerm*geometry: 80x72+285+0
and invoke xterm with:
$ xterm -name serverTerm -e ssh server
and be done with it?
--
Andrew DeFaria <http://defaria.com>
You know how it is when you're walking up the stairs, and you get to the
top, and you think there's one more step? I'm like that all the time.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: /proc/*/cmdline corrupted
2011-10-12 15:08 /proc/*/cmdline corrupted Jon Clugston
2011-10-13 12:56 ` jan.kolar
2011-10-13 18:02 ` Jon Clugston
@ 2011-10-16 21:31 ` jan.kolar
2011-10-16 23:59 ` Andrew DeFaria
2011-10-17 0:17 ` Jon Clugston
2 siblings, 2 replies; 17+ messages in thread
From: jan.kolar @ 2011-10-16 21:31 UTC (permalink / raw)
To: cygwin
> jc807j 2668 1 0 08:59 tty0 00:00:00 xterm -e ssh server
80x72+285+0 -e ssh server
> jc807j 3004 1 0 08:59 tty0 00:00:00 xterm -e ssh server
> 80x72-8+0 -e ssh server
> jc807j 2928 5852 0 09:12 ? 00:00:00 xterm 20000 +tb
> The actual command lines for the 3 xterm processes are:
> C:\cygwin\bin\xterm.exe -sl 20000 +tb -geometry 80x72+285+0 -e ssh server
> C:\cygwin\bin\xterm.exe -sl 20000 +tb -geometry 80x72-8+0 -e ssh server
> C:\cygwin\bin\xterm.exe -sl 20000 +tb
xterm calls XrmParseCommand() that
"parses an (argc, argv) pair according to the specified option table ... and
modifies the (argc, argv) pair to remove all recognized options."
Therefore
"-sl 20000 +tb -geometry 80x72+285+0"
is properly removed
and "-e ssh server" is moved to __argv[1 .. 3].
Then __argv[4] (respectively __argv[1] for the shorter command) is assigned
null pointer
which results in the second "\0" in the od-output below.
HOWEVER:
Either XrmParseCommand() does not update argc
or the change does not propagate (how would that be possible?) to __argc.
Therefore the command lines appear corrupted this particular way.
/proc/*/cmdline uses a copy of __argc named __argc_safe
which is hardly to be updated anyway.
" for (int i = 0; i < __argc_safe; i++) "
Funny enough, /proc/self/cmdline is likely to contain shortened version of
cmdline:
" for (char **a = __argv; *a; a++) "
[ pinfo.cc from cygwin 1.7.9-1 ]
> I have verified that the "/proc/*/cmdline" is the source of the
> corrupted information. "cmdline" from PID 2928 is:
>
> jc807j@~>od -c /proc/2928/cmdline
> 0000000 x t e r m \0 \0 2 0 0 0 0 \0 + t b
> 0000020 \0
> 0000021
----
What does xterm on different platforms ?
While concept of modifying own cmdline (In fact, __argv[0]) is used very
often to signal the process state down to the user,
I was never thinking of modifying argc:
main (int argc, char **argv)
:-)
JK
--
View this message in context: http://old.nabble.com/-proc-*-cmdline-corrupted-tp32639066p32663265.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: /proc/*/cmdline corrupted
2011-10-16 21:31 ` jan.kolar
@ 2011-10-16 23:59 ` Andrew DeFaria
2011-10-17 7:42 ` jan.kolar
2011-10-17 8:28 ` Corinna Vinschen
2011-10-17 0:17 ` Jon Clugston
1 sibling, 2 replies; 17+ messages in thread
From: Andrew DeFaria @ 2011-10-16 23:59 UTC (permalink / raw)
To: cygwin
On 10/16/11 14:31, jan.kolar wrote:
>> jc807j 2668 1 0 08:59 tty0 00:00:00 xterm -e ssh server
> 80x72+285+0 -e ssh server
>> jc807j 3004 1 0 08:59 tty0 00:00:00 xterm -e ssh server
>> 80x72-8+0 -e ssh server
>> jc807j 2928 5852 0 09:12 ? 00:00:00 xterm 20000 +tb
>> The actual command lines for the 3 xterm processes are:
>> C:\cygwin\bin\xterm.exe -sl 20000 +tb -geometry 80x72+285+0 -e ssh server
>> C:\cygwin\bin\xterm.exe -sl 20000 +tb -geometry 80x72-8+0 -e ssh server
>> C:\cygwin\bin\xterm.exe -sl 20000 +tb
> xterm calls XrmParseCommand() that
> "parses an (argc, argv) pair according to the specified option table ... and
> modifies the (argc, argv) pair to remove all recognized options."
>
> Therefore
> "-sl 20000 +tb -geometry 80x72+285+0"
> is properly removed
> and "-e ssh server" is moved to __argv[1 .. 3].
> Then __argv[4] (respectively __argv[1] for the shorter command) is assigned
> null pointer
> which results in the second "\0" in the od-output below.
>
>
> HOWEVER:
>
> Either XrmParseCommand() does not update argc
> or the change does not propagate (how would that be possible?) to __argc.
> Therefore the command lines appear corrupted this particular way.
>
>
> /proc/*/cmdline uses a copy of __argc named __argc_safe
> which is hardly to be updated anyway.
> " for (int i = 0; i< __argc_safe; i++) "
>
> Funny enough, /proc/self/cmdline is likely to contain shortened version of
> cmdline:
> " for (char **a = __argv; *a; a++)"
> [ pinfo.cc from cygwin 1.7.9-1 ]
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).
--
Andrew DeFaria <http://defaria.com>
Chastity is curable if detected early.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: /proc/*/cmdline corrupted
2011-10-16 21:31 ` jan.kolar
2011-10-16 23:59 ` Andrew DeFaria
@ 2011-10-17 0:17 ` Jon Clugston
2011-10-17 8:34 ` jan.kolar
1 sibling, 1 reply; 17+ messages in thread
From: Jon Clugston @ 2011-10-17 0:17 UTC (permalink / raw)
To: cygwin
I've checked and on Linux (at least) xterm's command line is not
corrupted. From looking at the xterm code, it would appear that the X
libraries would have to be what is corrupting the command line. I
didn't look into the X library (XmParseCommand).
Jon
On Sun, Oct 16, 2011 at 5:31 PM, jan.kolar <kolar@math.cas.cz> wrote:
>
>> jc807j 2668 1 0 08:59 tty0 00:00:00 xterm -e ssh server
> 80x72+285+0 -e ssh server
>> jc807j 3004 1 0 08:59 tty0 00:00:00 xterm -e ssh server
>> 80x72-8+0 -e ssh server
>> jc807j 2928 5852 0 09:12 ? 00:00:00 xterm 20000 +tb
>
>> The actual command lines for the 3 xterm processes are:
>> C:\cygwin\bin\xterm.exe -sl 20000 +tb -geometry 80x72+285+0 -e ssh server
>> C:\cygwin\bin\xterm.exe -sl 20000 +tb -geometry 80x72-8+0 -e ssh server
>> C:\cygwin\bin\xterm.exe -sl 20000 +tb
>
> xterm calls XrmParseCommand() that
> "parses an (argc, argv) pair according to the specified option table ... and
> modifies the (argc, argv) pair to remove all recognized options."
>
> Therefore
> "-sl 20000 +tb -geometry 80x72+285+0"
> is properly removed
> and "-e ssh server" is moved to __argv[1 .. 3].
> Then __argv[4] (respectively __argv[1] for the shorter command) is assigned
> null pointer
> which results in the second "\0" in the od-output below.
>
>
> HOWEVER:
>
> Either XrmParseCommand() does not update argc
> or the change does not propagate (how would that be possible?) to __argc.
> Therefore the command lines appear corrupted this particular way.
>
>
> /proc/*/cmdline uses a copy of __argc named __argc_safe
> which is hardly to be updated anyway.
> " for (int i = 0; i < __argc_safe; i++) "
>
> Funny enough, /proc/self/cmdline is likely to contain shortened version of
> cmdline:
> " for (char **a = __argv; *a; a++) "
> [ pinfo.cc from cygwin 1.7.9-1 ]
>
>
>
>> I have verified that the "/proc/*/cmdline" is the source of the
>> corrupted information. "cmdline" from PID 2928 is:
>>
>> jc807j@~>od -c /proc/2928/cmdline
>> 0000000 x t e r m \0 \0 2 0 0 0 0 \0 + t b
>> 0000020 \0
>> 0000021
>
>
>
>
>
>
> ----
> What does xterm on different platforms ?
> While concept of modifying own cmdline (In fact, __argv[0]) is used very
> often to signal the process state down to the user,
> I was never thinking of modifying argc:
> main (int argc, char **argv)
> :-)
>
>
> JK
> --
> View this message in context: http://old.nabble.com/-proc-*-cmdline-corrupted-tp32639066p32663265.html
> Sent from the Cygwin list mailing list archive at Nabble.com.
>
>
> --
> Problem reports: http://cygwin.com/problems.html
> FAQ: http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
>
>
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: /proc/*/cmdline corrupted
2011-10-16 23:59 ` Andrew DeFaria
@ 2011-10-17 7:42 ` jan.kolar
2011-10-17 8:30 ` Corinna Vinschen
2011-10-17 8:28 ` Corinna Vinschen
1 sibling, 1 reply; 17+ messages in thread
From: jan.kolar @ 2011-10-17 7:42 UTC (permalink / raw)
To: cygwin
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,
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
the process
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
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: /proc/*/cmdline corrupted
2011-10-16 23:59 ` Andrew DeFaria
2011-10-17 7:42 ` jan.kolar
@ 2011-10-17 8:28 ` Corinna Vinschen
2011-10-17 14:19 ` Christopher Faylor
1 sibling, 1 reply; 17+ messages in thread
From: Corinna Vinschen @ 2011-10-17 8:28 UTC (permalink / raw)
To: cygwin
On Oct 16 16:59, Andrew DeFaria wrote:
> On 10/16/11 14:31, jan.kolar wrote:
> >>jc807j 2668 1 0 08:59 tty0 00:00:00 xterm -e ssh server
> >80x72+285+0 -e ssh server
> >>jc807j 3004 1 0 08:59 tty0 00:00:00 xterm -e ssh server
> >>80x72-8+0 -e ssh server
> >>jc807j 2928 5852 0 09:12 ? 00:00:00 xterm 20000 +tb
> >>The actual command lines for the 3 xterm processes are:
> >>C:\cygwin\bin\xterm.exe -sl 20000 +tb -geometry 80x72+285+0 -e ssh server
> >>C:\cygwin\bin\xterm.exe -sl 20000 +tb -geometry 80x72-8+0 -e ssh server
> >>C:\cygwin\bin\xterm.exe -sl 20000 +tb
> >xterm calls XrmParseCommand() that
> >"parses an (argc, argv) pair according to the specified option table ... and
> >modifies the (argc, argv) pair to remove all recognized options."
> >
> >Therefore
> > "-sl 20000 +tb -geometry 80x72+285+0"
> >is properly removed
> >and "-e ssh server" is moved to __argv[1 .. 3].
> >Then __argv[4] (respectively __argv[1] for the shorter command) is assigned
> >null pointer
> >which results in the second "\0" in the od-output below.
> >
> >
> >HOWEVER:
> >
> >Either XrmParseCommand() does not update argc
> >or the change does not propagate (how would that be possible?) to __argc.
> >Therefore the command lines appear corrupted this particular way.
> >
> >
> >/proc/*/cmdline uses a copy of __argc named __argc_safe
> >which is hardly to be updated anyway.
> >" for (int i = 0; i< __argc_safe; i++) "
> >
> >Funny enough, /proc/self/cmdline is likely to contain shortened version of
> >cmdline:
> >" for (char **a = __argv; *a; a++)"
> >[ pinfo.cc from cygwin 1.7.9-1 ]
> 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?
The content of /proc is generated on the fly at runtime, as soon
as your application (like procps) opens the file in /proc. At exec
time there's no storage for this information since we don't have a
background service running all the time.
To fetch the command line of a process, the opening process has to
connect to the requested process via a bi-directional pipe and send a
request for the command line. In the requested process, a thread
constructs a copy of the __argv array and sends its contents back to the
requesting process through the pipe. THat's the code Jan inspected.
Thet code always scans through the entire __argv array from 0 to __argc
- 1, irrespectively of some __argv[i] being NULL. If some __argv[i] is
NULL or has an invalid pointer value, it is set to an empty string.
This fully explains the output of the procps command. Since XrmParseCommand
changes __argv, but not __argc, the output contains the full number of
arguments, but in the, let's say, "crippled" state it's left when
returning from XrmParseCommand.
This can be easily changed, so that the /proc/$PID/cmdline output stops
as soon as one of the arguments is NULL. That avoids the weird output,
but it has a disadvantage.
On Linux, /proc/$PID/cmdline always contains the full command line as
it has been when the process got started, irrespectively of changes
after process startup. It looks like the loader creates a copy of the
argv array before calling main.
Cygwin doesn't generate a copy of the argv array at startup, so the
processes __argv is the one used to call the main function. And I'm
reluctant to do that since it costs just more time for a process to
start again.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: /proc/*/cmdline corrupted
2011-10-17 7:42 ` jan.kolar
@ 2011-10-17 8:30 ` Corinna Vinschen
0 siblings, 0 replies; 17+ messages in thread
From: Corinna Vinschen @ 2011-10-17 8:30 UTC (permalink / raw)
To: cygwin
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
already.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: /proc/*/cmdline corrupted
2011-10-17 0:17 ` Jon Clugston
@ 2011-10-17 8:34 ` jan.kolar
2011-10-17 10:41 ` jan.kolar
0 siblings, 1 reply; 17+ messages in thread
From: jan.kolar @ 2011-10-17 8:34 UTC (permalink / raw)
To: cygwin
> I've checked and on Linux (at least) xterm's command line is not
> corrupted.
That means: unchanged ?
Or, with -sl 2000 +tb removed ?
A version (!) of xterm on Linux, which does not know +tb option, does not
change cmdline.
> From looking at the xterm code, it would appear that the X
> libraries would have to be what is corrupting the command line. I
> didn't look into the X library (XmParseCommand).
Well, it depends whether it is xterm's intention to change the command line.
(And this would be a topic for cygwin-apps list I think.)
For example sendmail likes to do that (on Linux):
root 3051 sendmail: accepting connections
smmsp 3061 sendmail: Queue runner@00:01:00 for
/var/spool/clientmqueue
root 14631 sendmail: server [1.46.244.248] cmd read
root 15254 sendmail: ./p9CDUban025571 mail3.cae3.com.: user open
entries of sendmail are not nullterminated (!).
Others have set (on Linux) a number of NULL pointers:
0000000 i n i t [ 3 ] \0 \0 \0 \0 \0 \0 \0 \0 \0
\0
0000000 l p d W a i t i n g \0 \0 \0
Hence, XmParseCommand() would do better job if it would zero all unused
argv[index],
not just the first unused one.
---
* On the side of cygwin, the question is
1. whether /proc should show the current content of command line,
that is, what is the standard today.
(I think at least $0 should have the current value, I do not know about
others.)
The "\0 \0 \0" above suggests that the Linux's behavior = cygwin's
behavior.
2. How it should interpret NULL pointers in the array, either
as "for (int i = 0; i < __argc_safe; i++)" or as
"for (char **a = __argv; *a; a++)". Both are present in pinfo.cc.
The "\0 \0 \0" above suggests that the Linux does it the first way.
(Note that the implications of "\0 \0 \0" and other observations are no more
than my speculations, that cannot replace a look at the code. :-) )
--
View this message in context: http://old.nabble.com/-proc-*-cmdline-corrupted-tp32639066p32665348.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: /proc/*/cmdline corrupted
2011-10-17 8:34 ` jan.kolar
@ 2011-10-17 10:41 ` jan.kolar
0 siblings, 0 replies; 17+ messages in thread
From: jan.kolar @ 2011-10-17 10:41 UTC (permalink / raw)
To: cygwin
jan.kolar wrote:
>
> For example sendmail likes to do that (on Linux):
> root 3051 sendmail: accepting connections
> smmsp 3061 sendmail: Queue runner@00:01:00 for
> /var/spool/clientmqueue
> root 14631 sendmail: server [1.46.244.248] cmd read
> root 15254 sendmail: ./p9CDUban025571 mail3.cae3.com.: user
> open
> entries of sendmail are not nullterminated (!).
> Others have set (on Linux) a number of NULL pointers:
> 0000000 i n i t [ 3 ] \0 \0 \0 \0 \0 \0 \0 \0
> \0 \0
> 0000000 l p d W a i t i n g \0 \0 \0
>
This was on
Linux host.a.b.c. 2.6.18-194.26.1.el5-ipx #1 SMP Wed Dec 8 20:08:05 CET 2010
x86_64 x86_64 x86_64 GNU/Linux
Corinna Vinschen-2 wrote
> On Linux, /proc/$PID/cmdline always contains the full command line as
> it has been when the process got started, irrespectively of changes
> after process startup. It looks like the loader creates a copy of the
> argv array before calling main.
Yes, I agree. A simple C program behaves like that. I did not know how
exactly
sendmail, lpd, init and other achieve the change.
Also perl allows to set $0 with appropriate effect (but not $1).
So, Q: how they do that ? A:" It depends " :-)
See
http://cvs.rutgers.edu/cgi-bin/viewvc.cgi/tags/start/postman1.11/PsTitle.cc?revision=1806&view=markup
where (probably) cygwin is SPT_CHANGEARGV and Linux is SPT_REUSEARGV.
(And blind xterm modifies its command line in the case SPT_CHANGEARGV.
Do the same other programs using XmParseCommand(), or do they first
make a working copy of argv pointer array?)
This works on Linux to change /proc/<cmd>/cmdline:
main (int argc, char **argv)
{ int i;
argv[0][0]='A';
for (i=1; i<argc; i++) argv[i][0]= 'A'+i ; // ! bad for
"", much bad if last arg is ""
sleep(30); }
./a.out 1 2 3 4 5 &
ps -fC a.out
A/a.out B C D E F
Thanks for the timeout on proc-IPC !
JK
--
View this message in context: http://old.nabble.com/-proc-*-cmdline-corrupted-tp32639066p32666054.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: /proc/*/cmdline corrupted
2011-10-17 8:28 ` Corinna Vinschen
@ 2011-10-17 14:19 ` Christopher Faylor
2011-10-17 15:54 ` jan.kolar
0 siblings, 1 reply; 17+ messages in thread
From: Christopher Faylor @ 2011-10-17 14:19 UTC (permalink / raw)
To: cygwin
On Mon, Oct 17, 2011 at 10:27:18AM +0200, Corinna Vinschen wrote:
>On Linux, /proc/$PID/cmdline always contains the full command line as
>it has been when the process got started, irrespectively of changes
>after process startup. It looks like the loader creates a copy of the
>argv array before calling main.
You can change the contents of what __argv[n] points to to modify what
/proc/<pid>/cmdline displays though.
i.e.,
strcpy (__argv[1], "a");
That's pretty risky though.
>Cygwin doesn't generate a copy of the argv array at startup, so the
>processes __argv is the one used to call the main function. And I'm
>reluctant to do that since it costs just more time for a process to
>start again.
Just creating a copy of argv without copying what it points to should be
pretty inexpensive. It's too bad that we export __argv and __argc. I
don't see Linux doing anything like that and it seems like a way for
a Cygwin program to cause mischief.
cgf
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: /proc/*/cmdline corrupted
2011-10-17 14:19 ` Christopher Faylor
@ 2011-10-17 15:54 ` jan.kolar
0 siblings, 0 replies; 17+ messages in thread
From: jan.kolar @ 2011-10-17 15:54 UTC (permalink / raw)
To: cygwin
Christopher Faylor-8 wrote:
>
> On Mon, Oct 17, 2011 at 10:27:18AM +0200, Corinna Vinschen wrote:
>>On Linux, /proc/$PID/cmdline always contains the full command line as
>>it has been when the process got started, irrespectively of changes
>>after process startup. It looks like the loader creates a copy of the
>>argv array before calling main.
>
> You can change the contents of what __argv[n] points to to modify what
> /proc/<pid>/cmdline displays though.
>
> i.e.,
>
> strcpy (__argv[1], "a");
>
> That's pretty risky though.
>
>>Cygwin doesn't generate a copy of the argv array at startup, so the
>>processes __argv is the one used to call the main function. And I'm
>>reluctant to do that since it costs just more time for a process to
>>start again.
>
> Just creating a copy of argv without copying what it points to should be
> pretty inexpensive. It's too bad that we export __argv and __argc. I
> don't see Linux doing anything like that and it seems like a way for
> a Cygwin program to cause mischief.
>
> cgf
>
> --
> Problem reports: http://cygwin.com/problems.html
> FAQ: http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
>
>
>
See the previous post about Linux:
http://cygwin.com/ml/cygwin/2011-10/msg00314.html
And for the hell of possible solution see the link from that post:
http://cvs.rutgers.edu/cgi-bin/viewvc.cgi/tags/start/postman1.11/PsTitle.cc?revision=1806&view=markup
--
View this message in context: http://old.nabble.com/-proc-*-cmdline-corrupted-tp32639066p32668296.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: /proc/*/cmdline corrupted
2011-10-13 18:02 ` Jon Clugston
2011-10-13 18:14 ` Andrew DeFaria
@ 2011-10-17 16:47 ` jan.kolar
2011-10-17 23:29 ` Jon Clugston
1 sibling, 1 reply; 17+ messages in thread
From: jan.kolar @ 2011-10-17 16:47 UTC (permalink / raw)
To: cygwin
> Jon Clugston wrote:
> I tried to reproduce by creating long command lines to other commands
> and none were corrupted.
I tried two now.
The first one turned out to be a script around xterm. :-(
The second fails the test:
xwininfo.exe -display :0 -children &
>>> tty0 00:00:00 xwininfo -children -children
The third fails as well:
xcalc -bg blue -fg green &
>>> tty0 00:00:00 xcalc blue -fg green
> Does "xterm" step on its command line?
If it can it does. Now (!sorry) I remember seeing that in nineties.
--
View this message in context: http://old.nabble.com/-proc-*-cmdline-corrupted-tp32639066p32668723.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: /proc/*/cmdline corrupted
2011-10-17 16:47 ` jan.kolar
@ 2011-10-17 23:29 ` Jon Clugston
0 siblings, 0 replies; 17+ messages in thread
From: Jon Clugston @ 2011-10-17 23:29 UTC (permalink / raw)
To: cygwin
On Mon, Oct 17, 2011 at 12:47 PM, jan.kolar <kolar@math.cas.cz> wrote:
>
>
>> Jon Clugston wrote:
>> I tried to reproduce by creating long command lines to other commands
>> and none were corrupted.
> I tried two now.
> The first one turned out to be a script around xterm. :-(
> The second fails the test:
> xwininfo.exe -display :0 -children &
>>>> tty0 00:00:00 xwininfo -children -children
>
> The third fails as well:
> xcalc -bg blue -fg green &
>>>> tty0 00:00:00 xcalc blue -fg green
>
>
>> Does "xterm" step on its command line?
> If it can it does. Now (!sorry) I remember seeing that in nineties.
From some light code inspection on my part and more thorough
investigation from others here, it seems to be the X libraries
mangling the command lines of any X program that calls them (when they
use common parameters). I would say this is a bug in the X libraries.
I wouldn't expect cygwin to try to prevent this dubious practice by
application code.
Jon
> --
> View this message in context: http://old.nabble.com/-proc-*-cmdline-corrupted-tp32639066p32668723.html
> Sent from the Cygwin list mailing list archive at Nabble.com.
>
>
> --
> Problem reports: http://cygwin.com/problems.html
> FAQ: http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
>
>
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2011-10-17 23:29 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-10-12 15:08 /proc/*/cmdline corrupted Jon Clugston
2011-10-13 12:56 ` jan.kolar
2011-10-13 13:02 ` Christopher Faylor
2011-10-13 18:02 ` Jon Clugston
2011-10-13 18:14 ` Andrew DeFaria
2011-10-17 16:47 ` jan.kolar
2011-10-17 23:29 ` Jon Clugston
2011-10-16 21:31 ` jan.kolar
2011-10-16 23:59 ` Andrew DeFaria
2011-10-17 7:42 ` jan.kolar
2011-10-17 8:30 ` Corinna Vinschen
2011-10-17 8:28 ` Corinna Vinschen
2011-10-17 14:19 ` Christopher Faylor
2011-10-17 15:54 ` jan.kolar
2011-10-17 0:17 ` Jon Clugston
2011-10-17 8:34 ` jan.kolar
2011-10-17 10:41 ` jan.kolar
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).