[Qemu-devel] Re: [HaikuPorts-devs] [FYI 7/8] qemu_malloc: Use areas on Haiku for sizes > 1 MiB

[Andreas Färber]

Hi,

Am 20.09.2010 um 14:26 schrieb Oliver Tappe:

> On 2010-09-20 at 00:50:49 [+0200], Andreas Färber <address@hidden 
> > 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