Le 16/02/2021 à 12:49, Richard Purdie a écrit :
> On Sat, 2021-02-13 at 18:40 +0100, Laurent Vivier wrote:
>> Le 08/01/2021 à 18:46, Richard Purdie a écrit :
>>> When using qemu-i386 to run gobject introspection parts of a webkitgtk
>>> build using musl as libc on a 64 bit host, it sits in an
On Sat, 2021-02-13 at 18:40 +0100, Laurent Vivier wrote:
> Le 08/01/2021 à 18:46, Richard Purdie a écrit :
> > When using qemu-i386 to run gobject introspection parts of a webkitgtk
> > build using musl as libc on a 64 bit host, it sits in an infinite loop
> > of mremap calls of ever
Le 08/01/2021 à 18:46, Richard Purdie a écrit :
> When using qemu-i386 to run gobject introspection parts of a webkitgtk
> build using musl as libc on a 64 bit host, it sits in an infinite loop
> of mremap calls of ever decreasing/increasing addresses.
>
> I suspect something in the musl memory
Cc'ing maintainer
On 1/22/21 10:37 AM, Richard Purdie wrote:
> On Fri, 2021-01-08 at 17:46 +, Richard Purdie wrote:
>> When using qemu-i386 to run gobject introspection parts of a webkitgtk
>> build using musl as libc on a 64 bit host, it sits in an infinite loop
>> of mremap calls of ever
On Fri, 2021-01-08 at 17:46 +, Richard Purdie wrote:
> When using qemu-i386 to run gobject introspection parts of a webkitgtk
> build using musl as libc on a 64 bit host, it sits in an infinite loop
> of mremap calls of ever decreasing/increasing addresses.
>
> I suspect something in the
When using qemu-i386 to run gobject introspection parts of a webkitgtk
build using musl as libc on a 64 bit host, it sits in an infinite loop
of mremap calls of ever decreasing/increasing addresses.
I suspect something in the musl memory allocation code loops indefinitely
if it only sees ENOMEM
