Re: [B2-devel] SheepShaver commit efa32be9e "Optimize invalidate_cache_range()..." linked to obscure crash

[Alexei S. <ale...@gm...>]

On Thu, Aug 9, 2012 at 12:15 AM, Alexei Svitkine
<ale...@gm...> wrote:
> I am not convinced that the revision in question is the cause of the
> issue you're seeing.
>
> I've read over that change and it seems correct to me. Perhaps
> something else is going wrong that is corrupting the internal state of
> those linked lists and that change merely exposes the issue?
>
> Could you actually debug this and verify that the two paths in that
> function end up invalidating different nodes?
>
> One way to do it would be with something like (mailer-code - may need tweaking):
>
>         std::vector<entry*> entries;
>         entry *p, *q;
>         if (cacheline(start) < cacheline(end - 1)) {
>                 // Optimize for short ranges flush
>                 const int end_cl = cacheline(end - 1);
>                 for (int cl = cacheline(start); cl <= end_cl; cl++) {
>                         p = cache_tags[cl];
>                         while (p) {
>                                 q = p;
>                                 p = p->next_same_cl;
>                                 if (q->intersect(start, end)) {
>                                         entries.push_back(q);
>                                 }
>                         }
>                 }
>         }
>
>         int index = 0;
>         p = active;
>         while (p) {
>                 q = p;
>                 p = p->next;
>                 if (q->intersect(start, end)) {
>                         if (entries[index++] != q)
>                                 abort();
>                         q->invalidate();
>                         remove_from_cl_list(q);
>                         remove_from_list(q);
>                         delete_blockinfo(q);
>                 }
>         }

Sorry, I think the code I suggested may not be quite right to check this as it
assumes the order of the nodes found is the same between the two
paths. It probably isn't - so you may need to save the results of the
two paths into separate vectors and sort them before comparing. But
you get the idea. (I hope...)

-Alexei
>
> If it does indeed hit the abort() code, maybe you can dump the state
> of the linked lists and narrow down where the state gets corrupted?
>
> -Alexei
>
>
> On Wed, Aug 8, 2012 at 9:50 PM, Josh Juran <jj...@gm...> wrote:
>>
>> Hi,
>>
>> I've bisected a crash in one of my programs running in SheepShaver to
>> this commit:
>>
>>         commit efa32be9ec44956c77e5001e31bebce151cb2ad6
>>         Author: gbeauche <>
>>         Date:   Sat Jul 21 10:25:51 2007 +0000
>>
>>                 Optimize invalidate_cache_range() for short ranges.
>>
>> I applied 7bb230ab "apparently this makes newest SDL happy" to each
>> checkout I tested to get SheepShaver to run at all.  This is in Mac
>> OS X 10.4 "Tiger" for Intel.
>>
>> The issue occurs only rarely, with regard to what triggers it, but
>> it's 100% reproducible.  To reproduce:
>>
>> * Launch MacRelix
>> * Run `git --version`
>> * cd into a Git repo (I only tried my metamage repo)
>> * Run `time git status` with git v1.7.6
>>
>> One of three failure modes occurs:
>>
>> * SheepShaver exits immediately
>> * The guest OS hangs and SheepShaver consumes maximum CPU
>> * The command completes with garbled output, having failed to
>> recognize its input
>>
>>         $ time /git status
>>         10-102.964309e-3152200othing added.
>>         0x1.0002400000000p-1023ybe you wanted to say 'git add .'?
>>
>>         real 0.07
>>         user 0.00
>>         sys  0.07
>>
>> No failure occurs with any of the following:
>>
>> * Don't run `git --version` first
>> * Run `git status` without `time`
>> * Use git v1.7.5 instead of v1.7.6
>> * Use a git binary built with symbolics (i.e. enabled to run in the
>> Metrowerks debugger)
>> * Run in Classic instead of SheepShaver
>> * Use a SheepShaver built with the optimization reverted
>>
>> If I cd before running `git --version`, the error message is
>> displayed ungarbled (which is still wrong, since the repo isn't empty).
>>
>> If I use an optimized build instead, I get a different error:
>>
>>         fatal: bad config value for 'core.repositoryformatversion' in .git/
>> config
>>
>> Since efa32be9e is at best an optimization and demonstrably causes
>> problems, I suggest it be reverted immediately.
>>
>> Josh
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> basilisk-devel mailing list
>> bas...@li...
>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel