Re: [Python-Dev] Test failures under Windows?
Right, my question to microsoft was more about making sure that a __crtMessageBox() actually does nothing, when running unattended as a service. Also, we should be seeing the same problem in non-debug versions, since the _set_invalid_parameter_handler() is no longer called, and the default one also puts up a message box. The Assertion is then performed _in_addition_ on debug builds: From ms-help://MS.VSCC.v80/MS.MSDN.v80/MS.VisualStudio.v80.en/dv_vccrt/html/c0e67934-1a41-4016-ad8e-972828f3ac11.htm In the following example, an invalid parameter error handler is used to print the function that received the invalid parameter and the file and line in CRT sources. When the debug CRT library is used, invalid parameter errors also throw an assertion, which is disabled in this example using _CrtSetReportMode. Btw, I am working on finding out the test suite failures for test_multiprocessing. K -Original Message- From: Curt Hagenlocher [mailto:c...@hagenlocher.org] Sent: 25. mars 2009 12:54 To: Kristján Valur Jónsson Cc: mhamm...@skippinet.com.au; David Bolen; python-dev@python.org Subject: Re: [Python-Dev] Test failures under Windows? 2009/3/25 Kristján Valur Jónsson krist...@ccpgames.com: I'm going to poke my contacts at Microsoft and ask them if there is a way to disable popups like this for a process that runs unattended and/or is running as a windows service. MSVC has shipped with runtime library source since the 16-bit days, so the easier thing is just to read the source code. :) It looks like there are two possible code paths for the assertion. The first code path uses functions in dbgrpt[t].c and its behavior is controlled by CrtSetReportMode and CrtSetReportFile. The second uses functions in assert.c and its behavior is controlled by _set_error_mode. Both code paths use __crtMessageBox in crtmbox.c to actually display the message box. This function -- when running as a service -- will helpfully set MB_SERVICE_NOTIFICATION before calling the USER32 MessageBox, which ensures that you'll see exactly why your service has hung the next time you actually log in with sufficient rights. :/ The variation that goes through assert.c should write to stderr for a console-mode application, so it's reasonable to assume that we're hitting the other code path -- and that Mark's suggestion to use CrtSetReportMode would address the issue. -- Curt Hagenlocher c...@hagenlocher.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
Kristján Valur Jónsson wrote: Btw, I am working on finding out the test suite failures for test_multiprocessing. Some of those are caused by force builds on a branch, so make sure the errors are still occurring before you put too much effort into this. We made the branch before some recent fixes to the py3k branch. But of course there may still be errors that exist. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
Kristján Valur Jónsson krist...@ccpgames.com writes: Btw, I am working on finding out the test suite failures for test_multiprocessing. This is all well and good, but I still haven't seen any plausible reason for not preventing these popups (in favor of stderr failures) during buildbot test runs? I don't get it - it just seems a no brainer to help protect the Windows buildbots. Surely there may be similar issues down the road that also introduce the potential for assertions? I guess I'll stop asking after this note, but can anyone give a final verdict on whether the older -n option can be restored to the buildbot test.bat (from the revision history I'm not actually sure it was intentionally removed in the first place)? Unlike normal Windows popups I can't protect against it easily through local modifications to my build slave, since test.bat gets updated as part of the source tree. -- David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
On Tue, Mar 31, 2009 at 4:07 PM, David Bolen db3l@gmail.com wrote: Kristján Valur Jónsson krist...@ccpgames.com writes: Btw, I am working on finding out the test suite failures for test_multiprocessing. This is all well and good, but I still haven't seen any plausible reason for not preventing these popups (in favor of stderr failures) during buildbot test runs? I don't get it - it just seems a no brainer to help protect the Windows buildbots. Surely there may be similar issues down the road that also introduce the potential for assertions? I guess I'll stop asking after this note, but can anyone give a final verdict on whether the older -n option can be restored to the buildbot test.bat (from the revision history I'm not actually sure it was intentionally removed in the first place)? Unlike normal Windows popups I can't protect against it easily through local modifications to my build slave, since test.bat gets updated as part of the source tree. -- David I guess I missed the multiprocessing part of this discussion, but in any case, see bug: http://bugs.python.org/issue5619 - once Martin and I review it, it should be in trunk and elsewhere as needed. -jesse ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
2009/3/31 Kristján Valur Jónsson krist...@ccpgames.com: Right, my question to microsoft was more about making sure that a __crtMessageBox() actually does nothing, when running unattended as a service. Also, we should be seeing the same problem in non-debug versions, since the _set_invalid_parameter_handler() is no longer called, and the default one also puts up a message box. The Assertion is then performed _in_addition_ on debug builds: From ms-help://MS.VSCC.v80/MS.MSDN.v80/MS.VisualStudio.v80.en/dv_vccrt/html/c0e67934-1a41-4016-ad8e-972828f3ac11.htm In the following example, an invalid parameter error handler is used to print the function that received the invalid parameter and the file and line in CRT sources. When the debug CRT library is used, invalid parameter errors also throw an assertion, which is disabled in this example using _CrtSetReportMode. Btw, I am working on finding out the test suite failures for test_multiprocessing. K I spoke to Martin about this yesterday, apparently a specific test in the multiprocessing suite was triggering these dialogs (the test invalid handle test). We're working on a patch for multiprocessing so that the children will obey the flag -jesse ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
I found a different problem in multiprocessing, for the py3k. In import.c, get_file.c, it was knowingly leaking FILE objects, while the underlying fh was being correctly closed. This caused the CRT to assert when cleaning up FILE pointers on subprocess exit. I fixed this this afternoon in a submission to the py3k branch. K -Original Message- From: Jesse Noller [mailto:jnol...@gmail.com] Sent: 31. mars 2009 21:31 To: Kristján Valur Jónsson Cc: Curt Hagenlocher; mhamm...@skippinet.com.au; David Bolen; python-dev@python.org Subject: Re: [Python-Dev] Test failures under Windows? 2009/3/31 Kristján Valur Jónsson krist...@ccpgames.com: Right, my question to microsoft was more about making sure that a __crtMessageBox() actually does nothing, when running unattended as a service. Also, we should be seeing the same problem in non-debug versions, since the _set_invalid_parameter_handler() is no longer called, and the default one also puts up a message box. The Assertion is then performed _in_addition_ on debug builds: From ms-help://MS.VSCC.v80/MS.MSDN.v80/MS.VisualStudio.v80.en/dv_vccrt/html/c0e67934-1a41-4016-ad8e-972828f3ac11.htm In the following example, an invalid parameter error handler is used to print the function that received the invalid parameter and the file and line in CRT sources. When the debug CRT library is used, invalid parameter errors also throw an assertion, which is disabled in this example using _CrtSetReportMode. Btw, I am working on finding out the test suite failures for test_multiprocessing. K I spoke to Martin about this yesterday, apparently a specific test in the multiprocessing suite was triggering these dialogs (the test invalid handle test). We're working on a patch for multiprocessing so that the children will obey the flag -jesse ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
Does it need to be backported? I wonder when that was introduced. Also, what CL was it so I can review it? 2009/3/31 Kristján Valur Jónsson krist...@ccpgames.com: I found a different problem in multiprocessing, for the py3k. In import.c, get_file.c, it was knowingly leaking FILE objects, while the underlying fh was being correctly closed. This caused the CRT to assert when cleaning up FILE pointers on subprocess exit. I fixed this this afternoon in a submission to the py3k branch. K -Original Message- From: Jesse Noller [mailto:jnol...@gmail.com] Sent: 31. mars 2009 21:31 To: Kristján Valur Jónsson Cc: Curt Hagenlocher; mhamm...@skippinet.com.au; David Bolen; python-dev@python.org Subject: Re: [Python-Dev] Test failures under Windows? 2009/3/31 Kristján Valur Jónsson krist...@ccpgames.com: Right, my question to microsoft was more about making sure that a __crtMessageBox() actually does nothing, when running unattended as a service. Also, we should be seeing the same problem in non-debug versions, since the _set_invalid_parameter_handler() is no longer called, and the default one also puts up a message box. The Assertion is then performed _in_addition_ on debug builds: From ms-help://MS.VSCC.v80/MS.MSDN.v80/MS.VisualStudio.v80.en/dv_vccrt/html/c0e67934-1a41-4016-ad8e-972828f3ac11.htm In the following example, an invalid parameter error handler is used to print the function that received the invalid parameter and the file and line in CRT sources. When the debug CRT library is used, invalid parameter errors also throw an assertion, which is disabled in this example using _CrtSetReportMode. Btw, I am working on finding out the test suite failures for test_multiprocessing. K I spoke to Martin about this yesterday, apparently a specific test in the multiprocessing suite was triggering these dialogs (the test invalid handle test). We're working on a patch for multiprocessing so that the children will obey the flag -jesse ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
I guess I'll stop asking after this note, but can anyone give a final verdict on whether the older -n option can be restored to the buildbot test.bat (from the revision history I'm not actually sure it was intentionally removed in the first place)? I have now restored it; it was removed by an unintentional merge from the trunk. Notice, however, that the feature was never present in the trunk. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
Revision 70843. I don't know when this crept in. I didn't go and check if it applies to other branches too. Also, I'm sorry for just checking this in witout warning. But I had just spent what amounts to a full day tracking this down which was tricky because it happens in a subprocess and those are hard to debug on windows. My eagerness got the best of me. But again, it shows how useful assertions can be and why we ought not to disable them. Cheers, Kristján -Original Message- From: Jesse Noller [mailto:jnol...@gmail.com] Sent: 31. mars 2009 22:00 To: Kristján Valur Jónsson Cc: Curt Hagenlocher; mhamm...@skippinet.com.au; David Bolen; python-dev@python.org Subject: Re: [Python-Dev] Test failures under Windows? Does it need to be backported? I wonder when that was introduced. Also, what CL was it so I can review it? 2009/3/31 Kristján Valur Jónsson krist...@ccpgames.com: I found a different problem in multiprocessing, for the py3k. In import.c, get_file.c, it was knowingly leaking FILE objects, while the underlying fh was being correctly closed. This caused the CRT to assert when cleaning up FILE pointers on subprocess exit. I fixed this this afternoon in a submission to the py3k branch. K ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
Martin v. Löwis mar...@v.loewis.de writes: Notice, however, that the feature was never present in the trunk. Yep - would be nice if it were to get backported to trunk at some point but that's a separate discussion ... presumably at some point py3k will be the trunk anyway, and for better or worst (perhaps due to the sorts of changes made) the assertions seem to have hit the py3k branch more than others. Thanks for the test.bat change. -- David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
Kristján Valur Jónsson krist...@ccpgames.com writes: But again, it shows how useful assertions can be and why we ought not to disable them. Note that just to be clear, I'm certainly not advocating the disabling of CRT assertions - just the redirection of them so they don't prevent unattended test runs from completing. -- David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
David Bolen wrote: I don't know why they are happening so frequently now when there was a reasonable period when they weren't an issue (something about new I/O support in 3.x perhaps?), but without preventing them it seems the Windows build slaves are going to become (if not already) quite a bit less useful. Don't know about anyone else's but I can't watch mine 7x24. -- David CRT Assertion was totally disabled before, but recently was enabled, and workarounds were patched for problematic functions. (ex: fdopen and dup) Probably this *patch* is not perfect. See http://bugs.python.org/issue4804 I'm now +3/4 for the idea disabling assertion by default, and enabling by startup option or environment variable. (Or enabling by default and disabling by environment variable?) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp writes: CRT Assertion was totally disabled before, but recently was enabled, and workarounds were patched for problematic functions. (ex: fdopen and dup) Probably this *patch* is not perfect. See http://bugs.python.org/issue4804 Ah - that ticket may explain why my buildbot hadn't been having problems until recently, even though the -n option in test.bat was removed quite a while back. I'm now +3/4 for the idea disabling assertion by default, and enabling by startup option or environment variable. (Or enabling by default and disabling by environment variable?) This is a bit more than I'm looking to have changed. I'm only discussing disabling the GUI assertions during buildbot test runs. It's fine if there are other circumstances when one might also want a mechanism to disable them, but I'd rather not intermingle such cases since there may be different pros and cons to different cases. The nature of the development process is that you're going to have issues at times which is why you're testing, and given the consequences of a pop-up box on an unattended build slave, it just seems very strange to me that there could be any good reason to leave a potential for such popups (which at this point is easy to disable) in the buildbot environment. -- David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
David Bolen db3l@gmail.com writes: From what I can see though, the tools/buildbot/test.bat file no longer adds the -n option that it used to, although I'm unclear on why it might have been removed. Perhaps this was just a regression that was accidentally missed, as it appears to have disappeared during a large merger from trunk to the py3k branch mid-2008 (r64273) when the batch file line ending was changed to CRLF. It would be nice to also have this in the other active release branches. This thread sort of died out ... would there be any objections to restoring the -n option in the buildbot test.bat file for Windows buildbots? I just went through clearing a ton of popups again on my build slave, but in the end had to again manually kill off all the individual python_d processes, as the popups just seemed to keep getting created anew. I don't know why they are happening so frequently now when there was a reasonable period when they weren't an issue (something about new I/O support in 3.x perhaps?), but without preventing them it seems the Windows build slaves are going to become (if not already) quite a bit less useful. Don't know about anyone else's but I can't watch mine 7x24. -- David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
On 25/03/2009 10:05 AM, David Bolen wrote: Kristján Valur Jónssonkrist...@ccpgames.com writes: Now, I know that this msvc behaviour can be disabled, but it was decided that it was not appropriate to meddle with runtime flags of the whole process for python. I must have missed that discussion, but I can't see what the problem is if such an override only occurs during the buildbot non-interactive test runs? Isn't that what using -n in the buildbot test.bat did? The issue was that Python unconditionally changed the behaviour of the CRT, not only during the test suite. I'm inclined to agree that Python itself (ie, pythonxx.dll on windows) has no business changing these flags, but it should be up to the application - ie, either python.exe itself, or exposed to the python app - the latter of which is what my patch offers. Note however that my patch doesn't cause any .py code to actually change the flags, just offers the ability for them to do so. Curt's suggestion of redirecting to a file is better still - I'll look at tweaking my patch to also offer that capability... Cheers, Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
Mark Hammond skippy.hamm...@gmail.com writes: The issue was that Python unconditionally changed the behaviour of the CRT, not only during the test suite. Hmm... I was more or less referring to the state of the py3k tree as of, say, r57823 back in 2007. It appeared to just add access to the necessary functions in the msvcrt module, and a -n/--nowindow option to regrtest.py which then used those functions to disable stuff before running the test, and finally added -n to the tools/buildbot/test.bat file, so things got disabled in buildbot test runs. (By disabled, I believe that all of the CRT warning/error/assert went to stderr) So nothing permanently built into Python, nor enabled outside of a buildbot regression test. I agree permanently disabling them wouldn't make sense, but I thought we also agreed to that back in 2007? -- David PS: The dialogs are showing up again on my build slave. I tried clearing it but then like 6+ of them showed up and kept showing up even though I kept aborting them (I guess the tests kept running new python_d instances or something). I finally managed to catch up and then whack the python_d processes manually through task manager. Really seems like disabling them can only make things more robust, otherwise the Windows build slaves are just going to keep ending up unresponsive. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
Right. In fact, having embedded python25.dll into an app once, I'm inclined to think that there is a lot of stuff that should be moved from that dll into python.exe, like argument parsing, path magic, and so on. Py_Initialize() really is designed in terms of python.exe Anyway, What I was trying to say is that there are other things that can cause dialogue boxes to pop up beside this. Assertions in other libraries, unhandled exceptions, and whatnot. Surely, all of this poses a problem on windows? Are the windows buildbots currently run as services, or are they started manually? I'm going to poke my contacts at Microsoft and ask them if there is a way to disable popups like this for a process that runs unattended and/or is running as a windows service. K -Original Message- From: python-dev-bounces+kristjan=ccpgames@python.org [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of Mark Hammond Sent: 25. mars 2009 08:44 To: David Bolen Cc: python-dev@python.org Subject: Re: [Python-Dev] Test failures under Windows? On 25/03/2009 10:05 AM, David Bolen wrote: Kristján Valur Jónssonkrist...@ccpgames.com writes: Now, I know that this msvc behaviour can be disabled, but it was decided that it was not appropriate to meddle with runtime flags of the whole process for python. I must have missed that discussion, but I can't see what the problem is if such an override only occurs during the buildbot non-interactive test runs? Isn't that what using -n in the buildbot test.bat did? The issue was that Python unconditionally changed the behaviour of the CRT, not only during the test suite. I'm inclined to agree that Python itself (ie, pythonxx.dll on windows) has no business changing these flags, but it should be up to the application - ie, either python.exe itself, or exposed to the python app - the latter of which is what my patch offers. Note however that my patch doesn't cause any .py code to actually change the flags, just offers the ability for them to do so. Curt's suggestion of redirecting to a file is better still - I'll look at tweaking my patch to also offer that capability... Cheers, Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/kristjan%40ccpgames.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
On 25/03/2009 7:58 PM, David Bolen wrote: Mark Hammondskippy.hamm...@gmail.com writes: The issue was that Python unconditionally changed the behaviour of the CRT, not only during the test suite. Hmm... I was more or less referring to the state of the py3k tree as of, say, r57823 back in 2007. I was referring to the issue described in http://bugs.python.org/issue4804, which notes that exceptions.c unconditionally called: _CrtSetReportMode(_CRT_ASSERT, 0); which has the effect of disabling crt assertions that would otherwise result in a modal dialog. That bug remains open though, so maybe I'm confused about the problem which started this discussion... Cheers, Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
I'm going to poke my contacts at Microsoft and ask them if there is a way to disable popups like this for a process that runs unattended and/or is running as a windows service. There is, and Curt pointed out one strategy for achieving this without losing the checks it provides... Curt's suggestion of redirecting to a file is better still - I'll look at tweaking my patch to also offer that capability... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
2009/3/25 Kristján Valur Jónsson krist...@ccpgames.com: I'm going to poke my contacts at Microsoft and ask them if there is a way to disable popups like this for a process that runs unattended and/or is running as a windows service. MSVC has shipped with runtime library source since the 16-bit days, so the easier thing is just to read the source code. :) It looks like there are two possible code paths for the assertion. The first code path uses functions in dbgrpt[t].c and its behavior is controlled by CrtSetReportMode and CrtSetReportFile. The second uses functions in assert.c and its behavior is controlled by _set_error_mode. Both code paths use __crtMessageBox in crtmbox.c to actually display the message box. This function -- when running as a service -- will helpfully set MB_SERVICE_NOTIFICATION before calling the USER32 MessageBox, which ensures that you'll see exactly why your service has hung the next time you actually log in with sufficient rights. :/ The variation that goes through assert.c should write to stderr for a console-mode application, so it's reasonable to assume that we're hitting the other code path -- and that Mark's suggestion to use CrtSetReportMode would address the issue. -- Curt Hagenlocher c...@hagenlocher.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
Curt Hagenlocher c...@hagenlocher.org writes: The variation that goes through assert.c should write to stderr for a console-mode application, so it's reasonable to assume that we're hitting the other code path -- and that Mark's suggestion to use CrtSetReportMode would address the issue. Which is pretty much what the regrtest.py -n option does/did in the py3k branch (and release30-maint). It enables the following code: import msvcrt msvcrt.SetErrorMode(msvcrt.SEM_FAILCRITICALERRORS| msvcrt.SEM_NOALIGNMENTFAULTEXCEPT| msvcrt.SEM_NOGPFAULTERRORBOX| msvcrt.SEM_NOOPENFILEERRORBOX) try: msvcrt.CrtSetReportMode except AttributeError: # release build pass else: for m in [msvcrt.CRT_WARN, msvcrt.CRT_ERROR, msvcrt.CRT_ASSERT]: msvcrt.CrtSetReportMode(m, msvcrt.CRTDBG_MODE_FILE) msvcrt.CrtSetReportFile(m, msvcrt.CRTDBG_FILE_STDERR) which seems like it would still be the right sort of code to use. For my buildbot the SetErrorMode is redundant because I already do that in the buildbot code itself (and the setting is inherited) but it won't hurt. From what I can see though, the tools/buildbot/test.bat file no longer adds the -n option that it used to, although I'm unclear on why it might have been removed. Perhaps this was just a regression that was accidentally missed, as it appears to have disappeared during a large merger from trunk to the py3k branch mid-2008 (r64273) when the batch file line ending was changed to CRLF. It would be nice to also have this in the other active release branches. -- David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
On Tue, 24 Mar 2009 13:49:28 + (UTC), Antoine Pitrou solip...@pitrou.net wrote: Hello, [snip] By the way, what happened to the Windows buildbots? It looks like some of them are suffering from problems which I think are common with buildbot on Windows - primarily difficulty dealing with runaway processes or timeouts. Perhaps BuildBot/Windows improvements would make a good GSoC project? :) Jean-Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
Antoine Pitrou solip...@pitrou.net writes: Am I the only one getting those? By the way, what happened to the Windows buildbots? Oops - sorry, mine (XP-4) apparently got stuck with C++ debug assertion dialogs (an assertion from the internal close.c module) from python_d during some earlier build. I try to catch these but have been a bit preoccupied this month. Should be back now. -- David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
These issues should be resolved in the py3k branch, but it will need porting to 2.6. Dialogue boxes are annoying, but do they pop up if you run your buildslave as a service without access to the console? K -Original Message- From: python-dev-bounces+kristjan=ccpgames@python.org [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of David Bolen Sent: 24. mars 2009 18:02 To: python-dev@python.org Subject: Re: [Python-Dev] Test failures under Windows? Antoine Pitrou solip...@pitrou.net writes: Am I the only one getting those? By the way, what happened to the Windows buildbots? Oops - sorry, mine (XP-4) apparently got stuck with C++ debug assertion dialogs (an assertion from the internal close.c module) from python_d during some earlier build. I try to catch these but have been a bit preoccupied this month. Should be back now. -- David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/kristjan%40ccpgames.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
David Bolen db3l.net at gmail.com writes: Antoine Pitrou solipsis at pitrou.net writes: Am I the only one getting those? By the way, what happened to the Windows buildbots? Oops - sorry, mine (XP-4) apparently got stuck with C++ debug assertion dialogs (an assertion from the internal close.c module) from python_d during some earlier build. :( This is unfortunately the kind of problem I wish the Windows buildbots had been able to report unambiguously... Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
Kristján Valur Jónsson krist...@ccpgames.com writes: These issues should be resolved in the py3k branch, but it will need porting to 2.6. Dialogue boxes are annoying, but do they pop up if you run your buildslave as a service without access to the console? Not sure what the MSVC++ runtime does with assertion dialogs if run without interactive access (they aren't console messages, but UI dialog popups). The buildslave already disables all normal MS runtime error dialogs, but can't stop the internal C runtime from putting up its own, at least I don't think so. It can be disabled from within Python itself at startup, but not external to the process. There was a discussion about this on the py3k mailing list back in mid-2007 (buildbots thread) and perhaps later as well, at which point I believe Martin added an -n option to regrtest and the buildbot test.bat file to disable the assertions. Is that the py3k branch piece you are referring to? Although in looking now I can't find that option in use in any of the current buildbot branches as part of tools/buildbot/test.bat. Looks like it got lost in one of the merges (unless it was intentional)? I wasn't paying close attention, so maybe there's some other mechanism in place at this point? -- David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
On Tue, Mar 24, 2009 at 11:49 AM, David Bolen db3l@gmail.com wrote: Kristján Valur Jónsson krist...@ccpgames.com writes: These issues should be resolved in the py3k branch, but it will need porting to 2.6. Dialogue boxes are annoying, but do they pop up if you run your buildslave as a service without access to the console? Not sure what the MSVC++ runtime does with assertion dialogs if run without interactive access (they aren't console messages, but UI dialog popups). At least at some point in the past, it didn't check to see if there was an attached window station. But the dialog can be disabled in debug mode by using the _set_error_mode function. (http://msdn.microsoft.com/en-us/library/sas1dkb2(VS.71).aspx) -- Curt Hagenlocher c...@hagenlocher.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
There was a discussion about this on the py3k mailing list back in mid-2007 (buildbots thread) and perhaps later as well, at which point I believe Martin added an -n option to regrtest and the buildbot test.bat file to disable the assertions. Is that the py3k branch piece you are referring to? I don't quite remember the -n flag, but I believe that Kristjan just removed all that stuff, ie. there is now no way to block CRT assertions anymore. I wasn't paying close attention, so maybe there's some other mechanism in place at this point? Unfortunately, not. There was a long debate, I lost, and Kristjan removed all the changes to support this setup, claiming that it is good to get assertions :-( Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
There was a recent test added to test_fileio.py which triggered runtime checks on windows. I fixed this and other related issues in a series of revisions around 70580. Now, I know that this msvc behaviour can be disabled, but it was decided that it was not appropriate to meddle with runtime flags of the whole process for python. It is unfortunate that a dialogue box is put up, even when the process is running without a UI. I wonder if there is a way to fix that without changing the way python is compiled... K -Original Message- From: python-dev-bounces+kristjan=ccpgames@python.org [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of Curt Hagenlocher Sent: 24. mars 2009 19:14 To: David Bolen Cc: python-dev@python.org Subject: Re: [Python-Dev] Test failures under Windows? On Tue, Mar 24, 2009 at 11:49 AM, David Bolen db3l@gmail.com wrote: Kristján Valur Jónsson krist...@ccpgames.com writes: These issues should be resolved in the py3k branch, but it will need porting to 2.6. Dialogue boxes are annoying, but do they pop up if you run your buildslave as a service without access to the console? Not sure what the MSVC++ runtime does with assertion dialogs if run without interactive access (they aren't console messages, but UI dialog popups). At least at some point in the past, it didn't check to see if there was an attached window station. But the dialog can be disabled in debug mode by using the _set_error_mode function. (http://msdn.microsoft.com/en-us/library/sas1dkb2(VS.71).aspx) -- Curt Hagenlocher c...@hagenlocher.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/kristjan%40ccpgames.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
On 25/03/2009 7:34 AM, Martin v. Löwis wrote: I don't quite remember the -n flag, but I believe that Kristjan just removed all that stuff, ie. there is now no way to block CRT assertions anymore. I wasn't paying close attention, so maybe there's some other mechanism in place at this point? Unfortunately, not. There was a long debate, I lost, and Kristjan removed all the changes to support this setup, claiming that it is good to get assertions :-( Note that I previously opened http://bugs.python.org/issue5116 with a patch to enable this to be controlled from Python via the msvcrt module. This would enable the test suite to disable assertions for its entire run. Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
Mark Hammond skippy.hammond at gmail.com writes: Note that I previously opened http://bugs.python.org/issue5116 with a patch to enable this to be controlled from Python via the msvcrt module. This would enable the test suite to disable assertions for its entire run. We certainly don't want to disable assertions during the test suite if it silences bugs which can crash the user's interpreter. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
On Tue, Mar 24, 2009 at 3:45 PM, Antoine Pitrou solip...@pitrou.net wrote: Mark Hammond skippy.hammond at gmail.com writes: Note that I previously opened http://bugs.python.org/issue5116 with a patch to enable this to be controlled from Python via the msvcrt module. This would enable the test suite to disable assertions for its entire run. We certainly don't want to disable assertions during the test suite if it silences bugs which can crash the user's interpreter. I assume the goal would be to write them to stdout or stderr instead of hanging the process by throwing up a dialog box. For that matter, you could use CrtSetReportFile to redirect them to any given file and then assert at the end of the test run that the file is empty. -- Curt Hagenlocher c...@hagenlocher.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
Note that I previously opened http://bugs.python.org/issue5116 with a patch to enable this to be controlled from Python via the msvcrt module. This would enable the test suite to disable assertions for its entire run. This patch is fine with me. It might need some documentation, though. However, I would still be unhappy if Python on Windows would pop up might pop up windows in cases where you get a proper exception on Unix. So I'd rather see these bugs fixed instead of silencing them. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
Kristján Valur Jónsson krist...@ccpgames.com writes: Now, I know that this msvc behaviour can be disabled, but it was decided that it was not appropriate to meddle with runtime flags of the whole process for python. I must have missed that discussion, but I can't see what the problem is if such an override only occurs during the buildbot non-interactive test runs? Isn't that what using -n in the buildbot test.bat did? It's not like it hides the error, as I believe the process will still terminate if it would have otherwise, thus causing a test failure, but the error itself just goes to stderr (or wherever) without popping up a blocking UI dialog. In that way it's no different than disabling the Windows (non-CRT) dialog boxes, which I do in my buildslave for all builds (via code in buildbot). The process still fails, but it doesn't hang waiting for UI interaction. I can't see the downside. -- David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
