malloc not behaving well when brk space is limited?

malloc not behaving well when brk space is limited?

[u-igbb]

Hello,

Background:
 Compiling a native musl-based toolchain for ia32 on Linux 2.6+.
 Using the standalone dynamic loader mode.
 (The latter seems to lead to a quite limited heap space, by kernel
 behaviour/design)

I encounter out of memory errors. A look at the malloc source does not
find any fallback to mmap when heap is exhausted. What would you suggest
as a suitable approach to make it work?

Somebody has possibly already encountered and solved this with musl?

I see also reports about a related out of memory problem with
pae-executables which means a solution might help many musl users.

The other standard libraries I am using (glibc, uclibc) seem to happily
switch to allocation from mmap() when the heap is full. I understand
that this costs some code and performance but a breakup is no good either.

Any ideas? Maintaining and using an external libmalloc or substituting
malloc in musl? This feels like quite a burden...
(Would musl internal calls to malloc notice the external library
and resolve to its entry points instead of the internal malloc?)

Rune

Re: malloc not behaving well when brk space is limited?

[Timo Teras]

On Sat, 29 Mar 2014 17:00:32 +0000
u-igbb@aetey.se wrote:

> Background:
>  Compiling a native musl-based toolchain for ia32 on Linux 2.6+.
>  Using the standalone dynamic loader mode.
>  (The latter seems to lead to a quite limited heap space, by kernel
>  behaviour/design)
> 
> I encounter out of memory errors. A look at the malloc source does not
> find any fallback to mmap when heap is exhausted. What would you
> suggest as a suitable approach to make it work?
> 
> Somebody has possibly already encountered and solved this with musl?

Yes, been there done that. I patched kernel.

The thread that follows on sending the patch upstream is e.g. at:
https://groups.google.com/forum/#!msg/linux.kernel/mOf1EWrrhZc/bl96BAE4fyQJ

Also using grsec kernel would fix the issue mostly, since grsec creates
"better" memory layout for PIE binaries.

> I see also reports about a related out of memory problem with
> pae-executables which means a solution might help many musl users.
> 
> The other standard libraries I am using (glibc, uclibc) seem to
> happily switch to allocation from mmap() when the heap is full. I
> understand that this costs some code and performance but a breakup is
> no good either.
> 
> Any ideas? Maintaining and using an external libmalloc or substituting
> malloc in musl? This feels like quite a burden...
> (Would musl internal calls to malloc notice the external library
> and resolve to its entry points instead of the internal malloc?)

musl does not support external malloc. musl internal calls to
malloc() are not overridable.

I think you need to fix kernel. Rewrite allocator in musl. Or add the
fallback code to mmap - but dalias said it's "hard". Perhaps still
should be still reconsidered.

- Timo

Re: malloc not behaving well when brk space is limited?

[Rich Felker]

On Sat, Mar 29, 2014 at 07:15:02PM +0200, Timo Teras wrote:
> On Sat, 29 Mar 2014 17:00:32 +0000
> u-igbb@aetey.se wrote:
> 
> > Background:
> >  Compiling a native musl-based toolchain for ia32 on Linux 2.6+.
> >  Using the standalone dynamic loader mode.
> >  (The latter seems to lead to a quite limited heap space, by kernel
> >  behaviour/design)
> > 
> > I encounter out of memory errors. A look at the malloc source does not
> > find any fallback to mmap when heap is exhausted. What would you
> > suggest as a suitable approach to make it work?
> > 
> > Somebody has possibly already encountered and solved this with musl?
> 
> Yes, been there done that. I patched kernel.
> 
> The thread that follows on sending the patch upstream is e.g. at:
> https://groups.google.com/forum/#!msg/linux.kernel/mOf1EWrrhZc/bl96BAE4fyQJ
> 
> Also using grsec kernel would fix the issue mostly, since grsec creates
> "better" memory layout for PIE binaries.
> 
> > I see also reports about a related out of memory problem with
> > pae-executables which means a solution might help many musl users.
> > 
> > The other standard libraries I am using (glibc, uclibc) seem to
> > happily switch to allocation from mmap() when the heap is full. I
> > understand that this costs some code and performance but a breakup is
> > no good either.
> > 
> > Any ideas? Maintaining and using an external libmalloc or substituting
> > malloc in musl? This feels like quite a burden...
> > (Would musl internal calls to malloc notice the external library
> > and resolve to its entry points instead of the internal malloc?)
> 
> musl does not support external malloc. musl internal calls to
> malloc() are not overridable.
> 
> I think you need to fix kernel. Rewrite allocator in musl. Or add the
> fallback code to mmap - but dalias said it's "hard". Perhaps still
> should be still reconsidered.

