Re: zombie with CLONE_THREAD

From: Andreas Schwab (schwab_at_suse.de)
Date: 06/30/04

  • Next message: simon_at_nuit.ca: "Re: Cannot access '/dev/pts/292': Value too large for defined data type"
    To: Roland McGrath <roland@redhat.com>
    Date:	Wed, 30 Jun 2004 11:04:46 +0200
    
    

    Roland McGrath <roland@redhat.com> writes:

    > Are you saying that if the ptracer dies, it can leave some threads in limbo?
    > I think that case is supposed to work because forget_original_parent will
    > move all the threads ptrace'd by the dying tracer process to be ptrace'd by
    > init, which will then clean up their zombies as previously described.

    Here is the test case, run it with "strace -f ./clone". When the bug
    happens then strace is stuck waiting for it's traced child that just died,
    but you may have to try a few times before it happens.

    
    

    #include <stdio.h>
    #include <signal.h>
    #include <sched.h>
    #include <unistd.h>
    #include <sys/types.h>
    #include <sys/mman.h>

    extern int __clone (int (*__fn) (void *__arg), void *__child_stack,
                        int __flags, void *__arg, ...);
    extern int __clone2 (int (*__fn) (void *__arg), void *__child_stack_base,
                         size_t __child_stack_size, int __flags, void *__arg, ...);

    static int thread (void *arg)
    {
      write (2, "thread\n", sizeof ("thread\n"));
      *(volatile int *) 0;
      return 0;
    }

    #define STACK_SIZE 1024 * 1024
    #define CLONE_FLAGS CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM

    int
    main (void)
    {
      void *stack = mmap (0, STACK_SIZE, PROT_READ|PROT_WRITE,
                          MAP_ANON|MAP_PRIVATE, -1, 0);
      pid_t pid;

    #ifdef __ia64__
      pid = __clone2 (thread, stack, STACK_SIZE - 64, CLONE_FLAGS, 0);
    #else
      pid = __clone (thread, stack + STACK_SIZE - 64, CLONE_FLAGS, 0);
    #endif
      printf ("pid = %d\n", pid);
      sleep (1);
      return 0;
    }

                

    
    

    Andreas.

    -- 
    Andreas Schwab, SuSE Labs, schwab@suse.de
    SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
    Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
    "And now for something completely different."
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at  http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at  http://www.tux.org/lkml/
    

  • Next message: simon_at_nuit.ca: "Re: Cannot access '/dev/pts/292': Value too large for defined data type"

    Relevant Pages

    • RE: Hugetlb demanding paging for -mm tree
      ... >> to have correct functionality for hugetlb demand paging. ... +static void scrub_one_pmd ... *, int); ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: i386 entry.S problems
      ... > kernel; nothing can legitemately use them and in the last few years ... -asmlinkage void lcall27; ... static void __init set_task_gate(unsigned int n, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] deinline sleep/delay functions
      ... void ndelay(unsigned int nsecs) ... any delay function. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [RFC 4/5] sysfs-attr_group.patch
      ... +static void remove_files(struct sysfs_dirent * sd, ... +static int create_files(struct sysfs_dirent * parent_sd, ... void sysfs_remove_group(struct kobject * kobj, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • [2/4] consolidate bit waiting code patterns
      ... -static inline int sync_page ... +static inline void wake_up_page ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)