You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Johan Corveleyn <jc...@gmail.com> on 2011/02/01 13:28:24 UTC

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....@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@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?

-- 
Johan

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

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Johan Corveleyn wrote on Thu, Feb 03, 2011 at 22:47:23 +0100:
> On Wed, Feb 2, 2011 at 5:53 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > Johan Corveleyn wrote on Tue, Feb 01, 2011 at 13:28:24 +0100:
> >> 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.
> >>
> >
> > I don't use Windows as my day-to-day OS any more, but I suppose it'll be
> > a good idea to adhere to my old promise to commit that Makefile once it
> > has seen some testing :-).  Johan, could you do that?  Or send it to me
> > and I'll do it.
> 
> Hi Daniel,
> 
> Yes, great idea. This could definitely help get other people working
> on Windows interested in svn development (it helped me getting
> started). Here is the Makefile I'm currently using, but I don't think
> it's ready to be committed right away, with my local paths in it and
> all, and lots of custom tweaks to make it work for my needs.
> 

r1067056, and I added some TODO's in README.  We can handle them on an
as-needed basis.

I added some tweaks --- to avoid requiring a 'test.exe' binary, etc ---
I guess you'll see them when you diff the files.  (I also diffed your
Makefile against the one I'd mailed the list a while ago.)

I also reverted some of your 'don't require version number for
dependencies' changes... but thinking again I think that might not have
a good move.  So feel free to add them back!

> If I have some time, I'll try to clean it up a little. But right now,
> attaching it to this mail is all I can do :-).
> 
> Some changes I made to the original you sent me (from memory):
> - Fiddled around with the dependencies, until they worked for me.
> - Added Programs\diff, Programs\diff3 and Programs\diff4 to the "all1"
> and "all2" targets, because I needed them (for the diff-opitimizations
> testing). Added corresponding copy statement in the package target.
> 

On Unix, 'make' now implies 'make tools' (as of a couple of months ago).
We should do the same on Windows.

> Maybe other things, but I don't remember (right now, I'm just copying
> this Makefile around if I need to build a new branch that I checked
> out (only need to change the paths in the beginning of the file)).
> 
> Cheers,
> Johan
> 

Thanks!

Daniel

> > Belatedly,
> >
> > Daniel
> > (as sibling to stsp's tools/dev/unix-build/ I suggest)
> >
> >> Anyone else who recently built trunk on Windows seeing this, when
> >> running update_tests.py?
> >>
> >> --
> >> Johan
> >


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

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Johan Corveleyn wrote on Thu, Feb 03, 2011 at 22:47:23 +0100:
> - Added Programs\diff, Programs\diff3 and Programs\diff4 to the "all1"
> and "all2" targets, because I needed them (for the diff-opitimizations
> testing).

stsp added 'make tools' to the default unix build, which builds these
too.  We should do the same for the Windows build if it's not already so.

> Added corresponding copy statement in the package target.

With respect to the rest: cool, thanks, one of us can clean it up and commit it.

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

Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Feb 2, 2011 at 5:53 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Johan Corveleyn wrote on Tue, Feb 01, 2011 at 13:28:24 +0100:
>> 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.
>>
>
> I don't use Windows as my day-to-day OS any more, but I suppose it'll be
> a good idea to adhere to my old promise to commit that Makefile once it
> has seen some testing :-).  Johan, could you do that?  Or send it to me
> and I'll do it.

Hi Daniel,

Yes, great idea. This could definitely help get other people working
on Windows interested in svn development (it helped me getting
started). Here is the Makefile I'm currently using, but I don't think
it's ready to be committed right away, with my local paths in it and
all, and lots of custom tweaks to make it work for my needs.

If I have some time, I'll try to clean it up a little. But right now,
attaching it to this mail is all I can do :-).

Some changes I made to the original you sent me (from memory):
- Fiddled around with the dependencies, until they worked for me.
- Added Programs\diff, Programs\diff3 and Programs\diff4 to the "all1"
and "all2" targets, because I needed them (for the diff-opitimizations
testing). Added corresponding copy statement in the package target.

