At 06:38 PM 10/23/99 +0200, Adrian Aichner wrote:
>>>>> "Craig" == Craig Lanning
<CraigL(a)DyCon.com> writes:
Craig> At 03:40 PM 10/23/99 +0200, Adrian Aichner wrote:
>>>>>>> "Craig" == Craig Lanning
<CraigL(a)DyCon.com> writes:
>>
Craig> create_child: exe=c:\BIN32\ls.exe,cmdline=c:\BIN32\ls.exe
>>
Craig> create_child.CreateProcess leads child PID -725391,
Craig> changing to PID 725391 Fatal error: assertion failed, file
Craig> sysdep.c, line 353, pid != NULL
>>
>> Hi Craig,
>>
>> did you ever see a message like:
>>
>> Fcall_process_internal.child_setup returns PID 725391, using PID
-725391
Craig> No, I sent you all the messages that were printed.
Hmmh, beats me ...
>> If not, then
>> if (os_subtype == OS_WIN95)
>> would not be true for Windows 98. That would be a problem!
Craig> How is os_subtype set? Maybe I can figure out what it is
Craig> for Win98.
See src/ntheap.c. It uses a SDK system information function called
GetVersion().
According to the documentation that I have the function GetVersion is
considered obsolete. It recommends the use of GetVersionEx instead.
If this hunk against callproc.c (part of the patch I just sent) does
not produce any output (to the DOS box you started src\xemacs.exe
from), then the os_subtype test is wrong:
#ifdef WINDOWSNT
pid = child_setup (filefd, fd1, fd_error, new_argv,
(char *) XSTRING_DATA (current_dir));
+ /* OpenProcess() as soon after child_setup as possible. It's too
+ late once the process terminated. */
+ if (os_subtype == OS_WIN95)
+ {
+ stderr_out ("Fcall_process_internal.child_setup returns PID %d, using
PID
%d\n", pid, -pid);
+ /* create_child() in ntproc.c hacks PIDs for OS_WIN95 to fit
+ into Lisp_Int, i.e. negates them. Hence we have to use -pid
+ to get at the real PID for OS_WIN95. */
+ pHandle = OpenProcess(PROCESS_ALL_ACCESS, 0, -pid);
+ }
+ else
I'll take out that message if all works out well.
If you have cygnus grep, please try this test-case if things work out:
I have a Win32 compiled version of grep (non-cygwin).
(dotimes (i 200 "grep test passed")
(unless
(= 2 (apply 'call-process "grep" nil '(t nil) nil
(list "drivers" "c:\winnt\system.ini")))
(error "Incorrect call-process return value!")))
While the test is running please act unnatural. Move other
applications like a madman, start cpu-intensive processes, and the
like. This should check whether there's any danger the process goes
away before we can obtain a handle for it. I haven't seen problems
with this in recent versions of my patches on NT.
This does bad things to Win98 (no interprocess protection). (As a side
note, you should be aware that when a CPU intensive task in running on Win
95/98 the system becomes sluggish to the user.)
The individual calls to call-process worked just fine so I decided to give
it your stress test. I started the (dotimes ...) and things seemed to be
working fine. You had asked that I do things while this is running so I
started iconifying and deiconifying programs, when suddenly the blue screen
of death appeared. It complained that Window's resources were low and
asked me if I wanted to kill a particular program. The BSoD appeared
several more times, each time asking about a different program. The first
program was Explorer. Others were XEmacs, grep, and one of the items in
the System Tray.
This sounds like something is not being returned to the OS.
Craig