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)

Changed 12 years ago by cebif

Attachment: gdb and a backtrace.txt added

comment:1 Changed 12 years ago by stippi

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 Changed 12 years ago by bonefish

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 Changed 12 years ago by axeld

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

comment:4 in reply to:  3 ; Changed 12 years ago by 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.

comment:5 in reply to:  4 Changed 12 years ago by 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.

Note: See TracTickets for help on using tickets.