Jeff, Roland Mainz wrote a more sophisticated command substitution test case, which can be found at http://svn.nrubsig.org/svn/people/gisburn/scripts/tests/sun_solaris_command_substitution.sh This might help with tracking this issue.
Olga On Wed, Sep 5, 2012 at 3:18 PM, FELLIN, JEFFREY K (JEFF) <j...@research.att.com> wrote: > A similar problem to this was reported earlier this month by Alex Beylin in > the official UWIN 5.0 release (2012-08-06). The problem was corrected and the > fix is in Beta release 2012-08-20. > > I have verified the fix also corrects this reported problem. > > $ runcmd "ksh -c /tmp/rep.ksh" > /tmp/rep.ksh > hello all > $ uname -a > UWIN-XP dt-Fellin 5.0/5.1 2012-08-20 i686 x86 32/32 UWIN > > Jeff fellin > > -----Original Message----- > From: uwin-users-boun...@research.att.com > [mailto:uwin-users-boun...@research.att.com] On Behalf Of Jon Pile > Sent: Tuesday, September 04, 2012 23:41 > To: uwin-users@research.att.com > Subject: [uwin-users] Deadlock in $( foo | bar ) > > Hi all, > > Thanks again for making UWIN useful. Sorry that I only talk to the list with > bug reports. Here we go again... > > I've been running into a deadlock with spawned ksh scripts, but it took me > some time to isolate a reproduction that didn't depend on a ton of layered > "dmake" nonsense. I think I finally got it. :) > > The reproduction is fussy to describe but seems reliable. I first noted it > with the 2012-02-29 release, but it exists in the version I am using today: > > $ uname -a > UWIN-W7 jpile-w510 5.0/6.1 2012-08-06 i686-64 x64 64/64 UWIN > > The problem arises when a ksh instance - started by CreateProcess(), not a > login shell - runs a "#!/bin/ksh" script that in turn uses a pipe within a > $(...) -spawned subshell. > > The following script should demonstrate the problem. > -------- K:\>cat \tmp\rep.ksh > #!/bin/ksh -p > > print $0 > # Hangs on the next line: never prints "hello all". > str=$(echo "hello world"| sed "s/world/all/" ) > print $str > -------- > > Running this from within a UWIN login shell does the expected: > ---- > $ /tmp/rep.ksh > /tmp/rep.ksh > hello all > $ ksh -c /tmp/rep.ksh > /tmp/rep.ksh > hello all > ---- > > However, here are two ways to cause the deadlock. One, within a ksh login > shell, use the 'runcmd' tool: > ---- > $ runcmd "ksh -c /tmp/rep.ksh" > /tmp/rep.ksh > > ---- > > Two, run from the Windows command prompt: > ---- > K:\>ksh -c "/tmp/rep.ksh args blah" > /tmp/rep.ksh > > ---- > > I initially noted this in our weird build system - we invoke many short bits > of ksh from within WTI dmake (which uses CreateProcess in a very similar way > to runcmd). > > When ksh is hung, procexp64 shows the following: > > cmd.exe > +- ksh.exe > Command line: ksh -c "/tmp/rep.ksh args blah" > +- ksh.exe > Command line: /bin/ksh -p /tmp/rep.ksh args blah > > > The following are the active threads in the child-most ksh instance. I don't > have debug symbols for posix.dll handy, so the debugger has so far been an > exercise in futility. > > "ksh.exe": > ntdll.dll!ZwWaitForSingleObject+0xa > KERNELBASE.dll!WaitForSingleObjectEx+0x9c > POSIX.dll!setgid+0x991 > POSIX.dll!read+0x149 > shell11.dll!sh_subfork+0x199e > shell11.dll!sh_subfork+0x39bf > shell11.dll!sh_subfork+0x3be7 > shell11.dll!sh_exec+0x216b > shell11.dll!sh_exec+0x305e > shell11.dll!sh_subfork+0xff6 > shell11.dll!sh_waitsafe+0x8f7b > shell11.dll!sh_waitsafe+0x483b > shell11.dll!sh_waitsafe+0x784f > shell11.dll!sh_waitsafe+0x83be > shell11.dll!nv_unset+0x19f > shell11.dll!sh_exec+0x9a7 > shell11.dll!b_test+0x12d5 > shell11.dll!sh_main+0x69e > ksh.exe+0x1541 > kernel32.dll!BaseThreadInitThunk+0xd > ntdll.dll!RtlUserThreadStart+0x21 > > "POSIX.dll!raise" > ntdll.dll!ZwDelayExecution+0xa > KERNELBASE.dll!SleepEx+0xb3 > POSIX.dll!raise+0x78f > kernel32.dll!BaseThreadInitThunk+0xd > ntdll.dll!RtlUserThreadStart+0x21 > > "POSIX.dll!uwin_nt2unixpid" > ntdll.dll!NtWaitForMultipleObjects+0xa > KERNELBASE.dll!GetCurrentThread+0x36 > kernel32.dll!WaitForMultipleObjectsEx+0xb3 > USER32.dll!PeekMessageW+0x1cd > USER32.dll!MsgWaitForMultipleObjectsEx+0x2a > USER32.dll!MsgWaitForMultipleObjects+0x20 > POSIX.dll!seteuid+0x203e > POSIX.dll!uwin_nt2unixpid+0x45e2 > kernel32.dll!BaseThreadInitThunk+0xd > ntdll.dll!RtlUserThreadStart+0x21 > > "POSIX.dll!sigset" > ntdll.dll!NtWaitForMultipleObjects+0xa > KERNELBASE.dll!GetCurrentThread+0x36 > kernel32.dll!WaitForMultipleObjects+0xb0 > POSIX.dll!sigset+0x9bf > kernel32.dll!BaseThreadInitThunk+0xd > ntdll.dll!RtlUserThreadStart+0x21 > > "POSIX.dll!grantpt" > ntdll.dll!ZwWaitForSingleObject+0xa > KERNELBASE.dll!WaitForSingleObjectEx+0x9c > POSIX.dll!grantpt+0x8fd > kernel32.dll!BaseThreadInitThunk+0xd > ntdll.dll!RtlUserThreadStart+0x21 > > "POSIX.dll!brk" > ntdll.dll!NtReadFile+0xa > KERNELBASE.dll!ReadFile+0x7a > kernel32.dll!ReadFile+0x59 > POSIX.dll!tcsetpgrp+0x5dca > POSIX.dll!brk+0x2f02 > kernel32.dll!BaseThreadInitThunk+0xd > ntdll.dll!RtlUserThreadStart+0x21 > > Let me know if I left out anything useful. > > -jP > _______________________________________________ > uwin-users mailing list > uwin-users@research.att.com > https://mailman.research.att.com/mailman/listinfo/uwin-users > _______________________________________________ > uwin-users mailing list > uwin-users@research.att.com > https://mailman.research.att.com/mailman/listinfo/uwin-users -- , _ _ , { \/`o;====- Olga Kryzhanovska -====;o`\/ } .----'-/`-/ olga.kryzhanov...@gmail.com \-`\-'----. `'-..-| / http://twitter.com/fleyta \ |-..-'` /\/\ Solaris/BSD//C/C++ programmer /\/\ `--` `--` _______________________________________________ uwin-users mailing list uwin-users@research.att.com https://mailman.research.att.com/mailman/listinfo/uwin-users
