[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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

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

	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.


#!/usr/bin/env python

import os

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

#include <unistd.h>
#include <stdio.h>

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

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


Output of testsys.py

testing system
ret is  11


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

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 "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

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.

Reply to: