You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan <lu...@gmx.de> on 2016/08/07 12:08:35 UTC
[PATCH] Resolve testsuite interruption in SVN 1.8
Hi,
the attached patch is the outcome of talking with jcorval on IRC about a
test suite issue on Windows (release builds) in SVN 1.8. It resolves the
fact that the tests will be interrupted on Windows by a Windows popup
upon an abort()-call.
Atm this is triggered for the 1.8 test suite for the move-test (no 8)
which is marked as XFail and triggers an SVN_ERR_ASSERT() and therefore
breaks fully automated tests.
The chosen solution is based on an old discussion in 2011 which
triggered the case in a different (older) test:
http://svn.haxx.se/dev/archive-2011-01/0328.shtml
http://svn.haxx.se/dev/archive-2011-02/0011.shtml
The proposed patch introduces a new environment variable
(SVN_CMDLINE_DISABLE_WATSON_ON_ABORT) and if set, disables the Windows'
Watson crash reporting upon an abort-call.
More details available here: http://www.luke1410.de:8090/browse/MAXSVN-66
The patch was checked against trunk and 1.8.16 (running the whole test
suite (Win10 (1511) 64-bit x ra_local x fsfs)).
[[[
Resolve testsuite interruption on Windows in release mode, if a test
triggers
an abort.
* subversion/libsvn_subr/cmdline.c
(svn_cmdline_init): check against the new
SVN_CMDLINE_DISABLE_WATSON_ON_ABORT
environment variable and disable Watson crash dumps in
this case
* subversion/tests/svn_test_main.c
(svn_test_main): the same
* win-tests.py
(): define the SVN_CMDLINE_DISABLE_WATSON_ON_ABORT environment
variable when
running the test suite
]]]
Regards,
Stefan
Re: [PATCH] Resolve testsuite interruption in SVN 1.8
Posted by Johan Corveleyn <jc...@gmail.com>.
On Sun, Aug 7, 2016 at 10:14 PM, Stefan <lu...@posteo.de> wrote:
> On 8/7/2016 21:16, Ivan Zhakov wrote:
>> On 7 August 2016 at 21:27, Stefan Sperling <st...@elego.de> wrote:
>>> On Sun, Aug 07, 2016 at 08:23:58PM +0200, Stefan Sperling wrote:
>>>> On Sun, Aug 07, 2016 at 02:08:35PM +0200, Stefan wrote:
>>>>> Hi,
>>>>>
>>>>> the attached patch is the outcome of talking with jcorval on IRC about a
>>>>> test suite issue on Windows (release builds) in SVN 1.8. It resolves the
>>>>> fact that the tests will be interrupted on Windows by a Windows popup
>>>>> upon an abort()-call.
>>>>>
>>>>> Atm this is triggered for the 1.8 test suite for the move-test (no 8)
>>>>> which is marked as XFail and triggers an SVN_ERR_ASSERT() and therefore
>>>>> breaks fully automated tests.
>>>> I'm not a windows person but this looks reasonable to me. +1
>>> Forgot to mention: If this is a 1.8-only fix, I'd suggest you create
>>> a branch of 1.8.x and commit your patch there, and then nominate your
>>> branch in the 1.8.x/STATUS file (you can add my +1 to the nomination).
>> I'm not sure that we should add handling of new environment variable
>> in patch release.
>>
>>
> I can understand the concern. Please bare in mind however that the
> default behavior (aka: if the environment variable is not set) would
> stay unchanged and the effect of the environment variable is quite
> limited (it will only disable the Watson crash dumps in release builds -
> obviously only applies on Windows builds). It's by default only
> activated for the test suites and therefore the risks involved is IMO
> close to non existent.
>
> Weighting the pros (fixing a test interruption of the test suite for
> everybody testing/building the SVN package) with the cons (the risk of
> s/o unintentionally already having set an environment variable with the
> same name and on the other side introducing a new test-suite related
> feature in a patch release which would be not available in versions <=
> 1.8.16), I do have a tendency to still propose that patch. (Note: I
> would suggest otherwise, if it wasn't related to a fix for the
> testsuite, since then it could hardly be seen as a bugfix).
>
> I thought about alternatives, but rejected them due to different reasons:
>
> Alternative 1:
> Do not use the environment variable and rather make it implicit behavior
> to disable the Watson crash reports.
> Rejected, since that would be a behavior change of SVN. Downstream
> releases of SVN might rely on current crashdump integration and would be
> broken.
>
> Alternative 2 (untested):
> For the test environment set the corresponding Windows registry entry
> [1] prior to running the SVN tests so to disable sending the
> crashreports and/or bring up the popup to attach a debugger.
> Rejected, since that would be an additional barrier to run the testsuite
> especially for people building SVN themselves. IMO there should be as
> few hurdles as possible to build and test SVN, so to not risk stopping
> people from giving SVN a try.
>
> Alternative 3:
> Use a config setting instead of an environment variable.
> Rejected, since there we could not disable the crashreports before the
> config file was processed.
>
> Alternative 4:
> Use a command line parameter to disable crashreports.
> Rejected, since it would only work for command line tests but not for
> testing the C API.
>
> Maybe your call, Ivan, would be to use alternative 2 for SVN <= 1.9 and
> introduce the environment variable related fix in trunk only?
>
> [1]
> https://blogs.msdn.microsoft.com/alejacma/2011/02/18/how-to-disable-the-pop-up-that-windows-shows-when-an-app-crashes/
>
> Regards,
> Stefan
Thanks for taking this on, Stefan. This has been bothering me every
time I needed to do release testing/signing for 1.8.x (but I didn't
know how to fix it, and didn't have the energy to push it further
myself).
I'm +1 for your current fix, certainly on trunk, but also for backport
to 1.8 and 1.9 (given your arguments above).
That said, I can also live with other solutions. In fact, currently
there is only this one known test crash in 1.8 (move-test #8), and no
known test crashes in 1.9. So if it's too contentious to backport
this, I can live with knowing about that registry entry (where I can
"fix" it myself -- thanks for pointing that out!) ... there are not
that many people who will still test 1.8 on Windows. New interested
contributors will most likely start with trunk (hopefully with your
fix then) or 1.9 (no known test crashes).
--
Johan
Re: [PATCH] Resolve testsuite interruption in SVN 1.8 (v2)
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 8 August 2016 at 23:29, Stefan <lu...@posteo.de> wrote:
> On 8/8/2016 14:53, Stefan Hett wrote:
>> On 8/8/2016 12:22 PM, Ivan Zhakov wrote:
>>
>>> On 7 August 2016 at 23:14, Stefan <lu...@posteo.de> wrote:
>>>
>>> Btw what are the problems with approach to disable watson reports on
>>> abort(), except backporting? I mean we already override Windows Error
>>> Reporting by installing our own SEH exception handler, so it looks
>>> natural to disable abort() reporting also.
>>>
>> I agree with you on this one. I wasn't aware that SVN does already
>> alter the default exception handling on Windows (and therefore
>> effectively disable the Watson crash dump reports in case of an
>> unhanled exception). So disabling the Watson crash dumps on abort
>> calls does indeed sound like increasing the system/design consistency
>> in SVN.
>> You got my non-binding +1 on that proposal (which obviously would be a
>> replacement for my proposed patch).
>>
> I've been thinking more about your arguments and since I agree with you,
> I'd like to replace my previously proposed patch with this updated
> version based on your idea.
> Due to the behavior change it imposes, I'm not going to propose this for
> backporting to 1.8 or 1.9, though.
>
> Note that I kept the design to only disable Watson crash reports, unless
> SVN_CMDLINE_USE_DIALOG_FOR_ABORT is set. The reasoning is as given in my
> previous reply as in as far as I understand the design of that
> environment-variable-setting, it should control whether an abort
> produces a popup or not. Disabling the Watson crash reports would
> prevent that popup (in certain cases) and therefore negate the setting.
>
Hi Stefan,
I've tested your patch, but it seems that calling
_set_abort_behavior(0, _CALL_REPORTFAULT) is not enough. The problem
with this approach that abort() uses RaiseFailFastException() that
bypasses all exception handlers [1].
So Subversion doesn't write crash dump and even doesn't print error
message on abort() failure. One solution would be to register signal
handler() and use RaiseException(STATUS_FATAL_APP_EXIT). This
exception would be handled by our own exception handler. Subversion
already uses such approach for handling out-of-memory errors (see
r1724784 [2]). I've tested this approach (see attached patch) and it
seems to be working fine, but I want to test it more before
committing.
[1] https://msdn.microsoft.com/en-us/library/windows/desktop/dd941688(v=vs.85).aspx
[2] https://svn.apache.org/r1724784
--
Ivan Zhakov
Re: [PATCH] Resolve testsuite interruption in SVN 1.8 (v2)
Posted by Stefan <lu...@posteo.de>.
On 8/8/2016 14:53, Stefan Hett wrote:
> On 8/8/2016 12:22 PM, Ivan Zhakov wrote:
>
>> On 7 August 2016 at 23:14, Stefan <lu...@posteo.de> wrote:
>>
>> Btw what are the problems with approach to disable watson reports on
>> abort(), except backporting? I mean we already override Windows Error
>> Reporting by installing our own SEH exception handler, so it looks
>> natural to disable abort() reporting also.
>>
> I agree with you on this one. I wasn't aware that SVN does already
> alter the default exception handling on Windows (and therefore
> effectively disable the Watson crash dump reports in case of an
> unhanled exception). So disabling the Watson crash dumps on abort
> calls does indeed sound like increasing the system/design consistency
> in SVN.
> You got my non-binding +1 on that proposal (which obviously would be a
> replacement for my proposed patch).
>
I've been thinking more about your arguments and since I agree with you,
I'd like to replace my previously proposed patch with this updated
version based on your idea.
Due to the behavior change it imposes, I'm not going to propose this for
backporting to 1.8 or 1.9, though.
Note that I kept the design to only disable Watson crash reports, unless
SVN_CMDLINE_USE_DIALOG_FOR_ABORT is set. The reasoning is as given in my
previous reply as in as far as I understand the design of that
environment-variable-setting, it should control whether an abort
produces a popup or not. Disabling the Watson crash reports would
prevent that popup (in certain cases) and therefore negate the setting.
[[[
Disable Watson crash reports upon abort()-calls on Windows, to allow
unattended test suite runs if an abort() is triggered.
* subversion/libsvn_subr/cmdline.c
(svn_cmdline_init): disable Watson crash reports on abort unless
SVN_CMDLINE_USE_DIALOG_FOR_ABORT is set
* subversion/tests/svn_test_main.c
(svn_test_main): the same
Suggested by: ivan
]]]
(Note: This patch was untested, since it's an obvious derivate of the
previous version of the patch.)
Regards,
Stefan
Re: [PATCH] Resolve testsuite interruption in SVN 1.8
Posted by Stefan Hett <st...@egosoft.com>.
On 8/8/2016 12:22 PM, Ivan Zhakov wrote:
> On 7 August 2016 at 23:14, Stefan <lu...@posteo.de> wrote:
>> On 8/7/2016 21:16, Ivan Zhakov wrote:
>>> On 7 August 2016 at 21:27, Stefan Sperling <st...@elego.de> wrote:
>>>> On Sun, Aug 07, 2016 at 08:23:58PM +0200, Stefan Sperling wrote:
>>>>> On Sun, Aug 07, 2016 at 02:08:35PM +0200, Stefan wrote:
>>>>>> Hi,
>>>>>>
>>>>>> the attached patch is the outcome of talking with jcorval on IRC about a
>>>>>> test suite issue on Windows (release builds) in SVN 1.8. It resolves the
>>>>>> fact that the tests will be interrupted on Windows by a Windows popup
>>>>>> upon an abort()-call.
>>>>>>
>>>>>> Atm this is triggered for the 1.8 test suite for the move-test (no 8)
>>>>>> which is marked as XFail and triggers an SVN_ERR_ASSERT() and therefore
>>>>>> breaks fully automated tests.
>>>>> I'm not a windows person but this looks reasonable to me. +1
>>>> Forgot to mention: If this is a 1.8-only fix, I'd suggest you create
>>>> a branch of 1.8.x and commit your patch there, and then nominate your
>>>> branch in the 1.8.x/STATUS file (you can add my +1 to the nomination).
>>> I'm not sure that we should add handling of new environment variable
>>> in patch release.
>>>
>>>
>> I can understand the concern. Please bare in mind however that the
>> default behavior (aka: if the environment variable is not set) would
>> stay unchanged and the effect of the environment variable is quite
>> limited (it will only disable the Watson crash dumps in release builds -
>> obviously only applies on Windows builds). It's by default only
>> activated for the test suites and therefore the risks involved is IMO
>> close to non existent.
>>
> Could you please first clarify: does this problem exist in trunk? I'm
> asking because subject is somewhat confusing because it only mention
> "SVN 1.8". If yes, we should discuss solution for trunk first. And
> then discuss backporting committed solution to active stable branches
> separately.
To clarify: I'd define the actual design problem as follows:
For release builds on Windows the test suite lacks the capability of
automatically handling abort()-calls in such a way that it won't require
manual interventions.
This problem exists on trunk.
> Regarding the patch itself (assuming it for trunk): why you have
> decided to check for SVN_CMDLINE_DISABLE_WATSON_ON_ABORT environment
> variable only if SVN_CMDLINE_USE_DIALOG_FOR_ABORT is not set? It
> creates very hard to understand dependency on other environment
> variables that controls crashhandler/abort() behavior. Because
> currently suggested behavior would be:
> if (!getenv("SVN_CMDLINE_DISABLE_CRASH_HANDLER"))
> {
> if (!getenv("SVN_CMDLINE_USE_DIALOG_FOR_ABORT"))
> {
> if (getenv("SVN_CMDLINE_DISABLE_WATSON_ON_ABORT"))
> {
> _set_abort_behavior(0, _CALL_REPORTFAULT);
> }
> }
> }
>
I'll split that up into separate questions:
1. SVN_CMDLINE_DISABLE_WATSON_ON_ABORT is only specified, unless the SVN
crash handler is disabled, because I assumed that the design decision
was that the SVN_CMDLINE_DISABLE_CRASH_HANDLER environment variable
should control whether the OS-default crash handling behavior should be
used, if specified (aka: do not mess around with system defaults, if
SVN_CMDLINE_DISABLE_CRASH_HANDLER is specified).
2. Not specifying SVN_CMDLINE_USE_DIALOG_FOR_ABORT was chosen as a
prerequisite for the SVN_CMDLINE_DISABLE_WATSON_ON_ABORT design, because
I assumed the design of SVN_CMDLINE_USE_DIALOG_FOR_ABORT was to ensure
that the OS-default dialog is to be used for abort-calls (and disabling
the Watson crash dumps would change that default handling).
I'm certainly not against having SVN_CMDLINE_DISABLE_WATSON_ON_ABORT be
evaluated completely independent from the other two environment
variables in order to make its definition easier to comprehend and leave
it with the user to ensure it's used reasonably in combination with the
other two environment variables.
> Btw what are the problems with approach to disable watson reports on
> abort(), except backporting? I mean we already override Windows Error
> Reporting by installing our own SEH exception handler, so it looks
> natural to disable abort() reporting also.
>
I agree with you on this one. I wasn't aware that SVN does already alter
the default exception handling on Windows (and therefore effectively
disable the Watson crash dump reports in case of an unhanled exception).
So disabling the Watson crash dumps on abort calls does indeed sound
like increasing the system/design consistency in SVN.
You got my non-binding +1 on that proposal (which obviously would be a
replacement for my proposed patch).
> Also your patch is missing documentation changes in notes/knobs.
>
Thanks for pointing that out. Wasn't aware of this document before.
Unless the tendency is to go with your suggestion (see above), I'll
provide an updated patch adding the missing documentation.
--
Regards,
Stefan Hett
Re: [PATCH] Resolve testsuite interruption in SVN 1.8
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 7 August 2016 at 23:14, Stefan <lu...@posteo.de> wrote:
> On 8/7/2016 21:16, Ivan Zhakov wrote:
>> On 7 August 2016 at 21:27, Stefan Sperling <st...@elego.de> wrote:
>>> On Sun, Aug 07, 2016 at 08:23:58PM +0200, Stefan Sperling wrote:
>>>> On Sun, Aug 07, 2016 at 02:08:35PM +0200, Stefan wrote:
>>>>> Hi,
>>>>>
>>>>> the attached patch is the outcome of talking with jcorval on IRC about a
>>>>> test suite issue on Windows (release builds) in SVN 1.8. It resolves the
>>>>> fact that the tests will be interrupted on Windows by a Windows popup
>>>>> upon an abort()-call.
>>>>>
>>>>> Atm this is triggered for the 1.8 test suite for the move-test (no 8)
>>>>> which is marked as XFail and triggers an SVN_ERR_ASSERT() and therefore
>>>>> breaks fully automated tests.
>>>> I'm not a windows person but this looks reasonable to me. +1
>>> Forgot to mention: If this is a 1.8-only fix, I'd suggest you create
>>> a branch of 1.8.x and commit your patch there, and then nominate your
>>> branch in the 1.8.x/STATUS file (you can add my +1 to the nomination).
>> I'm not sure that we should add handling of new environment variable
>> in patch release.
>>
>>
> I can understand the concern. Please bare in mind however that the
> default behavior (aka: if the environment variable is not set) would
> stay unchanged and the effect of the environment variable is quite
> limited (it will only disable the Watson crash dumps in release builds -
> obviously only applies on Windows builds). It's by default only
> activated for the test suites and therefore the risks involved is IMO
> close to non existent.
>
Could you please first clarify: does this problem exist in trunk? I'm
asking because subject is somewhat confusing because it only mention
"SVN 1.8". If yes, we should discuss solution for trunk first. And
then discuss backporting committed solution to active stable branches
separately.
Regarding the patch itself (assuming it for trunk): why you have
decided to check for SVN_CMDLINE_DISABLE_WATSON_ON_ABORT environment
variable only if SVN_CMDLINE_USE_DIALOG_FOR_ABORT is not set? It
creates very hard to understand dependency on other environment
variables that controls crashhandler/abort() behavior. Because
currently suggested behavior would be:
if (!getenv("SVN_CMDLINE_DISABLE_CRASH_HANDLER"))
{
if (!getenv("SVN_CMDLINE_USE_DIALOG_FOR_ABORT"))
{
if (getenv("SVN_CMDLINE_DISABLE_WATSON_ON_ABORT"))
{
_set_abort_behavior(0, _CALL_REPORTFAULT);
}
}
}
Btw what are the problems with approach to disable watson reports on
abort(), except backporting? I mean we already override Windows Error
Reporting by installing our own SEH exception handler, so it looks
natural to disable abort() reporting also.
Also your patch is missing documentation changes in notes/knobs.
--
Ivan Zhakov
Re: [PATCH] Resolve testsuite interruption in SVN 1.8
Posted by Stefan <lu...@posteo.de>.
On 8/7/2016 21:16, Ivan Zhakov wrote:
> On 7 August 2016 at 21:27, Stefan Sperling <st...@elego.de> wrote:
>> On Sun, Aug 07, 2016 at 08:23:58PM +0200, Stefan Sperling wrote:
>>> On Sun, Aug 07, 2016 at 02:08:35PM +0200, Stefan wrote:
>>>> Hi,
>>>>
>>>> the attached patch is the outcome of talking with jcorval on IRC about a
>>>> test suite issue on Windows (release builds) in SVN 1.8. It resolves the
>>>> fact that the tests will be interrupted on Windows by a Windows popup
>>>> upon an abort()-call.
>>>>
>>>> Atm this is triggered for the 1.8 test suite for the move-test (no 8)
>>>> which is marked as XFail and triggers an SVN_ERR_ASSERT() and therefore
>>>> breaks fully automated tests.
>>> I'm not a windows person but this looks reasonable to me. +1
>> Forgot to mention: If this is a 1.8-only fix, I'd suggest you create
>> a branch of 1.8.x and commit your patch there, and then nominate your
>> branch in the 1.8.x/STATUS file (you can add my +1 to the nomination).
> I'm not sure that we should add handling of new environment variable
> in patch release.
>
>
I can understand the concern. Please bare in mind however that the
default behavior (aka: if the environment variable is not set) would
stay unchanged and the effect of the environment variable is quite
limited (it will only disable the Watson crash dumps in release builds -
obviously only applies on Windows builds). It's by default only
activated for the test suites and therefore the risks involved is IMO
close to non existent.
Weighting the pros (fixing a test interruption of the test suite for
everybody testing/building the SVN package) with the cons (the risk of
s/o unintentionally already having set an environment variable with the
same name and on the other side introducing a new test-suite related
feature in a patch release which would be not available in versions <=
1.8.16), I do have a tendency to still propose that patch. (Note: I
would suggest otherwise, if it wasn't related to a fix for the
testsuite, since then it could hardly be seen as a bugfix).
I thought about alternatives, but rejected them due to different reasons:
Alternative 1:
Do not use the environment variable and rather make it implicit behavior
to disable the Watson crash reports.
Rejected, since that would be a behavior change of SVN. Downstream
releases of SVN might rely on current crashdump integration and would be
broken.
Alternative 2 (untested):
For the test environment set the corresponding Windows registry entry
[1] prior to running the SVN tests so to disable sending the
crashreports and/or bring up the popup to attach a debugger.
Rejected, since that would be an additional barrier to run the testsuite
especially for people building SVN themselves. IMO there should be as
few hurdles as possible to build and test SVN, so to not risk stopping
people from giving SVN a try.
Alternative 3:
Use a config setting instead of an environment variable.
Rejected, since there we could not disable the crashreports before the
config file was processed.
Alternative 4:
Use a command line parameter to disable crashreports.
Rejected, since it would only work for command line tests but not for
testing the C API.
Maybe your call, Ivan, would be to use alternative 2 for SVN <= 1.9 and
introduce the environment variable related fix in trunk only?
[1]
https://blogs.msdn.microsoft.com/alejacma/2011/02/18/how-to-disable-the-pop-up-that-windows-shows-when-an-app-crashes/
Regards,
Stefan
Re: [PATCH] Resolve testsuite interruption in SVN 1.8
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 7 August 2016 at 21:27, Stefan Sperling <st...@elego.de> wrote:
> On Sun, Aug 07, 2016 at 08:23:58PM +0200, Stefan Sperling wrote:
>> On Sun, Aug 07, 2016 at 02:08:35PM +0200, Stefan wrote:
>> > Hi,
>> >
>> > the attached patch is the outcome of talking with jcorval on IRC about a
>> > test suite issue on Windows (release builds) in SVN 1.8. It resolves the
>> > fact that the tests will be interrupted on Windows by a Windows popup
>> > upon an abort()-call.
>> >
>> > Atm this is triggered for the 1.8 test suite for the move-test (no 8)
>> > which is marked as XFail and triggers an SVN_ERR_ASSERT() and therefore
>> > breaks fully automated tests.
>>
>> I'm not a windows person but this looks reasonable to me. +1
>
> Forgot to mention: If this is a 1.8-only fix, I'd suggest you create
> a branch of 1.8.x and commit your patch there, and then nominate your
> branch in the 1.8.x/STATUS file (you can add my +1 to the nomination).
I'm not sure that we should add handling of new environment variable
in patch release.
--
Ivan Zhakov
Re: [PATCH] Resolve testsuite interruption in SVN 1.8
Posted by Stefan <lu...@posteo.de>.
On 8/7/2016 20:27, Stefan Sperling wrote:
> On Sun, Aug 07, 2016 at 08:23:58PM +0200, Stefan Sperling wrote:
>> On Sun, Aug 07, 2016 at 02:08:35PM +0200, Stefan wrote:
>>> Hi,
>>>
>>> the attached patch is the outcome of talking with jcorval on IRC about a
>>> test suite issue on Windows (release builds) in SVN 1.8. It resolves the
>>> fact that the tests will be interrupted on Windows by a Windows popup
>>> upon an abort()-call.
>>>
>>> Atm this is triggered for the 1.8 test suite for the move-test (no 8)
>>> which is marked as XFail and triggers an SVN_ERR_ASSERT() and therefore
>>> breaks fully automated tests.
>> I'm not a windows person but this looks reasonable to me. +1
> Forgot to mention: If this is a 1.8-only fix, I'd suggest you create
> a branch of 1.8.x and commit your patch there, and then nominate your
> branch in the 1.8.x/STATUS file (you can add my +1 to the nomination).
I'd certainly propose to apply the patch to trunk as well.
The reasoning would be that any code which triggers an abort-call should
be detected automatically by the test suite and not interrupt the test
run (waiting for some user interaction). So while atm no other case
seems to trigger the problem, it'd certainly improve the test facility
and prevent future problems the next time some added test (or code
change) triggers an abort() as part of running a test.
Regards,
Stefan
Re: [PATCH] Resolve testsuite interruption in SVN 1.8
Posted by Stefan Sperling <st...@elego.de>.
On Sun, Aug 07, 2016 at 08:23:58PM +0200, Stefan Sperling wrote:
> On Sun, Aug 07, 2016 at 02:08:35PM +0200, Stefan wrote:
> > Hi,
> >
> > the attached patch is the outcome of talking with jcorval on IRC about a
> > test suite issue on Windows (release builds) in SVN 1.8. It resolves the
> > fact that the tests will be interrupted on Windows by a Windows popup
> > upon an abort()-call.
> >
> > Atm this is triggered for the 1.8 test suite for the move-test (no 8)
> > which is marked as XFail and triggers an SVN_ERR_ASSERT() and therefore
> > breaks fully automated tests.
>
> I'm not a windows person but this looks reasonable to me. +1
Forgot to mention: If this is a 1.8-only fix, I'd suggest you create
a branch of 1.8.x and commit your patch there, and then nominate your
branch in the 1.8.x/STATUS file (you can add my +1 to the nomination).
Re: [PATCH] Resolve testsuite interruption in SVN 1.8
Posted by Stefan Sperling <st...@elego.de>.
On Sun, Aug 07, 2016 at 02:08:35PM +0200, Stefan wrote:
> Hi,
>
> the attached patch is the outcome of talking with jcorval on IRC about a
> test suite issue on Windows (release builds) in SVN 1.8. It resolves the
> fact that the tests will be interrupted on Windows by a Windows popup
> upon an abort()-call.
>
> Atm this is triggered for the 1.8 test suite for the move-test (no 8)
> which is marked as XFail and triggers an SVN_ERR_ASSERT() and therefore
> breaks fully automated tests.
I'm not a windows person but this looks reasonable to me. +1