LinuxThreads' stacks can collide with malloc
Wolfram Gloger
wmglo@dent.med.uni-muenchen.de
Wed Nov 15 10:09:00 GMT 2000
> > The stacks are unmapped at thread exit time, so if a stack region is
> > later occupied by e.g. malloc, and still later another thread is
> > started, it may corrupt the heap due to the use of MAP_FIXED to
> > re-claim the stack region.
>
> You mean the kernel allows to mmap() with MAP_FIXED in a place below
> the sbrk? This sounds like a kernel bug.
No, when the address space gets nearly full malloc() can allocate
chunks using mmap() (w/o MAP_FIXED) so high that they collide with the
fixed regions used by LinuxThreads for the stacks.
But anyway, MAP_FIXED definitely works below sbrk, too. When you use
MAP_FIXED, you really must know what you're doing. The real problem
IMHO is that it's impossible in Unix to probe whether an address range
is available for mapping with MAP_FIXED. That would require an
additional MAP_ONLY_IF_FREE flag or something.
> > I noticed that FLOATING_STACKS can only be enabled on i686. Wouldn't
> > the ldt tricks work on i586, too?
>
> It does. Most people only build i386 and i686 versions. I wanted to
> have a way to get the version without LDT use and one with.
OK.
> In
> addition, I've never looked at the performance of the ldt use on
> anything but i686. I think these usages were improved in modern CPUs
> since M$ is using this method, too. On older versions it's dog slow.
Right, I'll do a performance check and let you know.
> We can of course change it to use this also for i586 but I want some
> evidence that this is really wanted.
I for one would really appreciate any change that lets us avoid
MAP_FIXED.
Regards,
Wolfram.
More information about the Libc-hacker
mailing list