Hi,
Am 20.09.2010 um 14:26 schrieb Oliver Tappe:
On 2010-09-20 at 00:50:49 [+0200], Andreas Färber <andreas.faer...@web.de
> wrote:
Works around a calloc() SEGV in Haiku's libroot.
Cf. http://dev.haiku-os.org/ticket/6637
Ported to HEAD based on a patch by Michael "mmlr" Lotz.
Also consider the limit when reallocating.
Were you able to run any image in qemu on haiku with this?
As indicated, I built the ppc-softmmu system emulation. I was able to
both play around in OpenBIOS [1] and to try booting Haiku/ppc [2],
which doesn't go far due to OpenBIOS ofmem issues (cf. #6071).
i386-softmmu needs more patches to compile. Haiku's math.h is missing
some POSIX macros like isless[equal], isgreater, isunordered. That
should be fixed in Haiku imo instead of being worked around in QEMU.
QEMU's softfloat code has a wild mix of int32 and int though that may
need to be remedied then, I have a patch in preparation for that.
[1] qemu-system-ppc /dev/null
[2] qemu-system-ppc -boot d -cdrom path/to/haiku-boot-cd-ppc.iso
I'm asking because of haiku ticket #6606, which is about some
problematic behaviour
with respect to qemu not being able to resize an area (in effect
aborting). Looking at
the patch, I'd say it should still do the same ...
I had taken a look at #6606 and tried
LD_PRELOAD=libroot-icu-addon.so qemu-system-ppc /dev/null -nographic
without any luck.
Note that vanilla QEMU does not use any areas at all, it uses
malloc(), calloc(), realloc() and free().
The areas were just a workaround my mmlr and, to not miscredit him, he
had the following explanation in his patch:
+/*
+ The reason for the following mess is that somehow large allocations
seem
+ to cause memory curruption. Most likely this is a bug in either
Haiku or
+ QEMU. Since I wasn't able to repoduce the issue with other Haiku
software
+ my first guess would go to QEMU, but who knows. In any case the hack
below
+ makes larger allocations (>= 1MB) using areas instead of using the
heap
+ to work around said issue. TODO: remove this when the reason is
found/fixed!
+*/
(I personally rather believe it's a bug in Haiku and that most BeOS/
Haiku apps don't encounter it since they use C++ new/new[]/delete/
delete[] but no realloc. But no one knows for sure until we've found
out.)
As seen in this patch of mine, QEMU has a new tracing framework that
should (once it compiles - Haiku doesn't have clock_gettime) show us
all successful (re)allocations and a build configured with --disable-
strip shows us the crashing calloc args in gdb, so we could exactly
reproduce the allocations and find out if that triggers it or not.
Andreas
