[Tracker] wrong column display + crash in BBitmap::Lock()

[ttcoder]

A tunetracker customer made a detailed report to us; seems using folders that were originally created/manipulated in Zeta sometimes makes Haiku's Tracker display the columns as 'blank' and even crash if re-arranging them.

[ttcoder]

backtrace of segv crash

[axeld]

Do you happen to be able to reproduce it? If so, can you zip up such a folder, and attach it to this ticket?

[ttcoder]

the trigger event: adding a new column

[ttcoder]

immediate result: columns become messed up, "infinite" in width

[ttcoder]

a third symptom that occurs sometimes: column cells display "- -" when empty (instead of the normal "-")

[ttcoder]

@axel that's my thought as well: this should be reproducible if getting the "trk_/*" attributes; I'll ask him to empty the folder of its files, and zip it up (to preserve the layout attributes) and attach it here. Hang on.

[ttcoder]

Triggers the "column width" problem with the right FileTypes config

[ttcoder]

Seems #9444 which I just filed, might be the root cause of it all.

• I unzipped the above in a "factory settings" haiku install, which had just Artist/Title/Album ..etc attributes configured, and could not see problems when adding any of these.
• I then tried in my dev. partition, which is setup with out "tunetracker:volume_boost", "tunetracker:off_ramp" ..etc attributes, and there I was able to see the "wide column" problem indeed, when adding VolumeBoost (didn't see a crash, but didn't dig for it very deep either).

So the economy -of-force approach here is probably to tackle #9444 first, and maybe it will fix the problem and then we can close this ticket as duplicate of that ticket :-)

[axeld]

That would be the lazy way, as Tracker should not crash on reading invalid settings. One should fix this bug first, and the go for the root cause instead :-)

[ttcoder]

This would probably be a quick fix once pinpointed, so I won't be a PITA arguing with you about how you should spend or not your coding time ;-) A couple thoughts on the "pinpointing" however..

• didn't reproduce the crash itself in my quick test in #9444, so either I didn't try hard enough, or it's not enough to have the column-width set to 4000 pixels and one needs something else, maybe the type_code set to #?*! or maybe something else
• even if not primarily aimed at closing this ticket, #9444 could however inspire a "test case", pinpoint which field Tracker is "crashy" on.. I see that siarzhuk has assigned himself to that other ticket.

[ttcoder]

For the record,

The fix in hrev45275 has this key part:

+		fStatus(B_NO_INIT),
+		fType('CSTR'),
+		fViewable(true),
+		fEditable(false),
+		fExtra(false),
+		fWidth(0),
+		fAlignment(0)

So anyone looking for a vulnerability / a way to crash Tracker might want to create an intentionally broken version of setmime that changes the above to fWidth(4000.0), fType(0xdeadbeef) ..etc and maybe that will do the trick, opening a folder / the resulting column will crash...

[waddlesplash]

Should this be closed since it's fixed? Or left open because the bug in Tracker still exists, only buried?

[ttcoder]

No opinion either way from me, we're moving away from Tracker and to ArmyKnife instead for our editing needs, since we've added complex attributes (BMessage-in-BMessage ..etc) that won't fit in Tracker columns any more. I see the logic in axel's wish to leave this open though.