[Tracker] crashes in BCompressionAlgorithm::BAbstractInputStream::Read

[vidrep]

hrev49046 x86_gcc2 I was navigating the folders on an old BeOS R5 installation CD when the tracker crashed. Attached is a debug report and syslog.

[anevilyak]

Is this by any chance reproducible? If so, can you narrow it down to e.g. a particular folder on the CD?

[vidrep]

At the time I was looking for the sample movies. You know the ones...where the Be employees are throwing their monitors off the roof. I'll try to see if the error is reproducible and report back later.

[diver]

Happens too often. Should be fixed before beta.

[vidrep]

Updated to hrev49210 x86_gcc2, using "pkgman full-sync". After reboot CPU showing 100% and no mouse function. After 6 reboots, finally got "normal" Desktop with functional mouse and keyboard, but then tracker crashed. Relaunched Tracker from Team Monitor, but it crashed 2 more times. Previously it was only crashing when navigating a CD, but now is crashing after booting. I have attached all three debug reports in case they might provide a clue as to the problem.

[vidrep]

Attached syslog as well just in case it can provide useful information.

[Janus]

It is reproducible in the Terminal with

StyledEdit /boot/home/Desk/fakefile

It is almost systematic.

[waddlesplash]

Compiling libbe in debug mode stops the problem from happening :/ Trying a single-file debug info next.

[waddlesplash]

(In #11971) @Diver, no, these are two separate tickets. Read the entire ticket history again.

[waddlesplash]

Actually, this is really weird. The problem doesn't happen with any libbe except for the system's libbe, and I'm compiling the same hrev that the system libbe is on...

[waddlesplash]

OK, scratch that. It's actually a race condition of some sort, and I was triggering it in a slightly different way. I can actually reproduce it (but it's going to be really hard to get it into Debugger like this...)

[waddlesplash]

I managed to crash it there, but for some reason Debugger isn't saving the crash report with the debug information, so there's no source in it ... ? Anyway, the crash is occuring on ​this line. fInput has a value that looks real, but upon further inspection, appears to either be deleted or never initialized.

I see no reason in that thread that indicates this is a race condition, but looking at the main thread, it appears that the main thread is in the cleanup sections just before quitting. Since the crashed thread is the add poses thread (from a BFilePanel instance), it's very likely the BFilePanel this thread was for has been deleted, and thus this is really a use-after-free.

Nothing in the parameters / used variables of BAbstractInputStream look wrong, so this is the fault of Tracker's AddPosesTask for not stopping the thread when the object was deleted. Looking at Tracker's PoseView.cpp, the addPosesThread is started but never stopped, which confirms this.

I'm not sure what the correct solution is from here, though. How should the addPosesThread know to stop?

[pulkomandy]

The addPosesThread locks a BMessenger at each iteration, and if that fails, throws an exception that makes it exit the loop. However, this only works if the PoseView is destructed with the looper locked. That would make sure the thread stops running before the destruction starts. This should probably be done where the PoseView destructor is called, probably inside the window destructor?

[anevilyak]

Replying to pulkomandy:

The addPosesThread locks a BMessenger at each iteration, and if that fails, throws an exception that makes it exit the loop. However, this only works if the PoseView is destructed with the looper locked. That would make sure the thread stops running before the destruction starts. This should probably be done where the PoseView destructor is called, probably inside the window destructor?

I don't see the problem with the mentioned code. All calls that it makes to the PoseView itself occur while it holds the lock, during which it shouldn't be possible for the view to be removed/destroyed, as that's normally only done on a directory switch or window close, both of which by definition happen with the looper locked, as they're done in the message loop. If someone's deleting the view without locking the looper, then that's a bigger problem, but has nothing to do with the AddPoses thread.

[mmlr]

See #12072. I'm pretty sure these are caused the same regression. I am still unsure how to best fix the issue described there. Ideally the container would be a BReferenceable, but since it inherits from public classes, retrofitting that isn't really practical.

[mmlr]

The first and last stack trace look like #12072 and would be fixed in hrev49526. I'm not sure what to make of the other stack traces though.

[vidrep]

Tracker crashed again today with hrev49573 x86_gcc2. Open directory (all zip files) Window->select all File->Get Info Crash two times before I could restart Desktop from Team Monitor. 2 debug reports attached

[waddlesplash]

Totally unrelated. Please file a new ticket.

[diver]

Also for the crash in attachment:Tracker-486-debug-29-05-2015-11-29-30.report​​. The current one is fixed.