On Wed, Feb 2, 2011 at 7:38 AM, Lieven Govaerts <svnlgo_at_mobsol.be> wrote:
> Johan,
>
> On Tue, Feb 1, 2011 at 11:16 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
>>
>> On Tue, Feb 1, 2011 at 10:10 PM, Johan Corveleyn <jcorvel_at_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
Received on 2011-02-03 22:10:52 CET