Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#1422 closed bug (fixed)

/boot/beos/apps Folder Tracker Segmentation Fault

Reported by: cebif Owned by: axeld
Priority: normal Milestone: R1
Component: Applications/Tracker Version: R1/pre-alpha1
Keywords: Cc: bonefish
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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.

Attachments (1)

gdb and a backtrace.txt (5.2 KB ) - added by cebif 12 years ago.

Download all attachments as: .zip

Change History (6)

by cebif, 12 years ago

Attachment: gdb and a backtrace.txt added

comment:1 by stippi, 12 years ago

Cc: bonefish added

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?

comment:2 by bonefish, 12 years ago

Resolution: fixed
Status: newclosed

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

comment:3 by axeld, 12 years ago

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

in reply to:  3 ; comment:4 by bonefish, 12 years ago

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.

in reply to:  4 comment:5 by jackburton, 12 years ago

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.

Note: See TracTickets for help on using tickets.