build_monitor.exe: a cure worse than the disease
I have NO idea what criteria build_monitor uses to killing processes, but when I awoke this morning, it had managed to kill: the dnet "run in the background" ORG process, Pirch (my IRC client), a proxy that lets me get dcc's through my hardware firewall, Trillian (the instant message program), SpyBot resident..... I think you get the picture. this thing just walked through my system like a hoard of Vandals (or was it Visigoths). whatever DO NO RUN THIS PROGRAM ON YOUR SYSTEM UNTIL IT'S FIXED my results will be delayed as a result of my stopping the -monitored tests because I'll have to manually click through the modal dialogs (may their creator roast in hell) so the tests will finish. Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
On Sun, 01 Aug 2004 13:13:38 -0700, Victor A. Wagner Jr. wrote
I have NO idea what criteria build_monitor uses to killing processes, but when I awoke this morning, it had managed to kill: the dnet "run in the background" ORG process, Pirch (my IRC client), a proxy that lets me get dcc's through my hardware firewall, Trillian (the instant message program), SpyBot resident..... I think you get the picture. this thing just walked through my system like a hoard of Vandals (or was it Visigoths). whatever
DO NO RUN THIS PROGRAM ON YOUR SYSTEM UNTIL IT'S FIXED
my results will be delayed as a result of my stopping the -monitored tests because I'll have to manually click through the modal dialogs (may their creator roast in hell) so the tests will finish.
Might I suggest removing the teststreams test from the date-time Jamfile that is stopping everything? From my perspective we've already established that there is some sort of bug in the vc8 beta causing that one... Jeff
At Sunday 2004-08-01 13:56, you wrote:
On Sun, 01 Aug 2004 13:13:38 -0700, Victor A. Wagner Jr. wrote
I have NO idea what criteria build_monitor uses to killing processes, but when I awoke this morning, it had managed to kill: the dnet "run in the background" ORG process, Pirch (my IRC client), a proxy that lets me get dcc's through my hardware firewall, Trillian (the instant message program), SpyBot resident..... I think you get the picture. this thing just walked through my system like a hoard of Vandals (or was it Visigoths). whatever
DO NO RUN THIS PROGRAM ON YOUR SYSTEM UNTIL IT'S FIXED
my results will be delayed as a result of my stopping the -monitored tests because I'll have to manually click through the modal dialogs (may their creator roast in hell) so the tests will finish.
Might I suggest removing the teststreams test from the date-time Jamfile that is stopping everything? From my perspective we've already established that there is some sort of bug in the vc8 beta causing that one...
I'll do that....when I find the relevant line I still think the warning that it removes other programs is important for others to know. It wasn't that I _lost_ anything staggeringly important, and it only took a re-boot for all my things to start running again, but it WAS irritating. OK, I think I found it, we'll see how this run goes unmonitored
Jeff _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
On Sun, 01 Aug 2004 13:13:38 -0700, Victor A. Wagner Jr. <vawjr@rudbek.com> wrote:
my results will be delayed as a result of my stopping the -monitored tests because I'll have to manually click through the modal dialogs (may their creator roast in hell) so the tests will finish.
FWIW, it is possible to avoid ever displaying the dialog boxes that you see, by installing an exception filter. LONG CALLBACK exception_filter_function(EXCEPTION_POINTERS*) { std::cout << "Crash!" << std::endl; } // ... SetUnhandledExceptionFilter(&exception_filter_function); I'm quite certain that Gennadiy's testing framework already does this, and outputs a diagnostic message to stderr/stdout instead of popping up windows. /Mattias
At Sunday 2004-08-01 16:38, you wrote:
On Sun, 01 Aug 2004 13:13:38 -0700, Victor A. Wagner Jr. <vawjr@rudbek.com> wrote:
my results will be delayed as a result of my stopping the -monitored tests because I'll have to manually click through the modal dialogs (may their creator roast in hell) so the tests will finish.
FWIW, it is possible to avoid ever displaying the dialog boxes that you see, by installing an exception filter.
LONG CALLBACK exception_filter_function(EXCEPTION_POINTERS*) { std::cout << "Crash!" << std::endl; } // ... SetUnhandledExceptionFilter(&exception_filter_function);
I'm quite certain that Gennadiy's testing framework already does this, and outputs a diagnostic message to stderr/stdout instead of popping up windows.
I can assure you that it doesn't work on the teststreams error in VCV8.0
/Mattias _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
Victor A. Wagner Jr. wrote in news:6.1.2.0.2.20040801130827.05d83938@mail.rudbek.com in gmane.comp.lib.boost.devel:
I have NO idea what criteria build_monitor uses to killing processes, but when I awoke this morning, it had managed to kill: the dnet "run in the background" ORG process, Pirch (my IRC client), a proxy that lets me get dcc's through my hardware firewall, Trillian (the instant message program), SpyBot resident..... I think you get the picture. this thing just walked through my system like a hoard of Vandals (or was it Visigoths). whatever
DO NO RUN THIS PROGRAM ON YOUR SYSTEM UNTIL IT'S FIXED
my results will be delayed as a result of my stopping the -monitored tests because I'll have to manually click through the modal dialogs (may their creator roast in hell) so the tests will finish.
Their creator did at least write a manual :). <http://msdn.microsoft.com/library/default.asp?url=/library/en- us/debug/base/seterrormode.asp> http://tinyurl.com/4sq3j The real problem is we write command line programms for *nix and then expect them to work just the same in windows. Driver programme: #include <cstdlib> #include <windows.h> int main() { UINT previous = SetErrorMode( SEM_NOGPFAULTERRORBOX ); std::system( "segfault.exe" ); SetErrorMode( previous ); } segfault.exe: #include <iostream> int main() { int p = 0; // int *p = 0; std::cout << "segfault\n"; std::cout.flush(); return 1 / p; // return *p; } Assuming bjam doesn't call SetErrorMode( 0 ) itself, then as the error mode is "inherited" you shouldn't get any more popups. I suggest rewriting the "Driver" programme above to invoke bjam or whatever it is that invokes bjam. If a python version is more convenient: import sys, os _nowin32api = True if sys.platform[ : 3 ] == 'win': SEM_NOGPFAULTERRORBOX = 0x0002 try: import win32api _nowin32api = False class _error_mode( object ): def __init__( self ): self.mode = win32api.SetErrorMode( SEM_NOGPFAULTERRORBOX ) def restore( self ): win32api.SetErrorMode( self.mode ) pass except ImportError: print >> sys.stderr, "Warning win32 and no win32api (beware popups)" if _nowin32api: class _error_mode( object ): def restore( self ): pass pass def open_command( cmd, open = os.system ): """ does: wrapper for os.system, avoid's popups on win32 """ try: emode = _error_mode() result = open( cmd ) finally: emode.restore() return result if __name__ == '__main__': open_command( 'segfault.exe' ) print 'Ok' win32api is here: http://starship.python.net/crew/mhammond/win32/Downloads.html Rob. -- http://www.victim-prime.dsl.pipex.com/
Rob Williscroft writes:
Their creator did at least write a manual :).
<http://msdn.microsoft.com/library/default.asp?url=/library/en- us/debug/base/seterrormode.asp>
The dialog boxes are just a part of the problem (not to mention that GPF dialogs are far from being the only ones that are displayed by misbehaving tests). The test/compiler can simply hang or just run for too long. Monitoring is the only way to handle all the issues. -- Aleksey Gurtovoy MetaCommunications Engineering
participants (5)
-
Aleksey Gurtovoy -
Jeff Garland -
Mattias Flodin -
Rob Williscroft -
Victor A. Wagner Jr.