[HaikuDepot] crashes on quit

[diver]

Debug information for team /boot/system/apps/HaikuDepot (5815):
CPU(s): 1x Intel Core™ i7-3635QM
Memory: 998.88 MiB total, 623.52 MiB used
Haiku revision: hrev55867 Feb 11 2022 08:43:11 (x86_64)

Active Threads:
	thread 5815: HaikuDepot (main)
	thread 5823: Package Contents Populator 
	thread 5829: Package Populator 
	thread 5866: The Barber Machine 
	thread 8538: team 5815 debug task 
	thread 5836: w>HaikuDepot 
		state: Call (deleting referenceable object 0x10610116b728 with reference count (3414)
)

		Frame		IP			Function Name
		-----------------------------------------------
		00000000	0x1f6298d7627	_kern_debugger + 0x7 
			Disassembly:
				_kern_debugger:
				0x000001f6298d7620:   48c7c0e4000000  mov $0xe4, %rax
				0x000001f6298d7627:             0f05  syscall  <--

		0x7fd2448dcaf0	0x11a68969bb0	BReferenceable::~BReferenceable() + 0x50 
		0x7fd2448dcb50	0x11b3f0f7ed4	MainWindow::~MainWindow() + 0x154 
		0x7fd2448dcb70	0x11b3f0f7f4d	MainWindow::~MainWindow() + 0xd 
		0x7fd2448dcbb0	0x11a688485f0	BLooper::Quit() + 0x180 
		0x7fd2448dcc70	0x11a68848693	BLooper::_QuitRequested(BMessage*) + 0x33 
		0x7fd2448dcd00	0x11a68909e2b	BWindow::task_looper() + 0x1cb 
		0x7fd2448dcd20	0x11a6884815d	BLooper::_task0_(void*) + 0x1d 
		0x7fd2448dcd40	0x1f6298d63a6	thread_entry + 0x16 
		00000000	0x7fb47d44e260	commpage_thread_exit + 0

[waddlesplash]

Is the reference count always around 3000 or does it vary greatly?

[waddlesplash]

Fixed in hrev55888. However, at least for me, HaikuDepot then spins forever in cxa_finalize and uses 100% CPU, which is not good...

[diver]

Someone on Telegram reported that this is still an issue in hrev55923 with reference count 2.

[waddlesplash]

I need a new report.

[waddlesplash]

Have you reproduced this? Is there some specific sequence of operations that triggers it?

[apl-haiku]

@waddlesplash; I have seen this too recently on my system, but am currently looking into a different issue and don't have enough "hobby time" to look into this one right now unfortunately.

[tojoko]

Bug confirmed.

[tojoko]

Does that help?

[khallebal]

This report is not from the main window but when you close the dialog, it seems different from the others.

[diver]

Please file a new ticket for this issue.

[tojoko]

Replying to diver:

Please file a new ticket for this issue.

I did.

https://dev.haiku-os.org/ticket/17639

[diver]

Sorry, this was to meant to khallebal.

[waddlesplash]

Based on the attached crash reports and my own investigation, it appears there is memory corruption of some kind. Unfortunately, the guarded heap has either failed to detect it or run out of memory long before I would be able to use it. I guess the next thing is to try the debug heap with paranoid/wall checking enabled.

[waddlesplash]

Fixed in hrev55964.

[stippi]

The code was changed to use set:: containers a while back. At the time I had mixed feelings about that, because of the ugly std:: API. Now look at the fix! Unbelievable. It would have been better to keep the custom List.h an just change the implementation to be std:: based.

[apl-haiku]

@stippi; I was considering that. I started down the track of writing a "collections library" because I needed the classes to do much more; sorting, sets, binary-search etc... and then this started to turn into a big job. I also got the feeling that there will be a mismatch between the ways-of-working of STL and my bespoke "collections library" somewhere which could get awkward. So therefore my reasoning was that is better to use STL directly even though the API is not to my taste. If you want to change it back then please feel free but I think you will find it more time consuming than you think. I didn't blithely do this without consideration.

[apl-haiku]

Thanks for investigating and fixing this issue BTW.

[stippi]

Sorry if my rant came across the wrong way. Didn‘t mean to suggest it was done without good reasons. But I wonder if there isn‘t a middleground between maintaining one‘s own collection library and using the stdlib. Even just a thin wrapper around some of the most gruesome code, like a templated ListUtils::Remove(stdList, item) would seem better.

[apl-haiku]

Hi; this is a good idea and would improve the readability of the code. See #17690 for details.

[bipolar]

I'm occasionally experiencing this "crash on close" on an Atom N450 based netbook (nightly x86_64, hrev56004).

Sometimes it quits without crash. I don't recall doing anything more complex than a search, and clicking in a some package to see its info, the times it crashed at exit.

I'll attach a debug report.

[bipolar]

Debug report (hrev556004).

[waddlesplash]

This should be considered an unrelated bug and is tracked already in #17689.