Newsgroup: it.comp.lang.c
Titolo: gdb & fork

salve a tutti,
ho un piccolo problema: sto sviluppando un'applicazione multiprocesso,
in pratica un programma che a un certo momento forka. se lo eseguo sotto
gdb il child diventa subito zombie, mentre se eseguito da shell no.
è possibile debuggare programmi che usano fork sotto gdb? ciò che vorrei
è che gdb continui a eseguire il padre, e che il figlio parta e prosegua
per conto proprio.
dimenticavo che sto sviluppando sotto linux (kernel 2.2 con egcs112 o
gcc2.95.2 e gdb 4.17.0.11).
grazie per l'attenzione, Simone

 gdb il child diventa subito zombie
mmm... se il processo figlio diventa zombie e' perche' termina e il
padre non ne cattura lo stato d'uscita con una wait(). Bisognerebbe
vedere il codice.
--
 Ciao, Bianco.
 Reply to 
luca....@tiscalinet.it

 vedere il codice.
e te lo faccio vedere molto volentieri:
----ESEMPIO
#include <sys/types.h>
#include <sys/wait.h>
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
main ()
{
	int c, status, options;
	switch (c = fork())
	{
	case 0:
		printf("child %d\n",getpid());
		sleep(5);
		exit(0);
	default:
		printf("father %d created %d. WAITING...\n",getpid(),c);
		c = waitpid(c,&status,0);
		printf("c=%d exited:%d
exit:%d\n",c,WIFEXITED(status),WEXITSTATUS(status)); 
	}
}
-----FINE ESEMPIO
se lo esegui sotto gdb passo passo, immediatamente dopo aver eseguito la
fork() ps riporta che il child è già zombie (prima dei 5 secs dello
sleep e comunque non viene stampato niente). mentre se lo esegui da
shell tutto funge come dovrebbe.
tra l'altro ho scoperto anche che gdb si pianta su kill(). nel senso che
se esegui passo passo appena arriva alla kill il processo si pianta
lì...


Per come la vedo io ( dagli occhi di uno un po alle prime armi)
il problema e' nello sleep 5 e nella pritf prima di wait.
Se lo esegui da shell di norma 5 sec. sono sufficienti per eseguire la
chiamata di sistema nella printf e quindi poi i, babbo puo' eseguire la wait
per il figlio; viceversa da gdb il tutto viene falsato.
Credo che questo sia un esempio di processi concorrenti no?
Vi][oZ
-- 
          We are the true believers
       It's our turn to show the world
 In the fire of heavy metal we were burned
         It's more than our religion
          It's the only way to live
           But the enemies of metal
              We can't forgive

 
Dunque, non ho molta pratica con gdb, adesso porto tutto nel regno del
piguino (dopo il reboot, intendo), provo il provabile e faccio sapere
il risultato appena ho tempo.


 per il figlio; viceversa da gdb il tutto viene falsato.
Vuoi dire che quei 5 secondi non bastano per poter eseguire la wait
sotto gdb? Mi sembra un po' strano, vabbe' che non bisogna mai fare
affidamento sui tempi di risposta, ma 5 sec. quando non ci sono
centinaia di processi attivi mi sembra un tempo in cui il nostro
processo sara' molto, molto probabilmente schedulato.
-- 
 Ciao, Bianco.
 Reply to luca.bianco (at) 
tiscalinet.it

#include <sys/types.h>
#include <sys/wait.h>
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
int main (void)
{
	int c, status;
	switch (c = fork())
	{
	case 0:
		printf("child %d\n",getpid());
		sleep(5);
		exit(0);
	default:
		printf("father %d created %d. WAITING...\n",getpid(),c);
		c = waitpid(c,&status,0);
		printf("c=%d exited:%d
exit:%d\n",c,WIFEXITED(status),WEXITSTATUS(status)); 
	}
 
	return 0;
}
Dunque, questo e' il codice che ho provato, compilato senza warning e
il risultato e' stato che tutto ha funzionato a dovere, niente zombie
o mostri di sorta ;-)
Il tutto provato su RedHat 6.2, kernel 2.2.16, egcs-2.91.66.
Non so che altro provare...


 shell tutto funge come dovrebbe.
Forse la spiegazione sta qui:
[root@fokhouse /root]# info gdb 'Runn' 'Pro' 2>/dev/null| grep -1 'SIG'
child process will run unimpeded.  If you have set a breakpoint in any
code which the child then executes, the child will get a `SIGTRAP'
signal which (unless it catches the signal) will cause it to terminate.
[root@fokhouse /root]#
Controlla il valore di 'exited' quando lo fai girare sotto gdb passo
passo.
Ciao ciao,
Andrea
-- 
"...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and 
 the Ugly)."
(by Matt Welsh)