comp.lang.ada
 help / color / mirror / Atom feed
* fork; execve --> defunct process.
@ 2000-01-18  0:00 Bobby D. Bryant
  2000-01-18  0:00 ` Mats Weber
                   ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: Bobby D. Bryant @ 2000-01-18  0:00 UTC (permalink / raw)


I am trying to get a program to start a second job.  I import fork() and
execve() from C, and the calls apparently work OK (i.e., the fork
returns a legitimate PID, and the execve returns a non-negative status).

However, the child process immediately(?) goes into "defunct" status.
For example, if I try to run the testgtk program, the program's GUI
never pops up, and a ps x shows:

    29765 pts/6    ZN     0:00 [testgtk <defunct>]

The parent process continues without any apparent problem.  I have tried
different programs for the child process to run, and all have the same
problem.

I am using GNAT 3.12p under Linux/glibc 2.1.

Help/suggestions/explanations will be appreciated.

Thanks,

Bobby Bryant
Austin, Texas






^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: fork; execve --> defunct process.
  2000-01-18  0:00 fork; execve --> defunct process Bobby D. Bryant
@ 2000-01-18  0:00 ` Mats Weber
  2000-01-18  0:00   ` Bobby D. Bryant
  2000-01-18  0:00 ` Mats Weber
  2000-01-19  0:00 ` Mario Klebsch
  2 siblings, 1 reply; 8+ messages in thread
From: Mats Weber @ 2000-01-18  0:00 UTC (permalink / raw)


"Bobby D. Bryant" wrote:
> 
> I am trying to get a program to start a second job.  I import fork() and
> execve() from C, and the calls apparently work OK (i.e., the fork
> returns a legitimate PID, and the execve returns a non-negative status).

execve never returns if it succeeds. What are you doing between fork and
execve in the child ?

> However, the child process immediately(?) goes into "defunct" status.
> For example, if I try to run the testgtk program, the program's GUI
> never pops up, and a ps x shows:

defunct means that the process is finished, but its parent does not know
yet. To avoid defunct processes, you must do a waitpid for the child in
the parent.




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: fork; execve --> defunct process.
  2000-01-18  0:00 fork; execve --> defunct process Bobby D. Bryant
  2000-01-18  0:00 ` Mats Weber
@ 2000-01-18  0:00 ` Mats Weber
  2000-01-19  0:00 ` Mario Klebsch
  2 siblings, 0 replies; 8+ messages in thread
From: Mats Weber @ 2000-01-18  0:00 UTC (permalink / raw)


"Bobby D. Bryant" wrote:

> Help/suggestions/explanations will be appreciated.

Post the relevant parts of your code.




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: fork; execve --> defunct process.
  2000-01-18  0:00 ` Mats Weber
@ 2000-01-18  0:00   ` Bobby D. Bryant
  2000-01-19  0:00     ` Mats Weber
  2000-01-21  0:00     ` Robert A Duff
  0 siblings, 2 replies; 8+ messages in thread
From: Bobby D. Bryant @ 2000-01-18  0:00 UTC (permalink / raw)


Mats Weber wrote:

> execve never returns if it succeeds.

That's fine.


> What are you doing between fork and
> execve in the child ?

Nothing except check for PID = 0, plus whatever overhead is involved in a
function call, since I've got everything under wrappers.


> > However, the child process immediately(?) goes into "defunct" status.
> > For example, if I try to run the testgtk program, the program's GUI
> > never pops up, and a ps x shows:
>
> defunct means that the process is finished, but its parent does not know
> yet. To avoid defunct processes, you must do a waitpid for the child in
> the parent.

Fine, but that's not my problem; I'll clean up the completed child processes
iff I ever get them to run correctly.

My problem is: why are the children going defunct immediately, rather than
running the requested programs?  I am getting core files for them, but they
should not be bombing off, since they include programs that run well on their
own (Electric Eyes, testgtk, etc.).

The child process is created, execve returns a non-negative status, and the
child process picks up the name of the requested program, but it apparently
cores out before it actually does anything.

Has anyone here used execve from Ada?  Is there a special trick required to
get it to work?  Does the child process get into a confused state when execve
tries to have it jump out of the middle of a running Ada program?  I.e., are
there leftover structures from Ada's run-time checking and/or task management
system that are not cleanly erased when execve is called?  (I'm not
explicitly using tasks, but I assume the run-time infrastructure is there
anyway.)

Thanks,

Bobby Bryant
Austin, Texas






^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: fork; execve --> defunct process.
  2000-01-18  0:00 fork; execve --> defunct process Bobby D. Bryant
  2000-01-18  0:00 ` Mats Weber
  2000-01-18  0:00 ` Mats Weber