Unfortunately the approach I want to use with mmap seems to be what
glibc uses for its thread-local arenas, and it performs something like
2 to 10 times worse than brk... So unless we can solve that, I don't
think it's a good option. It could be a fallback, but I still don't
want PIE binaries running that much slower just because the kernel is
doing something wacky and wrong.

We need a good solution for this problem but I don't have one yet.

Rich

Re: malloc not behaving well when brk space is limited?

[u-igbb]

On Sat, Mar 29, 2014 at 01:22:12PM -0400, Rich Felker wrote:
> On Sat, Mar 29, 2014 at 07:15:02PM +0200, Timo Teras wrote:
> > musl does not support external malloc. musl internal calls to
> > malloc() are not overridable.

Ok.

> > I think you need to fix kernel. Rewrite allocator in musl. Or add the

Too bad I can not choose the kernel on all the computers where I want my
applications to run. To the contrary I am building as portable applications
as possible. Hardly this situation is out of scope of musl (?)

> > fallback code to mmap - but dalias said it's "hard". Perhaps still
> > should be still reconsidered.
> 
> Unfortunately the approach I want to use with mmap seems to be what
> glibc uses for its thread-local arenas, and it performs something like
> 2 to 10 times worse than brk... So unless we can solve that, I don't
> think it's a good option. It could be a fallback, but I still don't
> want PIE binaries running that much slower just because the kernel is
> doing something wacky and wrong.

It is a _lot_ better to run an order of magnitude slower than to fail
totally, isn't it? If you have any code doing mmap-fallback, I would be
willing to test it and hopefully use.

> We need a good solution for this problem but I don't have one yet.

