Development

hrev48986.

I closed HaikuDepot after rating a package and it crashed.

fixed:

Fixed in hrev48985.

Putting the add-ons uses the dormant node manager of the BMediaRoster. The BMediaRoster must therefore only be quit after all add-ons are put. Putting the add-ons uses the dormant node manager of the BMediaRoster. The BMediaRoster must therefore only be quit after all add-ons are put.

The hash table member still uses the element array memeber to clear itself on destruction. We must therefore ensure that the element array isn't destroyed before the hash table. Since the destruction order of memebers is the reverse order of their declaration, reordering them is enough. The hash table member still uses the element array memeber to clear itself on destruction. We must therefore ensure that the element array isn't destroyed before the hash table. Since the destruction order of memebers is the reverse order of their declaration, reordering them is enough.

The BShelf sets itself as a handler on the containing view on creation but didn't unset itself on destruction. When the containing view was later destroyed it would unset the shelf which triggered a use-after-free if you deleted the BShelf beforehand. Since the ownership of a BShelf isn't explicitly documented I took the shelf in DeskWindow of Tracker as a reference, which does delete it explicitly. The BShelf sets itself as a handler on the containing view on creation but didn't unset itself on destruction. When the containing view was later destroyed it would unset the shelf which triggered a use-after-free if you deleted the BShelf beforehand. Since the ownership of a BShelf isn't explicitly documented I took the shelf in DeskWindow of Tracker as a reference, which does delete it explicitly.

The inner loop to skip the function declaration stops at the terminating null but didn't break out of the loop in that case, causing the outer loop increment to skip the terminator and read beyond the string end. Well formatted symbols do not trigger this, but there sometimes are false positives that would cause it to happen. It was seen in Debugger that reuses this code. The inner loop to skip the function declaration stops at the terminating null but didn't break out of the loop in that case, causing the outer loop increment to skip the terminator and read beyond the string end. Well formatted symbols do not trigger this, but there sometimes are false positives that would cause it to happen. It was seen in Debugger that reuses this code.

See screenshot

I wold like to remove the default height parameter in the BRow constructor and add a default constructor. The default constructor will use the be_plain_font->Size to set the height.

This is the result

Is anyone against it?

260 MB

260 MB

261 MB

262 MB

Was using Google search when Webpositive failed to respond and locked up.
Tried to use process controller to see what was using CPU cycles, but that locked up as well.
See attached screenshot.

hrev48982 x86_gcc2
USB mouse stalls for several seconds then resumes
Attached syslog appears to show error

Spin-off from #11752:

When you run Haiku without interruption for days, ProcessController shows increasing memory usage for some apps.

We first realized about it by watching memory use for our apps, whose same versions didn't seem to leak in late 2014/early 2015 (or to rephrase, we didn't get reports from stations, whereas now they seem to need to reboot from memory exhaustion after a few days, which prompted us to run a 10 days test with the result below).

But it seems to also occur on Haiku apps (Deskbar, media_server ..etc), so time to start this ticket and gather more data, and confirm/infirm the suspicion.

Ticket to be dispatched to sub-tickets/modified/closed as invalid depending on outcome of data gathering.

I have today tried to boot Haiku, standard gcc2 version, gcc4 hyrbrid and 64-bit version on a ASUS305XU laptop. On all three versions of Haiku, I get the same error message.
* PANIC *
gKernelArgs.arch_args.pgables overflow
Pre a key to reboot