Maybe other things, but I don't remember (right now, I'm just copying
this Makefile around if I need to build a new branch that I checked
out (only need to change the paths in the beginning of the file)).

Cheers,
Johan

> Belatedly,
>
> Daniel
> (as sibling to stsp's tools/dev/unix-build/ I suggest)
>
>> Anyone else who recently built trunk on Windows seeing this, when
>> running update_tests.py?
>>
>> --
>> Johan
>

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

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Johan Corveleyn wrote on Tue, Feb 01, 2011 at 13:28:24 +0100:
> 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.
> 

I don't use Windows as my day-to-day OS any more, but I suppose it'll be
a good idea to adhere to my old promise to commit that Makefile once it
has seen some testing :-).  Johan, could you do that?  Or send it to me
and I'll do it.

Belatedly,

Daniel
(as sibling to stsp's tools/dev/unix-build/ I suggest)

> Anyone else who recently built trunk on Windows seeing this, when
> running update_tests.py?
> 
> -- 
> Johan

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

Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Feb 2, 2011 at 7:38 AM, Lieven Govaerts <sv...@mobsol.be> wrote:
> Johan,
>
> On Tue, Feb 1, 2011 at 11:16 PM, Johan Corveleyn <jc...@gmail.com> wrote:
>>
>> On Tue, Feb 1, 2011 at 10:10 PM, Johan Corveleyn <jc...@gmail.com>
>> wrote:
>> > 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?
>
> The idea was that people who have Visual Studio installed might be more
> interested in seeing the code resulting in a crash in their debugger than as
> a textual stacktrace.
> This choice is hardcoded in
> subversion/libsvn_subr/win32_crashrpt.c:svn__unhandled_exception_filter
> (lines 723-724).
> I'm not against using SVN_DBG_STACKTRACES_TO_STDERR also as a flag to
> trigger this, or add (yet) another flag.

I don't understand. I'm not running it from inside a debugger.

I'm just running the tests from the commandline:

    python win-tests.py --verbose --cleanup
--bin=C:\research\svn\client_build\svn_branch_diff-opt\dist\bin
--debug -f fsfs -t update_tests.py

If I run this with a Debug build, the crash in test 58 is no problem
(textual stacktrace in tests.log file).

However, if I run it with a Release build, that crash causes the Windows popup.

But there is no debugger involved in either case.

Anyway, I guess it would indeed help if SVN_DBG_STACKTRACES_TO_STDERR
would avoid the popup, both with Debug builds as with Release builds.
Or some other way of avoiding this problem ...

Cheers,
-- 
Johan

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

Posted by Lieven Govaerts <sv...@mobsol.be>.
Johan,

On Tue, Feb 1, 2011 at 11:16 PM, Johan Corveleyn <jc...@gmail.com> wrote:

> On Tue, Feb 1, 2011 at 10:10 PM, Johan Corveleyn <jc...@gmail.com>
> wrote:
> > 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?
>

The idea was that people who have Visual Studio installed might be more
interested in seeing the code resulting in a crash in their debugger than as
a textual stacktrace.

This choice is hardcoded in
subversion/libsvn_subr/win32_crashrpt.c:svn__unhandled_exception_filter
(lines 723-724).

I'm not against using SVN_DBG_STACKTRACES_TO_STDERR also as a flag to
trigger this, or add (yet) another flag.

regards,

Lieven

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

Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Feb 1, 2011 at 10:10 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Tue, Feb 1, 2011 at 3:08 PM, Bert Huijben <be...@qqmail.nl> wrote:
>>
>>
>>> -----Original Message-----
>>> From: Johan Corveleyn [mailto:jcorvel@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....@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@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

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

Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Feb 1, 2011 at 3:08 PM, Bert Huijben <be...@qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: Johan Corveleyn [mailto:jcorvel@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....@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@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 ...

Cheers,
-- 
Johan

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

Posted by Bert Huijben <be...@qqmail.nl>.

> -----Original Message-----
> From: Johan Corveleyn [mailto:jcorvel@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....@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@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).

	Bert