This looks like a showstopper. The applications do not work properly
as-is and replacing malloc or adding mmap support from scratch by myself
is a threshold too high, given the time constraints. :(

In other words, a bad solution would be much better than no solution.

Otherwise my impression from musl until now is excellent. Thanks
for your work on it.

Regards,
Rune

Re: malloc not behaving well when brk space is limited?

[Rich Felker]

On Sat, Mar 29, 2014 at 06:02:29PM +0000, u-igbb@aetey.se wrote:
> > Unfortunately the approach I want to use with mmap seems to be what
> > glibc uses for its thread-local arenas, and it performs something like
> > 2 to 10 times worse than brk... So unless we can solve that, I don't
> > think it's a good option. It could be a fallback, but I still don't
> > want PIE binaries running that much slower just because the kernel is
> > doing something wacky and wrong.
> 
> It is a _lot_ better to run an order of magnitude slower than to fail
> totally, isn't it? If you have any code doing mmap-fallback, I would be
> willing to test it and hopefully use.
> 
> > We need a good solution for this problem but I don't have one yet.
> 
> This looks like a showstopper. The applications do not work properly
> as-is and replacing malloc or adding mmap support from scratch by myself
> is a threshold too high, given the time constraints. :(
> 
> In other words, a bad solution would be much better than no solution.
> 
> Otherwise my impression from musl until now is excellent. Thanks
> for your work on it.

Yes, I understand. I didn't mean that this can't or shouldn't be
fixed, just that the changes I had hoped to make to malloc in the
1.1.x series are not looking like the right direction for fixing this,
so we're back to the question of what to do.

If you need a fix (or at least a workaround) right away, let me know
and I'll see if I can think of anything.

Rich

Re: malloc not behaving well when brk space is limited?

[u-igbb]

On Sat, Mar 29, 2014 at 02:56:19PM -0400, Rich Felker wrote:
> Yes, I understand. I didn't mean that this can't or shouldn't be
> fixed, just that the changes I had hoped to make to malloc in the
> 1.1.x series are not looking like the right direction for fixing this,
> so we're back to the question of what to do.
> 
> If you need a fix (or at least a workaround) right away, let me know
> and I'll see if I can think of anything.

Thanks Rich,

I would appreciate your support for any tenable solution.

The very ugly workaround which I am testing now is to temporarily
resort to the implicit loader. This seems to work, with a hack of the
kind I posted at first, introducing a "ONCE_LD_LIBRARY_PATH" variable
and renaming it afterwards (introducing the possible slight environment
corruption).

This is far from a solution, just slightly better than a complete halt.

Nevertheless I feel moving to musl if worth the effort.

So if you can think of any half-usable solution to make malloc compatible
with the standalone loader, I would happily go for it.

Regards,
Rune

Re: malloc not behaving well when brk space is limited?

[Rich Felker]

On Sat, Mar 29, 2014 at 07:54:22PM +0000, u-igbb@aetey.se wrote:
> On Sat, Mar 29, 2014 at 02:56:19PM -0400, Rich Felker wrote:
> > Yes, I understand. I didn't mean that this can't or shouldn't be
> > fixed, just that the changes I had hoped to make to malloc in the
> > 1.1.x series are not looking like the right direction for fixing this,
> > so we're back to the question of what to do.
> > 
> > If you need a fix (or at least a workaround) right away, let me know
> > and I'll see if I can think of anything.
> 
> Thanks Rich,
> 
> I would appreciate your support for any tenable solution.
> 
> The very ugly workaround which I am testing now is to temporarily
> resort to the implicit loader. This seems to work, with a hack of the
> kind I posted at first, introducing a "ONCE_LD_LIBRARY_PATH" variable
> and renaming it afterwards (introducing the possible slight environment
> corruption).
> 
> This is far from a solution, just slightly better than a complete halt.
> 
> Nevertheless I feel moving to musl if worth the effort.
> 
> So if you can think of any half-usable solution to make malloc compatible
> with the standalone loader, I would happily go for it.

I have in mind a solution which may work as a real fix, not just a
workaround. If it works out, it will probably make it into the 1.1.x
series first, but it should apply cleanly to 1.0.0. I'm pretty busy
with some other work right now so it'll be at least a few days before
I really get started on it I think.

Rich

Re: malloc not behaving well when brk space is limited?

[u-igbb]

On Sat, Mar 29, 2014 at 04:25:54PM -0400, Rich Felker wrote:
> I have in mind a solution which may work as a real fix, not just a
> workaround. If it works out, it will probably make it into the 1.1.x
> series first, but it should apply cleanly to 1.0.0.

This sounds great.

> I'm pretty busy with some other work right now so it'll be at least
> a few days before I really get started on it I think.

That's alright. I have got a workaround sufficient to continue
the building and testing but I will not commit/publish the built
applications yet.

When a more tolerable malloc arrives I can rebuild from the beginning and
only then commit to production the resulting, proper and reconfigurable
incarnation. Nice.

Tell me when you might need testing.

Thanks Rich!

Rune

Re: malloc not behaving well when brk space is limited?

[Rich Felker]

On Sat, Mar 29, 2014 at 08:54:09PM +0000, u-igbb@aetey.se wrote:
> On Sat, Mar 29, 2014 at 04:25:54PM -0400, Rich Felker wrote:
> > I have in mind a solution which may work as a real fix, not just a
> > workaround. If it works out, it will probably make it into the 1.1.x
> > series first, but it should apply cleanly to 1.0.0.
> 
> This sounds great.
> 
> > I'm pretty busy with some other work right now so it'll be at least
> > a few days before I really get started on it I think.
> 
> That's alright. I have got a workaround sufficient to continue
> the building and testing but I will not commit/publish the built
> applications yet.
> 
> When a more tolerable malloc arrives I can rebuild from the beginning and
> only then commit to production the resulting, proper and reconfigurable
> incarnation. Nice.
> 
> Tell me when you might need testing.

Please see the patch on the mailing list.

Rich