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

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

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);
		}
	}

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