Gobe Productive crashing when quitting program.

[kvdman]

Hi,

This is reproducible, Gobe Productive 2.0.1 will always crash when exiting. I'll provide the bt here. Sorry if this turns out weird, posting from within Opera/Haiku.

0xffff0102 in ?? () (gdb) bt #0 0xffff0102 in ?? () #1 0x00c2c596 in debugger () from /boot/beos/system/lib/libroot.so #2 0x00c337e5 in assert_fail () from /boot/beos/system/lib/libroot.so #3 0x00c3866a in BPrivate::hoardHeap::freeBlock ()

from /boot/beos/system/lib/libroot.so

#4 0x00c39716 in BPrivate::processHeap::free ()

from /boot/beos/system/lib/libroot.so

#5 0x00c3ada0 in free () from /boot/beos/system/lib/libroot.so #6 0x00c2a68c in builtin_delete () from /boot/beos/system/lib/libroot.so #7 0x00832ae4 in BArchivable::~BArchivable ()

from /boot/beos/system/lib/libbe.so

#8 0x0073a826 in BBitmap::~BBitmap () from /boot/beos/system/lib/libbe.so #9 0x003652da in TBitmapManager::DeleteEntry () #10 0x00364e4a in TBitmapManager::~TBitmapManager () #11 0x0035bc2c in TApp::~TApp () #12 0x00361e47 in main () (gdb)

[kvdman]

This also happens with Opera and some other apps I can't think of right now. I looked at the bt when Opera crashes on termination, and it doesn't look similar though, so I'm not sure if they're related.

[axeld]

Usually not. Apps mostly crash on Haiku because the allocator has turned on debugging, and many apps are just buggy. I don't think Gobe will be an exception here; but at least the crash will likely go away for the release (because debugging will then be turned off by default).

[jackburton]

Replying to axeld:

Usually not. Apps mostly crash on Haiku because the allocator has turned on debugging, and many apps are just buggy. I don't think Gobe will be an exception here; but at least the crash will likely go away for the release (because debugging will then be turned off by default).

By the way: we are using the hoard allocator. The version we're using is LGPL, but we can't update it to newer version because they've switched to GPL. Maybe we should consider alternative allocators, or even adapt our slab allocator to be used in userland too (AFAIK Sun did the same for their own slab allocator, cf. libumem)

[axeld]

Replying to jackburton:

By the way: we are using the hoard allocator. The version we're using is LGPL, but we can't update it to newer version because they've switched to GPL.

I know, but there is little reason to update it, it's complete. Later versions did not really change anything besides the license.

Maybe we should consider alternative allocators, or even adapt our slab allocator to be used in userland too (AFAIK Sun did the same for their own slab allocator, cf. libumem)

We can of course experiment with that, but for now, I'm all for sticking to what we have.

[korli]

Replying to jackburton:

Maybe we should consider alternative allocators, or even adapt our slab allocator to be used in userland too (AFAIK Sun did the same for their own slab allocator, cf. libumem)

Some alternatives: tcmalloc (from google perftools BSD License). nedmalloc (Boost Software License)

[kvdman]

Hi,

'Apps mostly crash on Haiku because the allocator has turned on debugging'

I'm not sure what this means... I remember Axel's presentation at Google, and he said everything ran slow and crashed because debugging was enabled. Are the vmware images at haikuhost compiled with debugging enabled, or is that how does that work?

thanks

[julun]

fixed in r28236