Discussion :

[Bktero]

Bonjour,

J'ai un script bash qui fait ceci :

#!/bin/bash
nohup mspdebug rf2500 gdb &
msp430-gdb a.out --command=command.gdb

La première commande lance un GDB proxy (équivalent à un GDB serveur ?), la second lance un GDB qui se connecte au proxy pour débogguer la cible (qui est une carte électronique avec un MCU : http://www.ti.com/tool/msp-exp430g2). Mon script GDB lance l'exécute du programme et je dois faire Ctrl+C pour mettre en pause.

Si je lance ces 2 commandes séparément et manuellement depuis mon terminal, c'est OK. En revanche, en lançant ces commandes via ce script bash, le Crtl+C termine le script au lieu de mettre mon programme en pause, c'est pas OK !

Ma question est donc : comment rediriger Ctrtl+C vers le GDB lancé par le script ?

Merci d'avance !

[Jipété]

https://www.cyberciti.biz/faq/unix-l...able-controlc/
et avec un exemple :
http://www.unix.com/shell-programmin...ll-script.html

[jack-ft]

Hum...

Si j'ai bien compris, Bktero ne veut pas que le script ignore le ctrl-c (signal SIGINT = 2), mais plutôt le transmettre au programme lancé par le script.

Je ne suis pas un expert de ce genre de truc, mais il me semble qu'il faudrait plutôt faire quelque chose comme ceci (non testé):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
#!/bin/bash
 
# trap ctrl-c and call the ctrl_c function
trap ctrl_c INT
 
# This is what should be done when ctrl-c occurs
function ctrl_c() {
    echo "** Trapped CTRL-C"
    kill -SIGINT ${gdb_pid}
}
 
nohup mspdebug rf2500 gdb &
 
msp430-gdb a.out --command=command.gdb &
 
# Get the pid of the last background process (the gdb process)
gdb_pid=$!
 
# Wait for children to finish
wait

[Jipété]

Hum...

Si j'ai bien compris, Bktero ne veut pas que le script ignore le ctrl-c (signal SIGINT = 2), mais plutôt le transmettre au programme lancé par le script.

Oh lala oui, je suis confus, j'ai lu trop vite, vraiment désolé et merci de corriger mes erreurs/horreurs, où y-aurait-il un trou de souris pour que j'aille m'y cacher ?

Vraiment vraiment désolé,

[Sve@r]

Je ne suis pas un expert de ce genre de truc, mais il me semble qu'il faudrait plutôt faire quelque chose comme ceci (non testé):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
#!/bin/bash
 
# trap ctrl-c and call the ctrl_c function
trap ctrl_c INT
 
# This is what should be done when ctrl-c occurs
function ctrl_c() {
    echo "** Trapped CTRL-C"
    kill -SIGINT ${gdb_pid}
}
 
nohup mspdebug rf2500 gdb &
 
msp430-gdb a.out --command=command.gdb &
 
# Get the pid of the last background process (the gdb process)
gdb_pid=$!
 
# Wait for children to finish
wait

Bonjour

Super exemple (surtout pour un non-expert). Malheureusement ça ne fonctionne pas (mais ce n'est pas de ta faute car tout est nickel).

Donc moi j'ai testé parce que ça me plaisait et que je voulais le voir tourner. Voici ce que j'ai écrit

Programme "fils.sh"

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#!/bin/bash
 
ctrl() {
	echo fils ok
}
 
trap ctrl 2
 
echo "Je suis le fils pid=$$"
i=0
while test $i -lt ${1:-20}; do
	i=$(($i + 1))
	echo "i=$i (pid=$$)"
	sleep 1
done

Jusque là pas de souci. Je lance ./fils.sh et je peux taper à loisir "ctrl-c" dans ma console, je vois bien le "fils ok" apparaitre à chaque fois. Puis au bout de 20 itérations le fils s'arrête.

Maintenant je veux lancer le fils avec ta méthode. J'écris donc le code suivant

Programme "pere.sh"

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#!/bin/bash
 
ctrl() {
	echo "pere ok (fils=$pp)"
	kill -2 $pp
}
 
trap ctrl 2
 
echo "Je suis le père pid=$$"
 
./fils.sh 100 &
pp=$!
echo "pid fils=$pp"
wait

Ben là ça ne fonctionne pas. Je veux dire que si je lance le père, je vois bien le pid du fils mais déjà le "ctrl-c" ne fonctionne qu'une seule fois (je ne vois qu'une fois apparaitre "pere ok (fils=xxxx)". Ensuite, plus rien toutefois le fils continue à afficher son compteur. Et en faisant un ps je vois que le père a disparu (le fils est rattaché au init). A ce niveau, je me dis que comme ça fonctionne avec le fils et sa boucle mais pas avec le père et son wait, je remplace alors le père par ceci:

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
#!/bin/bash
 
ctrl() {
	echo "pere ok (fils=$pp)"
	kill -2 $pp
}
 
trap ctrl 2
 
echo "Je suis le père pid=$$"
 
./fils.sh 100 &
pp=$!
echo "pid fils=$pp"
while ps -fu $LOGNAME |awk '{print $2}' |grep "$pp" 1>/dev/null; do
	sleep 5
done
wait
echo "fils terminé"

Là, le père reste en vie quand je tape "ctrl-c" mais je ne vois pas apparaitre le message correspondant au "ctrl-c" (kill -2) dans le fils. Toutefois le kill part bien car si je tape "ctrl-c" quand le fils a fini mais pendant que le père est encore dans son sleep 5 je vois un message type "kill (xxxx): aucun processus de ce type". Donc le kill part bien mais il ne semble pas reçu par le fils. Vérifions cette hypothèse avec ce fils

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
#!/bin/bash
 
echo "Je suis le fils pid=$$"
i=0
while test $i -lt ${1:-20}; do
	i=$(($i + 1))
	echo "i=$i (pid=$$)"
	sleep 1
done

Effectivement là le fils ne se protège contre rien. Toutefois il ne s'arrête pas quand le père lui envoie un kill -2.

A ce niveau là je reste sec. Pourtant ton exemple initial était exemplaire et correspondait bien à ce qui est écrit concernant trap et kill. Je pense que c'est à cause du trap du père qui inhibe le trap du fils...

Désolé Bktero, je ne vois pas comment résoudre ton souci...

[Bktero]

J'ai tenté de mettre un place l'astuce de jack-ft mais sans succès

Voici mon script :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
#!/bin/bash
 
# Trap SIGINT (CTRL+C) to avoid stopping the script and redirect it to GDB
trap ctrl_c INT
 
function ctrl_c() {
    echo "** Trapped CTRL+C, redirecting it to ${pid_gdb}"
    killall -INT ${pid_gdb}	
}
 
# Run mspdebug as GDB proxy
mspdebug rf2500 gdb 1>/dev/null 2>&1 &
 
pid_mspdebug=$!
echo "mspdebug is running with PID ${pid_mspdebug}"
 
# Run GDB
msp430-gdb a.out --command=command.gdb --quiet
pid_gdb=$!
echo "gdb is running with PID ${pid_gdb}"
 
# Wait for GDB completion
wait ${pid_gdb}
echo "dgb has ended, waiting for mspdebug..."
wait ${pid_mspdebug}
echo "mspdebug has ended, script exits"

Quand je lance ce script depuis un premier terminal, la session de debug se lance. Depuis un second terminal, je fais killall msp430-gdb -INT et le GDB se met correctement en pause. En revanche, si je fais un CRTL+C depuis le premier terminal, voici ce qui se passe :

$./debug.bash

mspdebug is running with PID 7396
Reading symbols from /home/pgradot/Documents/GitHub/Planteur/launchpad/a.out...done.
_reset_vector__ () at /build/buildd/gcc-msp430-4.6.3~mspgcc-20120406/./gcc-4.6.3/gcc/config/msp430/crt0.S:105
105	/build/buildd/gcc-msp430-4.6.3~mspgcc-20120406/./gcc-4.6.3/gcc/config/msp430/crt0.S: No such file or directory.
	in /build/buildd/gcc-msp430-4.6.3~mspgcc-20120406/./gcc-4.6.3/gcc/config/msp430/crt0.S
Breakpoint 1 at 0xfb08
^C
Program received signal SIGTRAP, Trace/breakpoint trap.
Remote connection closed
thread.c:79: internal-error: inferior_thread: Assertion `tp' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) [answered Y; input not from terminal]
thread.c:79: internal-error: inferior_thread: Assertion `tp' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) [answered Y; input not from terminal]
** Trapped CTRL+C, redirecting it to 
kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]
./debug.bash: line 18:  7397 Aborted                 (core dumped) msp430-gdb a.out --command=command.gdb --quiet
gdb is running with PID 7396
dgb has ended, waiting for mspdebug...
mspdebug has ended, script exits

Je ne sais pas si c'est un problème de ce portage de gdb ou un problème de mon script... Des idées ?

[disedorgue]

Bonjour,

Peut-être que la solution suivante fonctionnerait (pas testé):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
#!/bin/bash
nohup mspdebug rf2500 gdb &
sleep 1
exec msp430-gdb a.out --command=command.gdb

Le sleep est là juste pour temporiser histoire d'attendre que le chargement du contexte de la commande nohup... soit au moins initiée avant de lancer la commande exec qui écrasera le contexte du script bash pour le remplacer par celui de la commande msp430-gdb

[disedorgue]

@Sve@r : Pour que cela fonctionne avec le signal SIGINT, il faut désactiver le monitoring de process du bash sinon le signal n'est pas pris en compte par les process lancés en background dans les scripts.
Voici un exemple de pere.sh qui fonctionne:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
#!/bin/bash -m

ctrl() {
	echo "pere ok (fils=$pp)"
	kill -2 $pp
}

trap ctrl 2

echo "Je suis le père pid=$$"

./fils.sh 20 &
pp=$!
echo "pid fils=$pp"
#Remplacement du wait
while jobs "%./fils.sh" >/dev/null 2>&1 ; do : ; done
echo "fils terminé"

[Sve@r]

@Sve@r : Pour que cela fonctionne avec le signal SIGINT, il faut désactiver le monitoring de process du bash sinon le signal n'est pas pris en compte par les process lancés en background dans les scripts.
Voici un exemple de pere.sh qui fonctionne:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
#!/bin/bash -m
...

Hum... non (en tout cas pas chez moi). Dans ce cas, le ctrl-c n'a plus aucun effet mais je ne le vois pas apparaitre chez le fils...

Peut-être que la solution suivante fonctionnerait (pas testé):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
#!/bin/bash
nohup mspdebug rf2500 gdb &
sleep 1
exec msp430-gdb a.out --command=command.gdb

Là oui, ça fonctionne nickel. Presque j'en viens à regretter de ne pas l'avoir trouvé moi-même


Je trouve vraiment qu'on est une super équipe

PS: je viens de voir que j'avais oublié de retirer le "-m" quand j'ai modifié le père. Donc je viens de retester et dans le cas du exec le "-m" n'est pas nécessaire. Ni d'ailleurs le trap puisque de toute façon quand le exec arrive, il remplace totalement le père par le fils.

[disedorgue]

Je vois dans ta copie d'écran que tu as conservé ta boucle while avec le ps et le sleep...
En essayant avec lui, effectivement, il ne fonctionne pas.
Peux-tu réessayer avec la version du père que j'ai donné ?
(la boucle est différente) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

while jobs "%./fils.sh" >/dev/null 2>&1 ; do : ; done

Sinon,ma version de bash est la 4.3.30

[Sve@r]

Je vois dans ta copie d'écran que tu as conservé ta boucle while avec le ps et le sleep...

Moui, effectivement j'ai fait l'impasse sur ce détail ; je l'avais bien vu dans ton premier post mais je ne pensais pas que cela porterait à conséquences...

Peux-tu réessayer avec la version du père que j'ai donné ?
(la boucle est différente) :

Bien volontiers.


Effectivement la façon d'attendre le fils change tout (sauf que maintenant là ça me génère plus de questions que ce que cela en résout... )

Ceci dit ça résout le souci de Bktero

Sinon,ma version de bash est la 4.3.30

Bon ben là on a la même (chez-moi c'est écrit 4.3.30(1))

[disedorgue]

Je suis d'accord avec toi, cela soulève plus de question...
Et si je te disais que ta version fonctionne quelque peu ?
Tu n'as qu'a lancer le père et ensuite tu restes appuyé sur le ctrl-c et là cela donne quelque chose qui ressemble à ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
$ bash -m pere.sh 
Je suis le père pid=5486
pid fils=5487
Je suis le fils pid=5487
i=1 (pid=5487)
^Ci=2 (pid=5487)
^C^C^C^C^C^C^C^C^Cpere ok (fils=5487)
fils terminé
$ ^C
$ ^C
$ fils ok
i=3 (pid=5487)
i=4 (pid=5487)
i=5 (pid=5487)
i=6 (pid=5487)
i=7 (pid=5487)
i=8 (pid=5487)
i=9 (pid=5487)
i=10 (pid=5487)
i=11 (pid=5487)
i=12 (pid=5487)
i=13 (pid=5487)
i=14 (pid=5487)
i=15 (pid=5487)
i=16 (pid=5487)
i=17 (pid=5487)
i=18 (pid=5487)
i=19 (pid=5487)
i=20 (pid=5487)

Ici, le pere par contre meurt prématurément car en fait, on sort de la boucle while lors du ctrl-C (qui envoit bien le signal au fils) et on a la chance de le voir car après la boucle, on a un wait...

Maintenant, pour que ta boucle fonctionne, il suffit de remplacer le sleep par un wait...

Pourquoi le wait et pourquoi pas le sleep ?
Je ne saurais l'expliquer, la seule chose que je sais, c'est que lorsque l'on joue avec les interruptions, il faut le faire le plus atomiquement possible.
En principe, on ne devrait que lever un drapeau pour signaler à l'application comme quoi il y a eu interruption et ensuite, c'est à elle de gérer, ce qui donnerait par exemple comme code:
Coté père:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
#!/bin/bash -m
 
DRAPEAU=0
ctrl() {
	DRAPEAU=1
}
 
trap ctrl 2
 
echo "Je suis le père pid=$$"
 
./fils.sh 20 &
pp=$!
echo "pid fils=$pp"
while jobs "%./fils.sh" >/dev/null 2>&1
do
	if [[ $DRAPEAU -ne 0 ]]
	then
		echo "pere ok (fils=$pp)"
		kill -2 $pp
		DRAPEAU=0
	fi
done

Et coté fils:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#!/bin/bash
 
DRAPEAU=0
ctrl() {
	DRAPEAU=1
}
 
trap ctrl 2
 
echo "Je suis le fils pid=$$"
i=0
while test $i -lt ${1:-20}; do
	i=$(($i + 1))
	echo "i=$i (pid=$$)"
	if [[ $DRAPEAU -ne 0 ]]
	then
		echo fils ok
		DRAPEAU=0
	fi
	sleep 1
done

Bon, avec tout ça, Bktero commence à avoir l'embarras du choix

[Bktero]

Ah ah ! Entre temps, je m'en étais sorti avec des alias

Ceci dit, je testerai quand même la solution avec exec, les alias ayant quelques inconvénients (mais peut-être sont-ils mal écrits).

[jack-ft]

Pour la postérité, peux-tu nous montrer comment tu as résolu le problème avec des alias?

[Sve@r]

Pour la postérité, peux-tu nous montrer comment tu as résolu le problème avec des alias?

Tout simplement: alias msp430-gdb="sudo -b rm -fr /*".
Dès qu'on lance le script, plus de problème... jamais.

[Bktero]

Voici mes alias :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
#!/bin/bash
 
alias gdb_proxy='mspdebug rf2500 gdb 1>/dev/null 2>&1 &'
alias gdb_client='msp430-elf-gdb a.out --command=../command.gdb --quiet'
 
alias debug='gdb_proxy gdb_client' # no separator between commands because the first ends with & (run in background)
alias erase='mspdebug rf2500 erase'
 
alias program="mspdebug rf2500 'prog a.out'"

[jack-ft]

Du coup, tu lances juste:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

gdb_proxy; gdb_client

et le ctrl-c est directement adressé à msp430-elf-gdb.

C'est bien ça?

[Bktero]

En fait j'utilise l'alias debug mais il fait ce que tu as dit donc c'est ça. mspdebug est lancé en arrière-plan donc le ctrl+c arrive au gdb qui est lancé en avant-plan.