Bug#81343: libc thread code problem in Debian Linux 2.2.17, i686

[wiener@rap.ucar.EDU (Gerry Wiener)]

Package: base

Linux amber 2.2.17 #1 SMP Thu Sep 7 11:35:24 MDT 2000 i686 unknown

I initially reported the bug below to the Python 2.0 bug list. The
author of Python responded by mentioning that he thinks it is a
problem with the libc thread code. I wanted to make sure the bug was
reported.

	Gerry Wiener	
	National Center for Atmospheric Research
	P.O. Box 3000
	Boulder, Co
	80307-3000

	Phone: (303)497-8417
	FAX:   (303)497-8401
	Email: gerry@ucar.edu




Here's a trivial example along with Python driver code which exhibits
the problem. If the size of array m is decreased, the testsys code
runs correctly under os.system(). Note that testsys1 by itself runs
fine on the same system and also runs fine when executed by system()
within a C program. We worked around this problem by configuring Python
2.0 using  --with-threads=no before doing the build.


--------------------------
testsys.py
--------------------------

#!/usr/bin/env python

import os


print 'testing system'
ret = os.system("testsys")
print 'ret is ', ret


-----------------------
testsys.c 
-----------------------
#include <unistd.h>
#include <stdio.h>

main(int argc, char **argv)
{
  int i;
  int m[1000000];

  for (i=0; i<10; i++)
    {
      sleep(1);
      printf("hello there\n");
    }

}

------------------------------
Output of testsys.py
------------------------------

testing system
ret is  11


-------------------------------------------------------

Date: 2000-Dec-06 11:37
By: gvanrossum

Comment:
Yup. The same problem happens under Linux, too. The C program crashes with a SIGSEGV, apparently because it doesn't have enough stack space.

Here's how I decode the s.system() return value:

if ret&0xff:
    print "Killed by signal", ret&0x7f,
    if ret&0x80:
        print "-- core dumped",
    print
else:
    print "Exit status", ret>>8

This prints "Killed by signal 11 -- core dumped" for me.

The bug must be in the libc thread code, which apparently limits the
stack size but doesn't reset the limit in a child process. Here's a
work-around:

ret = os.system("ulimit -s 8192; ./testsys")

I'm closing the bug report, since there's nothing that *Python* can do to avoid this problem.