allow ASSERT_ALWAYS_ABORT for debug builds on windows to be true or false

[Michael Stahl]

On 14.10.2014 11:19, Stephan Bergmann wrote:
> On 10/14/2014 10:51 AM, Bjoern Michaelsen wrote:
>> Well, I see a good reason for that. I recently saw some bibisects being done
>> with Mikloss dbgutils bibisect repo[1] and they seem to contain more "git
>> bisect skip"s than everything else leading to less than optimal results. Now
>> the fact that the branch apparently has so many asserts that fail regulary is
>> unhealthy a topic of its own. But restricting our triaging here by failing too
>> early is to be avoided IMHO -- and building bibisects with local patches is
>> certainly a lot worse than yet-another-configure-switch.

this is a silly argument: asserts get added for a good reason, and if
assert fails then that's a bug that needs to be fixed, and you can use a
bibisect with debug enabled to track down when the bug was introduced.

if you don't want asserts in your bibisect then please build a bibisect
repo with debug disabled; that is certainly useful.

also this problem is definitely not limited to asserts, i've seen it
numerous times that i couldn't bibisect a particular bug in the repos
you built because there happened to be another bug that made things
crash at an earlier point.

> If I understand you correctly, you mean using that bibisect repo like
> 
>    $ git bisect start ...
>    $ instdir/program/soffice
>    # do something specific in LO, leads to SIGABRT
>    $ git bisect skip
>    $ instdir/program/soffice
>    # do something specific in LO, leads to SIGABRT
>    $ git bisect skip
>    ...
> 
> That sounds somewhat odd, given that at least "make check" apparently 
> does not generally trigger failing asserts, so I would not assume that 
> some random "do something specific in LO" would routinely do.  Do you 
> have an example?

it tends to happen in UI and framework code, which is hardly exercised
by current tests...