Bug #1371
closed
  
libc_r not functional with new malloc
 
        
        Added by corecode over 16 years ago.
        Updated over 16 years ago.
        
  
  
  
  Description
  
  I think the new malloc broke libc_r.  Running firefox, I get this:
	% firefox3
Fatal error 'Cannot allocate red zone for initial thread' at line ? in 
file /usr/src/lib/libc_r/uthread/uthread_init.c (errno = ?)
zsh: abort      firefox3
	cheers
   simon
   
 
 
  
  
    
    
    
    Matthew Dillon wrote:
	BTW we don't support libc_r any more.  We haven't for a while.
It is libthread_xu or nothing.
	why do we build and install it still then?  I'm trying to figure out the 
cause of MASSIVE slowdown with thunderbird and firefox, and I thought an 
alternative thread lib could help tracking it down.
	cheers
   simon
 
   
  
  
    
    
    
    fixed in 5f2211a11e7c56b07e5d8ce5c278b86d06210131
 
   
  
  
    
    
    
    :I think the new malloc broke libc_r.  Running firefox, I get this:
:
:% firefox3
:Fatal error 'Cannot allocate red zone for initial thread' at line ? in=20
:file /usr/src/lib/libc_r/uthread/uthread_init.c (errno =3D ?)
:zsh: abort      firefox3
:
:cheers
:   simon
	No, this is a bug in libc_r not using the proper MAP_* flags when
    it mmap()'s the thread stack or the thread stack's guard page.  The
    kernel previously did not catch the problem but now it does, and I
    fixed libthread_xu to use the proper MAP_ flags.
	Instead of properly generating ENOMEM or some other related failure
    when the user VM map fills up in older kernels would allow MAP_STACK
    mappings to improperly overlap MAP_STACK mapped areas, creating a
    situation where the mapped stack can dive into the non-MAP_STACK
    mapping without generating a VM fault or a guard fault, resulting in
    massive corruption instead of a clean memory allocation error.
	BTW we don't support libc_r any more.  We haven't for a while.
    It is libthread_xu or nothing.
	-Matt
 
   
  
 
  
 
Also available in:  Atom
  PDF