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
1. Looks like*something* in ps reports process/thread state incorrectly. It
should not report 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
Your example is a C program. I'm guessing you're using gccgo to link with
equivalent C code. In which case your question has almost nothing to do
with Go. You need to ask the Linux community why your example results in a
defunct process that appears to have a live thread.
I do not believe you
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
On Thu, Sep 10, 2020 at 9:25 PM Uday Kiran Jonnala
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.
Hi Ian, Kurtis,
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.
My kernel version is
Linux version 4.14.175-1.nutanix.20200709.el7.x86_64 (dev@ca4b0551898c)
(gcc version 7.3.1
On Thu, Sep 10, 2020 at 5:09 PM Kurtis Rader wrote:
>
> A defunct process is a process that has terminated but whose parent process
> has not called wait() or one of its variants. I don't know why lsof still
> reports open files. It shouldn't since a dead process should have its
> resources,
A defunct process is a process that has terminated but whose parent process
has not called wait() or one of its variants. I don't know why lsof still
reports open files. It shouldn't since a dead process should have its
resources, such as its file descriptor table, freed by the kernel even if
the
Hi Ian,
Again. Thanks for the reply. Problem here is we see go process is in defunt
process and sure parent process did not get SIGCHILD and looking deeper,
I see a thread in futex_wait_queue_me. If we think we are just getting the
stack trace and the go process actually got killed, why would
On Mon, Sep 7, 2020 at 12:03 AM Uday Kiran Jonnala wrote:
>
> Thanks for the reply, I get the point on zombie, I do not think the issue
> here is parent not reaping child, seems like go process has not finished
> execution of some
> internal threads (waiting on some futex) and causing SIGCHILD
Hi Ian,
Thanks for the reply, I get the point on zombie, I do not think the issue
here is parent not reaping child, seems like go process has not finished
execution of some
internal threads (waiting on some futex) and causing SIGCHILD not to be
sent to parent.
go process named hit with panic
On Thu, Aug 27, 2020 at 10:01 AM Uday Kiran Jonnala
wrote:
>
> I have a situation on zombie parent scenario with golang
>
> A process (in the case replicator) has many goroutines internally
>
> We hit into panic() and I see the replicator process is in Zombie state
>
> <<>>>:~$ ps -ef | grep
I have a situation on zombie parent scenario with golang
A process (in the case replicator) has many goroutines internally
1. We hit into panic() and I see the replicator process is in Zombie
state
<<>>>:~$ ps -ef | grep replicator
root 87548 87507 0 Aug23 ?00:00:00
13 matches
Mail list logo
