Hi Kurtis, Thanks for the reply. I was giving C code to show the behavior of defunct with threads still executing in a process. I do feel defunct process should not have any associated resources or threads held. Could be an issue with this Linux version, will check on the behavior in Linux community why defunct still showing threads with resources.
I was giving this C example to check if the go process may be hitting into the same situation. Thanks again for the time. Thanks & Regards, Uday Kiran On Thursday, September 10, 2020 at 11:00:57 PM UTC-7 ba...@iitbombay.org wrote: > 1. Looks like*something* in ps reports process/thread state incorrectly. > It should not report <defunct> until all the pthreads have exited and the > parent has not picked up the status. The runtime will call exit() when the > last thread terminates (exit() in turn will call the _exit syscall). > > 2. If any thread calls _exit(), the system will clean up everything. It > doesn't matter how many threads may be active. You can see this for > yourself if you replaced pthread_exit() in main() with _exit(0). > > 3. stacktrace within the kernel mode is irrelevant. You are merely > confusing yourself. > > 4. Go runtime doesn't use pthread so not sure testing pthread based C > program is relevant. Exiting from func main() will kill all goroutines. > Copy https://play.golang.org/p/zRfhvfYt_oE locally and see for yourself. > > 5. Looking at your original message, it *seems* like a parent is not > picking up the child's status. But I can't be sure. > > I suspect you are on a wild goose chase. Possibly confused by ps. You may > wish to backtrack to whatever you were looking at before this <defunct> > came up. Or try explaining what is going on with your go program and what > you expect it should do, without stacktrace or C programs etc. > > I wouldn't switch to a newer kernel if I were you. When debugging you > should keep everything else fixed or else you may end up chasing something > different or the symptom may change or disappear. > > On Sep 10, 2020, at 10:08 PM, Uday Kiran Jonnala <juday...@gmail.com> > wrote: > > Thanks Kurtis for the reply. I understand defunct process mechanism. > > As I mentioned in the initial mail, [Correct me if I am wrong here], In a > process if there is main thread and a detached thread created by main > thread, when the main thread exits the process is kept in defunct state, > since the created thread is still > executing, I was thinking if we have such scenario in go runtime. That > could be the reason I see this thread is waiting on futex and holding the > file handles and causing the go process (kernel) not to send SIGCHLD to > parent process. > > For example below case > > #include <stdio.h> > #include <pthread.h> > #include <unistd.h> > #include <stdlib.h> > > void *thread_function(void *args) > { > printf("The is new thread! Sleep 20 seconds...\n"); > sleep(100); > printf("Exit from thread\n"); > pthread_exit(0); > } > > int main(int argc, char **argv) > { > pthread_t thrd; > pthread_attr_t attr; > int res = 0; > res = pthread_attr_init(&attr); > res = pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED); > res = pthread_create(&thrd, &attr, thread_function, NULL); > res = pthread_attr_destroy(&attr); > printf("Main thread. Sleep 5 seconds\n"); > sleep(5); > printf("Exit from main process\n"); > pthread_exit(0); > } > > ujonnala@ ~/mycode/go () $ ps -T > PID SPID TTY TIME CMD > 43635 43635 pts/29 00:00:00 a.out <defunct> > 43635 43638 pts/29 00:00:00 a.out > > Due to the detached thread still executing the process left in defunt > state. > > Thanks for checking on this, I will see if we can reproduce my situation > on a newer kernel. > > Thanks & Regards, > Uday Kiran > > On Thursday, September 10, 2020 at 9:49:06 PM UTC-7 Kurtis Rader wrote: > >> On Thu, Sep 10, 2020 at 9:25 PM Uday Kiran Jonnala <juday...@gmail.com> >> wrote: >> >>> Thanks for the reply. We are fixing the issue. But the point I wanted to >>> bring it up here is the issue of a thread causing the go process to be in >>> defunct state. >>> >> >> Any thread can cause the go process to enter the "defunct" state. For >> example, by calling os.Exit(), or panic(), or causing a signal to be >> delivered that terminates the process (e.g., SIGSEGV). >> >> >>> My kernel version is >>> Linux version 4.14.175-1.nutanix.20200709.el7.x86_64 (dev@ca4b0551898c) >>> (gcc version 7.3.1 20180303 (Red Hat 7.3.1-5) (GCC)) #1 SMP Fri Jul 10 >>> 02:17:54 UTC 2020 >>> >> >> Is that the output of `uname -a`? It seems to suggest you're using CentOS >> provided by the https://www.nutanix.com/go/linux-on-ahv cloud >> environment. So we've established you are using Linux with kernel version >> 4.14. A kernel that is now three years old. I don't have anything like it >> installed on any of my virtual machines so I can't explore how it handles >> defunct processes. But my prior point stands: A "defunct" process is one >> that has been terminated but whose parent process has not reaped its exit >> status. Either that parent process has a bug (the most likely explanation) >> or your OS has a bug. >> >> -- >> Kurtis Rader >> Caretaker of the exceptional canines Junior and Hank >> > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/ad4843e1-f7d1-43ae-8091-579bc61527fdn%40googlegroups.com > > <https://groups.google.com/d/msgid/golang-nuts/ad4843e1-f7d1-43ae-8091-579bc61527fdn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/e40f891c-304b-4f41-b7fb-81926d897326n%40googlegroups.com.
