"filepanel" crashes on certain key-combos

[humdinger]

This is hrev50173.

• create a save panel with "filepanel --save"
• press SHIFT + ALT + C (or X or V)

Attached the rather long full crash report. Here's a cut:

thread 900: w>filepanel: Save 
state: Exception (Segment violation)

Frame		IP			Function Name
-----------------------------------------------
0x7052e040	0x19b53e5	BPrivate::BContainerWindow::MessageReceived(BMessage*) + 0x9 
	Disassembly:
		BPrivate::BContainerWindow::MessageReceived(BMessage*):
		0x019b53dc:               55  push %ebp
		0x019b53dd:             89e5  mov %esp, %ebp
		0x019b53df:     81ec3c010000  sub $0x13c, %esp
		0x019b53e5:               57  push %edi <--

	Frame memory:
		Unavailable (Bad address)
0x7052e190	0x19f4d0b	BPrivate::TFilePanel::MessageReceived(BMessage*) + 0xa67 
0x7052e280	0x1c382b7	BHandler::MessageReceived(BMessage*) + 0x37b 
0x7052e3a0	0x1d1d58f	BView::MessageReceived(BMessage*) + 0x33b 
0x7052e490	0x1c382b7	BHandler::MessageReceived(BMessage*) + 0x37b 
.
.
.
0x7056cc00	0x19b5596	BPrivate::BContainerWindow::MessageReceived(BMessage*) + 0x1ba 
0x7056cd50	0x19f4d0b	BPrivate::TFilePanel::MessageReceived(BMessage*) + 0xa67 
0x7056cd80	0x1c3e5a5	BLooper::DispatchMessage(BMessage*, BHandler*) + 0x59 
0x7056cf60	0x1d25ed8	BWindow::DispatchMessage(BMessage*, BHandler*) + 0x182c 
0x7056cf90	0x19ef6a0	BPrivate::TFilePanel::DispatchMessage(BMessage*, BHandler*) + 0x24 
0x7056cff0	0x1d2a37a	BWindow::task_looper() + 0x28e 
0x7056d020	0x1c3fa4d	BLooper::_task0_(void*) + 0x3d 
0x7056d048	0x13aed21	thread_entry + 0x21 
00000000	0x60cd6250	commpage_thread_exit + 0 

[humdinger]

filepanel crashing on SHIFT+ALT+C

[waddlesplash]

Looks like a stack overflow. Not sure what the root cause is, but it's probably related to the "missing shortcuts in file panels" bug...

[pulkomandy]

More precisely, it seems there is an infinite recursion of this sequence:

959	        0x7056be40  0x19b5596   BPrivate::BContainerWindow::MessageReceived(BMessage*) + 0x1ba
960	        0x7056bf90  0x19f4d0b   BPrivate::TFilePanel::MessageReceived(BMessage*) + 0xa67
961	        0x7056c080  0x1c382b7   BHandler::MessageReceived(BMessage*) + 0x37b
962	        0x7056c1a0  0x1d1d58f   BView::MessageReceived(BMessage*) + 0x33b
963	        0x7056c290  0x1c382b7   BHandler::MessageReceived(BMessage*) + 0x37b
964	        0x7056c3b0  0x1d1d58f   BView::MessageReceived(BMessage*) + 0x33b
965	        0x7056c4a0  0x1c382b7   BHandler::MessageReceived(BMessage*) + 0x37b
966	        0x7056c5c0  0x1d1d58f   BView::MessageReceived(BMessage*) + 0x33b
967	        0x7056c6a0  0x1c81d1c   BControl::MessageReceived(BMessage*) + 0x300
968	        0x7056c780  0x1cfb71c   BTextControl::MessageReceived(BMessage*) + 0x290
969	        0x7056c870  0x1c382b7   BHandler::MessageReceived(BMessage*) + 0x37b
970	        0x7056c990  0x1d1d58f   BView::MessageReceived(BMessage*) + 0x33b
971	        0x7056caa0  0x1d00ff7   BTextView::MessageReceived(BMessage*) + 0x84b
972	        0x7056cc00  0x19b5596   BPrivate::BContainerWindow::MessageReceived(BMessage*) + 0x1ba

It looks like:

• Message is dispatched to a BTextView (971)
• The BTextView does not handle it, so it propagates up to BHandler (965)
• BHandler tries to propagate the message to the next handler (964) ​https://www.haiku-os.org/legacy-docs/bebook/TheApplicationKit_Messaging.html#TheApplicationKit_Messaging_Inheritance
• After a few hops through the handler chain, we end up in BPrivate::TFilePanel::MessageReceived and the message is dispatched to the window again, restarting the cycle.

[waddlesplash]

So it looks like the culprit is probably this block of code: ​http://xref.plausible.coop/source/xref/haiku/src/kits/tracker/ContainerWindow.cpp#1377

This looks mightily suspicious to me for a few reasons:

1. Why does this code exist in the first place (for the generic B_CUT/B_COPY/B_PASTE ...)? Won't the BWindow handle this by default?
2. In addition to the generic B_* messages, it's also forwarding a few k* messages which belong to Tracker and would be unrecognized by a generic view, if one were focused (and thus probably cause the infinite recursion seen here).
3. It's also locking the looper of the focused view. Why? The view will necessarily be a child view of this window, no? So why does its looper (our looper) need to be locked?

[waddlesplash]

From git-blame it looks like that code has been that way since Tracker was imported. It looks like it was added in a patch applied by axeld to the OpenTracker repo in 2002: ​https://github.com/HaikuArchives/OpenTracker/commit/e12904fef914ceb5e0ac7d7bd80fab931f4f20e4#diff-ffd6f98701ded9231c943769267a142dR1057

[axeld]

Originally it was done by Shard, not me, though. I don't know why this code is there, actually. Locking is not necessary in MessageReceived(), as the looper is always locked when processing events.

In any case, yes, this code looks suspicious. Just removing it might break Tracker's copy/paste feature, though. I guess this needs some more investigation.

[waddlesplash]

Fixed in hrev51138.