System used: Linux Fedora Core 2.
Python version: Python 2.3.3 (#1, May  7 2004, 10:31:40)
------------------------------------------------

Depending on the build used for Java, its invocation
through os.system within a thread causes a segmentation
fault. The attached short program illustrates this problem.

Any Java class 'DoNothing.class' (also attached) in the
current directory will do. Notice that only the second
one of the two builds 04 and 05 causes this problem.

It migh be a Java problem but I tried the same thing
with pthreads in C, and no problems occured.

-- Tomasz Kowaltowski

Logged In: YES 
user_id=33168

This sounds like an environment problem.  I'm guessing that
the stack is being blown and the kernel is killing the
process.  It's java that's dying, not python, correct?  

I don't have _05.  _04 works fine for me one Fedora 1.  Can
you use strace or gdb to try to determine what's happening?
 I'm not sure if anyone will be able to reproduce this
problem.  Can you also try starting java with options to
lower the the memory consumption, e.g., -Xss -Xmx.

From your shell you can also try raising stack size, etc
with ulimit.  This may get java to run ok.  -s changes the
stack size.  BTW, what does ulimit -a report?

Logged In: YES 
user_id=185428

I tried all these things. Adding 'strace' to the command
line to be executed reports a segmentation fault which was
already expected because of the error code 11 printed by the
Python test program. 'ulimit -a' reports everything that
counts unlimited. I also tried Java memory options without
any success. You are right -- it is the java that is dying
not Python, but it only happens under this unusual circumstance.

It seems to me that if it were an environment problem it
would happen within any call of os.system. It happens
however only within Python threads: I tested both packages
'thread' and 'threading' and they both had the same
behavior. It does not happen if no threads are envolved, or
if threads are programmed in C.

Logged In: YES 
user_id=33168

There's another possibility, but I'm not sure if it would
affect your build or not.  It's possible to set a smaller
stack size when creating a thread.  This would mean that
THREAD_STACK_SIZE is set.  If you look in
./Python/thread_pthread.h you will see the references. 
THREAD_STACK_SIZE is not set on my box.  

In your C test, did you pass NULL for the attributes or did
you do pthread_attr_init().  It's possible that is the
difference between your C test and python.  You might try
mucking in ./Python/thread_pthread.h to see if you can
determine what is happening.

Logged In: YES 
user_id=185428

I did not find the file 'thread_pthread.h' under my
installation :-(.  My program in C is:

----------------------------------------------------------
#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>

void *ExecuteCommand( void *ptr ) {
  char *command = ptr;
  int result = system(command);
  printf("Tested the command: %s; result =
%d\n",command,result);
  return NULL;
 } 

int main()
{
  pthread_t thread;
  pthread_create(&thread,NULL,ExecuteCommand,
       (void*)"/usr/java/j2sdk1.4.2_04/bin/java -cp .
DoNothing");
  pthread_join(thread,NULL);
  pthread_create(&thread,NULL,ExecuteCommand,
       (void*)"/usr/java/j2sdk1.4.2_05/bin/java -cp .
DoNothing");
  pthread_join(thread,NULL);
  return 0;
}
----------------------------------------------------------

It correctly prints 0 for both threads.

Logged In: YES 
user_id=185428

Tested with the alpha version Python-2.4a3. It works properly!

Logged In: YES 
user_id=80475

So, can this be closed as "out-of-date"?

Logged In: YES 
user_id=185428

I guess so even though 2.4 is still alpha.