/boot/beos/apps Folder Tracker Segmentation Fault

[cebif]

This crash happens when clicking on the Modified or Created columns in the apps folder. It doesn't seem to happen in any other folder. Not even in a child folder. The steps to reproduce this are: 1) Navigate to /boot/beos/apps and open apps. 2) Click on Modified or Created columns. The segmentation fault happens every time. Expected results are the Modified or created column should be sorted by date. This is reproduceable every time. The version I was testing is: hrev22046 on it's own partition. I also attached a gdb output with a backtrace appended in the same file.

[stippi]

I think we have multiple bugreports now that hint something might be wrong with the sorting algorithm? Could it have been caused by my commit which put ObjectList.h or something like that into the headers/private/shared folder? And now Tracker might be using two different versions?

[bonefish]

Fixed 22113. It may be worthwhile for anyone who knew the code to check whether he potentially copied the bad compare functions elsewhere.

[axeld]

Do you have an explanation why this never occured on BeOS?

[bonefish]

Replying to axeld:

Do you have an explanation why this never occured on BeOS?

Not really. Maybe our allocator's memory layout is friendlier for exposing such bugs. If you're really interested, have a look at the old version in the debugger. A debugger() call in ColumnDragState::Clicked() right before poseView->SortPoses() will be handy. A column with all equal values will be perfect for testing. Then one can see pretty nicely how the sort()'s helper function unguarded_partition() runs out of bounds.

[jackburton]

Replying to bonefish:

Not really. Maybe our allocator's memory layout is friendlier for exposing such bugs.

Could definitely be the case. In a couple of cases, for example, I had an application deleting already freed memory working on BeOS, but crashing on haiku.