Odd crash in UB only using my own QSort

K

kuroyume

Registered
Hello all,

This is very odd. In order to do an alphanumeric sort of folders/files in a tree, I coded my own little QSort. Only the data between the items is swapped - no pointers are harmed.

This was heavily tested on Windows 32|64-bit and MacOS PPC (CodeWarrior) using the same folders/files - solid! Enter Xcode. Xcode, bless its little brain, creates code that crashes on the QSort call under odd circumstances. I can't decide if this is a stack issue (though it doesn't appear to be) or some other quirk.

MacOS 10.4.9 Intel
Xcode 2.4.1
C++
SDK plugin (dynamic library)

Any ideas?

Thank you very much,
Robert
 
Just to add: The UB crash is the same test that doesn't elsewhere. Here's the code for your perusal:

Code: 
// Alphanumerically QuickSort by content name (String path)
//*---------------------------------------------------------------------------*
void RuntimeItem::QSortRTI(RuntimeItem* rti, LONG left, LONG right)
//*---------------------------------------------------------------------------*
{
	// Do nothing if array contains fewer than two elements
	if (left >= right)	return;
	QSwapRTI(&rti[left], &rti[(left+right)>>1]);
	LONG			last =	left;
	RuntimeItem*	rt;
	for (LONG i = left+1; i <= right; ++i)
	{
		rt =	&rti[i];
		if (rt->path.LexCompare(rti[left].path) < 0)	QSwapRTI(&rti[++last], rt);
	}
	QSwapRTI(&rti[left], &rti[last]);
	QSortRTI(rti, left, last-1);
	QSortRTI(rti, last+1, right);
}
// Swap RuntimeItem data during QuickSort
//*---------------------------------------------------------------------------*
void RuntimeItem::QSwapRTI(RuntimeItem* rti, RuntimeItem* rtj)
//*---------------------------------------------------------------------------*
{
	UINT			t_itemType =	rti->itemType;
	UINT			t_poserType =	rti->poserType;
	UINT			t_iconType =	rti->iconType;
	UINT			t_flag =		rti->flag;
	// Child RuntimeItem
	RuntimeItem*	t_child =		rti->child;
	RuntimeItem*	t_sortl =		rti->sortl;
	// Dummy RuntimeItem (for folded folders)
	LONG			t_id =			rti->id;
	String			t_path =		rti->path;

	rti->itemType =					rtj->itemType;
	rti->poserType =				rtj->poserType;
	rti->iconType =					rtj->iconType;
	rti->flag =						rtj->flag;
	rti->child =					rtj->child;
	rti->sortl =					rtj->sortl;
	rti->id =						rtj->id;
	rti->path =						rtj->path;

	rtj->itemType =					t_itemType;
	rtj->poserType =				t_poserType;
	rtj->iconType =					t_iconType;
	rtj->flag =						t_flag;
	rtj->child =					t_child;
	rtj->sortl =					t_sortl;
	rtj->id =						t_id;
	rtj->path =						t_path;
}
 
Nobody? I have not yet found a reason for this crash. It is very particular and *only* UB. Even a non-recursive sort (CombSort) has the same results. This makes no sense at all. If the files are moved from this particular folder, no crash. If the folders are moved from this particular folder, no crash. And if the alphanumeric sort is removed, no crash. In every other instance, it crashes with a sort on this particular folder. That is so fubar.

Is there some Xcode setting being overlooked here? Since the CombSort has no recursion, it cannot possibly be a stack overflow issue. This is something odd in the greatest way. The same 'workflow' on other folders has no problems - just this single one so far. Maybe I'm just not looking hard enough but it consistently crashes no matter which partition of files reside in the folder. And remember that the exact same folder with PPC (CodeWarrior) or Windows (VC++) has never crashed at all (!).

~Befuddled~

Thanks,
Robert
 
If it crashes on one, particular folder, I would first suspect the folder's name... or, perhaps, a file inside of that folder.

Do any of the files or folders have funky characters in the name; perhaps, say, a semicolon? Or maybe a space or something?
 
Have you tried running it through the debugger to see which line is chokes on? You could try stepping through the entire thing (which could take a long time) or you could set multiple breakpoints in parts of the code where you think something could go wrong.
 
You must log in or register to reply here.
Back
Top