@ 2000-01-19  0:00 ` Mario Klebsch
  2 siblings, 0 replies; 8+ messages in thread
From: Mario Klebsch @ 2000-01-19  0:00 UTC (permalink / raw)


"Bobby D. Bryant" <bdbryant@mail.utexas.edu> writes:

>I am trying to get a program to start a second job.  I import fork() and
>execve() from C, and the calls apparently work OK (i.e., the fork
>returns a legitimate PID, and the execve returns a non-negative status).

>However, the child process immediately(?) goes into "defunct" status.
>For example, if I try to run the testgtk program, the program's GUI
>never pops up, and a ps x shows:

>    29765 pts/6    ZN     0:00 [testgtk <defunct>]

It looks like your child process is dying immediately after
execve()ing it. In such situations, I often do change the roles
child&parent. In C there is some code that looks like:

	if ((pid=fork()<0))
	  ErrorHandling();
	if (pid==0)
	  Child();
	else
	  Parent();	

When I change the pid==0 to pid!=0, the parent code is executing in
child context. Not I can start the program using my favourite debugger
and see, where the child is dying.

Since your child process is a separate programm, you could try to
start is manually on the command line. It probably will fail, too. If
not, you probably pass a changed environment to if (different
enviroment variables, different descriptors open, ...).

73, Mario
-- 
Mario Klebsch						mario@klebsch.de




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: fork; execve --> defunct process.
  2000-01-18  0:00   ` Bobby D. Bryant
@ 2000-01-19  0:00     ` Mats Weber
  2000-01-21  0:00     ` Robert A Duff
  1 sibling, 0 replies; 8+ messages in thread
From: Mats Weber @ 2000-01-19  0:00 UTC (permalink / raw)


"Bobby D. Bryant" wrote:

> > execve never returns if it succeeds.
> 
> That's fine.

See below.

> The child process is created, execve returns a non-negative status, and the
> child process picks up the name of the requested program, but it apparently
> cores out before it actually does anything.

execve does not return if the call is successful. I don't see what you
mean here, and there is a contradication with what you are saying
earlier in your message.

> Has anyone here used execve from Ada?  Is there a special trick required to
> get it to work?  Does the child process get into a confused state when execve
> tries to have it jump out of the middle of a running Ada program?  I.e., are
> there leftover structures from Ada's run-time checking and/or task management
> system that are not cleanly erased when execve is called?  (I'm not
> explicitly using tasks, but I assume the run-time infrastructure is there
> anyway.)

fork/execve is fine from an Ada program, even with tasks. I have done
that for years without major problems. Post the code fragment, I cannot
guess more from your message.




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: fork; execve --> defunct process.
  2000-01-18  0:00   ` Bobby D. Bryant
  2000-01-19  0:00     ` Mats Weber
@ 2000-01-21  0:00     ` Robert A Duff
  2000-01-22  0:00       ` Bobby D. Bryant
  1 sibling, 1 reply; 8+ messages in thread
From: Robert A Duff @ 2000-01-21  0:00 UTC (permalink / raw)


"Bobby D. Bryant" <bdbryant@mail.utexas.edu> writes:

> Has anyone here used execve from Ada?
>...

You might find it useful to look at the Spawn_Internal procedure in
GNAT.OS_Lib, and the stuff it calls -- eg the portable_spawn function
in a-adaint.c.

- Bob




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: fork; execve --> defunct process.
  2000-01-21  0:00     ` Robert A Duff
@ 2000-01-22  0:00       ` Bobby D. Bryant
  0 siblings, 0 replies; 8+ messages in thread
From: Bobby D. Bryant @ 2000-01-22  0:00 UTC (permalink / raw)


Robert A Duff wrote:

> You might find it useful to look at the Spawn_Internal procedure in
> GNAT.OS_Lib, and the stuff it calls -- eg the portable_spawn function
> in a-adaint.c.

Ah, just what I needed!  Thanks.

And thanks to the others who responded as well.  Mario's trick helped me
past one hurdle, but I was still getting various problems when I tried
to launch anything with a GUI, so I backed up and tried OS_Lib, and it
has worked on the first try for everything I've tried to launch so far.
(And there are some other goodies in OS_Lib that I need to know about,
too.)

Bobby Bryant
Austin, Texas






^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2000-01-22  0:00 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-01-18  0:00 fork; execve --> defunct process Bobby D. Bryant
2000-01-18  0:00 ` Mats Weber
2000-01-18  0:00   ` Bobby D. Bryant
2000-01-19  0:00     ` Mats Weber
2000-01-21  0:00     ` Robert A Duff
2000-01-22  0:00       ` Bobby D. Bryant
2000-01-18  0:00 ` Mats Weber
2000-01-19  0:00 ` Mario Klebsch

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox