Re: Patches Applied for 21.1.8

Craig> At 06:38 PM 10/23/99 +0200, Adrian Aichner wrote: >> Craig> At 03:40 PM 10/23/99 +0200, Adrian Aichner wrote: >> >> 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 Craig> -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(). Craig> According to the documentation that I have the function GetVersion is Craig> 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 Craig> 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: Well, seems like we are getting somewhere! Craig> 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. Craig> This does bad things to Win98 (no interprocess protection). Craig> (As a side note, you should be aware that when a CPU Craig> intensive task in running on Win 95/98 the system becomes Craig> sluggish to the user.) That's good to know. You say that the individual tests return correct exit status? Does minitar work now (pui-list-packages & Install)? Are you not getting the STDERR messages saying something like the following? Fcall_process_internal.child_setup returns PID 100, using PID -100 Anyway ..., since I have conditionalized everything on os_subtype now, we seem to be OK, even though your system might deduce the incorrect subtype right now, due to building on MINGW32. The unqualified negation of pid if (cp->pid < 0) cp->pid = - cp->pid; was that haunting culprit! I didn't even realize you're building for MINGWIN32 ;-> Could you send a build-report please? Can be done like this: M-x customize-group RET build-report RET M-x build-report RET Cheers, Adrian PS: Would you be willing to test a formal patch against latest 21.1.7 CVS sources? Do you have access via CVS? I have written a lisp package to build XEmacs from within. It's called, SURPRISE, build. Latest Installed Package name Vers. Vers. Description =============================================================================== <lines deleted by Adrian> build 1.45 1.45 Build XEmacs from within (for UNIX, Windows). -rw-rw-rw- 1 AichnerAd 5 25047 Aug 19 14:43 build-1.45-pkg.tar.gz Craig> The individual calls to call-process worked just fine so I Craig> decided to give it your stress test. I started the Craig> (dotimes ...) and things seemed to be working fine. You Craig> had asked that I do things while this is running so I Craig> started iconifying and deiconifying programs, when suddenly Craig> the blue screen of death appeared. It complained that Craig> Window's resources were low and asked me if I wanted to Craig> kill a particular program. The BSoD appeared several more Craig> times, each time asking about a different program. The Craig> first program was Explorer. Others were XEmacs, grep, and Craig> one of the items in the System Tray. Craig> This sounds like something is not being returned to the OS. Craig> Craig