Re: Patches Applied for 21.1.8

Craig> Yes, the individual tests did return the correct status. Good! Craig> minitar seemed to be OK. However, I just tried updating Craig> some of the packages and there are problems. It downloaded Craig> the scheme package and failed during the install. I killed Please send me (and xemacs-beta) any error messages you get anywhere. Craig> XEmacs, but the shell is still waiting for it to exit. The Set Options -> General Options -> Debug On Error Try installing the package again and send us *Backtrace* if you get one. Craig> following lines were printed to STDERR: Craig> C:...XEmacs/21-2-b19/bin> xemacs Craig> create_child.CreateProcess abs(PID) -880217 > EMACS_INT_MAX (2147483647) Hmmh, how often do you get the above warning? Does it occur for every (call-process ...) or just for the minitar process? Craig> Fatal error: assertion failed, file console.h, line 422, RECORD_TYPEP (obj, Craig> &lrecord_console) || MARKED_RECORD_P (obj) Error checking for a console lrecord failed above assertion. Maybe Andy knows what goes on here? Craig> No. It's pretty clear at this point that MINGW32 cannot distingush a WindowsNT- form a Windows9[58] system. Andy might come up with a solution for this, let's see. Craig> I have access to CVS (that's what I have been using), Craig> however, I can't build 21.1.x because Andy's patches to Craig> support mingw32 builds are only in the 21.2.x tree. OK 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. Hmmh, only wait_for_termination gets a process handle. Fcall_process_internal has this suspicious little comment atend: /* Don't kill any children that the subprocess may have left behind when exiting. */ call_process_exited = 1; unbind_to (speccount, Qnil); Could this be the problem? Also call_process_cleanup will NOT call wait_for_termination if call_process_exited is true. In that case the handle may be hanging around. I'll try to CloseHandle it at the end of Fcall_process_internal if it's still open. Thanks for the feedback! Adrian Craig> Craig