[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Assertion failure during update_tests.py 58 (XFAIL: update a nonexistent child of a copied dir)

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Tue, 1 Feb 2011 23:16:08 +0100

On Tue, Feb 1, 2011 at 10:10 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> On Tue, Feb 1, 2011 at 3:08 PM, Bert Huijben <bert_at_qqmail.nl> wrote:
>>
>>
>>> -----Original Message-----
>>> From: Johan Corveleyn [mailto:jcorvel_at_gmail.com]
>>> Sent: dinsdag 1 februari 2011 13:28
>>> To: Daniel Shahaf
>>> Cc: Subversion Development
>>> Subject: Re: Assertion failure during update_tests.py 58 (XFAIL: update
>>> a nonexistent child of a copied dir)
>>>
>>> On Mon, Jan 24, 2011 at 3:21 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name>
>>> wrote:
>>> > Johan Corveleyn wrote on Mon, Jan 24, 2011 at 02:42:11 +0100:
>>> >> Hi,
>>> >>
>>> >> Already for some time now, update_tests.py 58 (XFAIL: update a
>>> >> nonexistent child of a copied dir) crashes on my machine:
>>> >>
>>> >>     svn: In file '..\..\..\subversion\libsvn_wc\update_editor.c'
>>> line
>>> >> 4877: assertion failed (repos_root != NULL && repos_uuid != NULL)
>>> >>
>>> >> I understand that this test is XFAIL, that this isn't addressed yet,
>>> >> but is it supposed to fail an assert?
>>> >>
>>> >> On my system (Win XP) this causes an ugly popup to appear (which I
>>> >> need to click away to continue), each time I run the full test suite
>>> >> ("This application has requested the Runtime to terminate it in an
>>> >> unusual way...")
>>> >>
>>> >> Relevant excerpt from tests.log in attachment (this was with
>>> trunk_at_1062600).
>>> >>
>>> > It certainly isn't supposed to force all test runs to be interactive
>>> :-(
>>> >
>>> > Have you tried removing SVN_USE_WIN32_CRASHHANDLER from gen_win.py?
>>>
>>> Almost forgot about this one, until I ran into it again yesterday
>>> evening.
>>>
>>> So: I've tried removing SVN_USE_WIN32_CRASHHANDLER from gen_win.py
>>> (put it in comment, ran "nmake config" and rebuilt everything), then
>>> ran update_tests.py again: same result. It still crashes, and shows
>>> the ugly blocking popup.
>>>
>>> Anyone else who recently built trunk on Windows seeing this, when
>>> running update_tests.py?
>>
>> The 'SVN_DBG_STACKTRACES_TO_STDERR' environment option that is set in
>> subversion/tests/cmdline/svntest/main.py should stop the popup dialogs while
>> running the tests. (It moves the output to stderr to allow logging them on
>> the Windows buildbots, instead of requiring interactive resolving).
>
> But it is set, and it still crashes with the popup, whether or not I
> remove the define of SVN_USE_WIN32_CRASHHANDLER in gen-win.py.
>
> If I add a print statement just below where
> SVN_DBG_STACKTRACES_TO_STDERR is set in main.py, this is the output I
> get when running update_tests.py:
>
> [[[
> C:\research\svn\client_build\svn_branch_diff-opt>python win-tests.py
> --verbose --cleanup
> --bin=C:\research\svn\client_build\svn_branch_diff-opt\dist\bin
> --release -f fsfs -t update_tests.py
> <snip...>
> Testing Release configuration on local repository.
> Running tests in update_tests.py [1/1]SVN_DBG_STACKTRACES_TO_STDERR set
> .
> ]]]
>
> it continues until test nr 58, and then gives the popup.
>
> Hm, I'm confused. I guess I'm going to fire up my debugger and set a
> breakpoint or something to see what happens and why ...

Ok, I'm starting to understand. If I do this with a Debug build, it
crashes without the popup. If I'm running the test with a Release
build, it gives the annoying popup, blocking the rest of the test
suite.

Is it supposed to be that way? I guess I should just as well be able
to run the full test suite, unattended, with a Release build, no?

(I always work with a Release build lately, because of the
performance/optimization work (I consider perf-numbers with
Debug-builds more or less irrelevant)).

Cheers,

-- 
Johan
Received on 2011-02-01 23:17:04 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.