Changes between Initial Version and Version 1 of Ticket #143, comment 11


Ignore:
Timestamp:
Feb 20, 2017, 11:20:43 PM (8 years ago)
Author:
dmik

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #143, comment 11

    initial v1  
    1 I'm reopening this as it turned out that the problem described in #204 is actually a regression of the above fork to popen change. The thing is that passing a --pipe portion for the --last popt option to `popen()`in the form of `sh -c "BLAHBLAH"` makes sh expand $0, $1 and some escape shars there which breaks sh syntax as well as awk invocation (which expects $0 and $1 to be its own args). The unexpected expansion happens `popen` actually already uses sh to execute what it is given, so it turns out to `sh -c "sh -c "BLAHBLAH""` hence the expansion. It could be fixed by removing `sh -c` from a `popen` call and relying on the fact that the user has EMXSHELL set to `sh`, not to `cmd.exe` but it has its pitfalls and I also looked closer at why `fork` failed in the first place.
     1I'm reopening this as it turned out that the problem described in #204 is actually a regression of the above fork to popen change. The thing is that passing the --pipe portion for the --last popt option to `popen()`in the form of `sh -c "BLAHBLAH"` makes sh expand $0, $1 and some escape shars there which breaks sh syntax as well as awk invocation (which expects $0 and $1 to be its own args). The unexpected expansion happens `popen` actually already uses sh to execute what it is given, so it turns out to `sh -c "sh -c "BLAHBLAH""` hence the expansion. It could be fixed by removing `sh -c` from a `popen` call and relying on the fact that the user has EMXSHELL set to `sh`, not to `cmd.exe` but it has its pitfalls and I also looked closer at why `fork` failed in the first place.
    22
    33Unfortunately, the fix from ​http://trac.netlabs.org/libc/ticket/363 was not enough here. It turned out that the problem was not in RPM and not even in the fork implementation but in a fact that RPM statically links against NSS3.DLL which in turn dynamically loads SOFTOKN3.DLL at NSS init time and this is done by PR_LoadLibrary from NSPR which in turn uses DosLoadModule directly instead of `dlopen` from kLIBC and this breaks fork machinery because modules loaded by DosLoadModule directly are not properly set up for forking and at the time when the fork child process copies its data segments from its parent it ends up copying the SOFTOKN3.DLL segment to a memory location that hasn't been allocated in the child (due to a missing `dlopen` call). This would result in XCPT_ACCESS_VIOLATION while doing fork which would eventually cause the child to abort with LIBC PANIC 0xfffffffc (which means -EINTR emitted by the fatal error handler). Pretty hairy chain of events, huh.