Memory problem on a software

[Olivier Cruilles]

Hello,

I don't know if I must write this Email in english or in french.
I try in french because it's more easy for me but if it's necessary I
can translate it in english. Thank you in advance for your answer.

----------------------------

Je suis actuellement en train de développer un petit logiciel Gambas en
mode console uniquement (pas de graphique) dont le but est d'exécuter
des requêtes Snmp vers des divers équipements réseau.

Description du fonctionnement logiciel:

1 - Lire le fichier de configuration des requêtes a effectuer

  Ex:
# TYPE:HOSTNAME:VERSIONSNMP:COMMUNAUTE:RRD_DB:TIMER:OIDs LIST
        #

SNMP:10.34.2.205:2c:public:/data/RRD_files/frocr05_10.34.2.205-Linux-Linux_Ethernet.rrd:60:ifInOctets.2#ifOutOctets.2#ifInErrors.2#ifOutErrors.2

SNMP:10.34.2.205:2c:public:/data/RRD_files/frocr05_10.34.2.205-Linux-Linux_Cpu.rrd:300:ssCpuUser.0#ssCpuSystem.0#ssCpuIdle.0
        #

SNMP:10.35.75.11:2c:gpcisco:/data/RRD_files/10.35.75.11-1-cisco_router_cpu-Cpu-1.rrd:300:1.3.6.1.4.1.9.2.1.58.0

SNMP:10.35.75.11:2c:gpcisco:/data/RRD_files/10.35.75.11-6-cisco_router_memory-Memory-2.rrd:300:1.3.6.1.4.1.9.9.48.1.1.1.5.1#1.3.6.1.4.1.9.9.48.1.1.1.6.1

SNMP:10.35.75.11:2c:gpcisco:/data/RRD_files/10.35.75.11-15-cisco_router_network_ethernet-FastEthernet0-1-3.rrd:150:ifInOctets.2#ifOutOctets.2#ifInErrors.2#ifOutErrors.2

SNMP:10.35.75.11:2c:gpcisco:/data/RRD_files/10.35.75.11-32-cisco_router_network_ethernet-Vlan1-4.rrd:150:ifInOctets.8#ifOutOctets.8#ifInErrors.8#ifOutQLen.8

SNMP:10.35.75.11:2c:gpcisco:/data/RRD_files/10.35.75.11-49-cisco_router_network_ethernet-Tunnel3-5.rrd:150:ifInOctets.9#ifOutOctets.9#ifInErrors.9#ifOutErrors.9

SNMP:10.35.75.11:2c:gpcisco:/data/RRD_files/10.35.75.11-66-cisco_router_network_ethernet-Vlan666-6.rrd:150:ifInOctets.10#ifOutOctets.10#ifInErrors.10#ifOutErrors.10

SNMP:10.35.75.11:2c:gpcisco:/data/RRD_files/10.35.75.11-83-cisco_router_network_ethernet-Vlan888-7.rrd:150:ifInOctets.11#ifOutOctets.11#ifInErrors.11#ifOutErrors.11
       
        2 - Détermination des différents Timer a définir:

   Ici, si on analyse le champ TIMER de chaque ligne, on peux mettre en
évidence 3 Timer différents:
       
        60 secondes
        150 secondes
        300 secondes

3 - Lancement d'autant de Classe CTask qu'il y a de Timer différents
                                                 (ici 3 timers)


Description de la Classe CTask

Afin de pouvoir exécuter chaque requête SNMP à intervalle régulier, la
Classe CTask lance en sous process la Classe CTimer.

La classe CTimer remonte régulièrement un évènement indiquant qu'il est
temps d'exécuter les requêtes SNMP.

L'exécution des requêtes SNMP est alors effectué par la Classe CTask en
lançant autant des Classes CSnmp qu'il y a
de lignes de configuration définies dans le fichier de configuration
pour un Timer donné.

La Classe CSnmp se charge de lancer a sont tour une commande en SHELL
pour effectuer le requête SNMP

      Ex: snmpget -v 2c -c gpcisco 10.35.75.11
ifInOctets.11#ifOutOctets.11#ifInErrors.11#ifOutErrors.11

    Les informations en retour de cette commande sont alors récupérés
pour être tracé dans un fichier de logs.


Problème rencontré:


    Il apparaît que ce petit logiciel ai des fuite de mémoire, en effet,
au fur et a mesure que les Process SNMP sont lancé,
les objets associés a ces Process de soit jamais libérés.

Je fais appel a vous dans l'espoir que quelqu'un pourra m'indiquer ou se
situe mon erreur de programmation ou mon erreur
d'approche de l'utilisation de l'Orienté Object en Gambas.

Ci-joint dans cet Email les sources du logiciel en Gambas 1.0... et
Gambas 2.5...

Nota:
   
    a) Pour utiliser le logiciel, après avoir décompacter les sources,
il vous faudra renseigner le fichier 'gbUpdated.ini'

    b) Afin de mettre en évidence plus rapidement le problème de fuite
de mémoire, j'ai diminuer la valeur des Timers dans les
        Classe CTask comme suit

        PRIVATE SUB setDelay_Write(delay AS Integer)
            $Delay = delay * 350    '  Cette valeur doit être
normalement égale a  1000
            iCtimer.setDelay = $Delay
        END


    c) Pour visualiser les résultats des requêtes SNMP, il suffit
d'executer dans un terminal la commande suivante:

        tail -f CHEMIN_SOURCE_LOGICIEL/gbUpdated.log


Merci beaucoup d'avance car après beaucoup d'heure de travail, j'arrive
dans une impasse.

--
Olivier CRUILLES
Email: linuxos@...

      * hypoaristerolactotherapie : methode de depannage des machines
        par le coup de pied en bas a gauche.
      * Mais si, Linux est user-friendly. Mais Linux il choisit ses
        amis, lui !
      * Software is like sex, it's better when it's free (Linus Torvalds)



-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Gambas-user-fr mailing list
Gambas-user-fr@...
https://lists.sourceforge.net/lists/listinfo/gambas-user-fr

[Benoit Minisini]

On jeudi 24 avril 2008, linus wrote:
> Hello,
>
> I don't know if I must write this Email in english or in french.
> I try in french because it's more easy for me but if it's necessary I
> can translate it in english. Thank you in advance for your answer.
>
> ----------------------------

C'est une mailing-list en français, alors je pense que le français s'impose,
non ?

>
> Je suis actuellement en train de développer un petit logiciel Gambas en
> mode console uniquement (pas de graphique) dont le but est d'exécuter
> des requêtes Snmp vers des divers équipements réseau.
>
> Description du fonctionnement logiciel:
>
> 1 - Lire le fichier de configuration des requêtes a effectuer
>
>   Ex:
> # TYPE:HOSTNAME:VERSIONSNMP:COMMUNAUTE:RRD_DB:TIMER:OIDs LIST
>         #
>
> SNMP:10.34.2.205:2c:public:/data/RRD_files/frocr05_10.34.2.205-Linux-Linux_
>Ethernet.rrd:60:ifInOctets.2#ifOutOctets.2#ifInErrors.2#ifOutErrors.2
>
> SNMP:10.34.2.205:2c:public:/data/RRD_files/frocr05_10.34.2.205-Linux-Linux_
>Cpu.rrd:300:ssCpuUser.0#ssCpuSystem.0#ssCpuIdle.0 #
>
> SNMP:10.35.75.11:2c:gpcisco:/data/RRD_files/10.35.75.11-1-cisco_router_cpu-
>Cpu-1.rrd:300:1.3.6.1.4.1.9.2.1.58.0
>
> SNMP:10.35.75.11:2c:gpcisco:/data/RRD_files/10.35.75.11-6-cisco_router_memo
>ry-Memory-2.rrd:300:1.3.6.1.4.1.9.9.48.1.1.1.5.1#1.3.6.1.4.1.9.9.48.1.1.1.6.
>1
>
> SNMP:10.35.75.11:2c:gpcisco:/data/RRD_files/10.35.75.11-15-cisco_router_net
>work_ethernet-FastEthernet0-1-3.rrd:150:ifInOctets.2#ifOutOctets.2#ifInError
>s.2#ifOutErrors.2
>
> SNMP:10.35.75.11:2c:gpcisco:/data/RRD_files/10.35.75.11-32-cisco_router_net
>work_ethernet-Vlan1-4.rrd:150:ifInOctets.8#ifOutOctets.8#ifInErrors.8#ifOutQ
>Len.8
>
> SNMP:10.35.75.11:2c:gpcisco:/data/RRD_files/10.35.75.11-49-cisco_router_net
>work_ethernet-Tunnel3-5.rrd:150:ifInOctets.9#ifOutOctets.9#ifInErrors.9#ifOu
>tErrors.9
>
> SNMP:10.35.75.11:2c:gpcisco:/data/RRD_files/10.35.75.11-66-cisco_router_net
>work_ethernet-Vlan666-6.rrd:150:ifInOctets.10#ifOutOctets.10#ifInErrors.10#i
>fOutErrors.10
>
> SNMP:10.35.75.11:2c:gpcisco:/data/RRD_files/10.35.75.11-83-cisco_router_net
>work_ethernet-Vlan888-7.rrd:150:ifInOctets.11#ifOutOctets.11#ifInErrors.11#i
>fOutErrors.11
>
>         2 - Détermination des différents Timer a définir:
>
>    Ici, si on analyse le champ TIMER de chaque ligne, on peux mettre en
> évidence 3 Timer différents:
>
> 60 secondes
> 150 secondes
> 300 secondes
>
> 3 - Lancement d'autant de Classe CTask qu'il y a de Timer différents
> (ici 3 timers)
>
>
> Description de la Classe CTask
>
> Afin de pouvoir exécuter chaque requête SNMP à intervalle régulier, la
> Classe CTask lance en sous process la Classe CTimer.
>
> La classe CTimer remonte régulièrement un évènement indiquant qu'il est
> temps d'exécuter les requêtes SNMP.
>
> L'exécution des requêtes SNMP est alors effectué par la Classe CTask en
> lançant autant des Classes CSnmp qu'il y a
> de lignes de configuration définies dans le fichier de configuration
> pour un Timer donné.
>
> La Classe CSnmp se charge de lancer a sont tour une commande en SHELL
> pour effectuer le requête SNMP
>
>       Ex: snmpget -v 2c -c gpcisco 10.35.75.11
> ifInOctets.11#ifOutOctets.11#ifInErrors.11#ifOutErrors.11
>
>     Les informations en retour de cette commande sont alors récupérés
> pour être tracé dans un fichier de logs.
>
>
> Problème rencontré:
>
>
>     Il apparaît que ce petit logiciel ai des fuite de mémoire, en effet,
> au fur et a mesure que les Process SNMP sont lancé,
> les objets associés a ces Process de soit jamais libérés.
>
> Je fais appel a vous dans l'espoir que quelqu'un pourra m'indiquer ou se
> situe mon erreur de programmation ou mon erreur
> d'approche de l'utilisation de l'Orienté Object en Gambas.
>
> Ci-joint dans cet Email les sources du logiciel en Gambas 1.0... et
> Gambas 2.5...
>
> Nota:
>
>     a) Pour utiliser le logiciel, après avoir décompacter les sources,
> il vous faudra renseigner le fichier 'gbUpdated.ini'
>
>     b) Afin de mettre en évidence plus rapidement le problème de fuite
> de mémoire, j'ai diminuer la valeur des Timers dans les
>         Classe CTask comme suit
>
>         PRIVATE SUB setDelay_Write(delay AS Integer)
>             $Delay = delay * 350    '  Cette valeur doit être
> normalement égale a  1000
>             iCtimer.setDelay = $Delay
>         END
>
>
>     c) Pour visualiser les résultats des requêtes SNMP, il suffit
> d'executer dans un terminal la commande suivante:
>
>         tail -f CHEMIN_SOURCE_LOGICIEL/gbUpdated.log
>
>
> Merci beaucoup d'avance car après beaucoup d'heure de travail, j'arrive
> dans une impasse.

En regardant vite fait le code, j'ai vu de nombreuses bizarreries pour ne pas
dire pire.

Le code en lui-même a l'air bien compliqué pour faire ce que vous décrivez.

Je pense que les fuites de mémoires sont dues à la logique de votre programme
et pas à Gambas.

Je vous suggère déjà de nettoyer le code: indentation, renommage des variables
et des propriétés, utilisation de la syntaxe de Gambas 2...

Ensuite il faut afficher un message chaque fois que vous créez un objet et
qu'il est libéré (mais ça vous l'avez déjà fait) pour déterminer quels objets
ne sont pas libérés. Sans cette information, difficile de savoir ce qui se
passe !

Ce que je trouve étrange, c'est que, à priori, un objet CTask déclenche sa
série d'objets CSnmp en réponse au timer, sans vérifier que la série
précédente est bien terminée.

Quelques remarques sinon:

- Pourquoi la classe CTimer ? Pourquoi exécuter "usleep" en processus
externe ??? Les timers de Gambas sont normalement suffisamment précis, et
utilisent même une attente active lorsque leur résolution est inférieure à
10ms.

- Pourquoi "FOR IndexList = 0 TO (NbreLigne)" à la ligne 57 de CTask.class ?
Ce n'est pas "NbreLigne - 1" ?

- Split() renvoie un tableau de chaînes. Inutile d'initialiser la variable
recevant le résultat avec un autre tableau de chaînes vide.

- Inutile de faire LAST.Kill dans le gestionnaire de l'évènement Kill d'un
processus. Si ce gestionnaire se déclenche, c'est que le processus est déjà
terminé. Quant au "FLUSH #LAST", il ne sert à rien non plus, le processus est
mort.

- Ce n'est pas bien de tuer votre processus 'snpmget' dès l'instant où il
écrit sur la sortie erreur standard. Mais vous devez avoir vos raisons,
peut-être qu'il ne s'arrêterait pas tout seul autrement.

Cordialement,

--
Benoit Minisini

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Gambas-user-fr mailing list
Gambas-user-fr@...
https://lists.sourceforge.net/lists/listinfo/gambas-user-fr

[Olivier Cruilles]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Bonjour,

Un grand merci pour la vitesse de votre reponse.
En effet il ya surrement des bizarreries dans ce petit logiciel.

Tout d'abord, avant d'en arriver a cette version du logiciel, j'ai testé un grand nombre de solutions diverses et variées.

Au depart tout été déclaré en dynamique dans les classes  CTask, CTimer, CSnmp
mais j'arrivais pas a m'en sortir avec cette memoire qui "fuyé".
Je suis convaincu que ce n'est pas un probleme de fuite dans Gambas mais probablement une erreur de programmation.

J'ai écris la classe CTimer au depart car je ne l'ai pas trouvé en mode console dans la version 1.0.x de Gambas. Elle y est peut etre mais je ne l'ai pas trouvé.

Votre remarque est tres juste, dans la Classe CTask, je relance une nouvelle serie de requetes SNMP sans me preocuper de savoir si les precedantes sont terminées...
Effectivement c'est par ce que je ne sais pas comment le faire :)
J'ai tenté de stocker dans un tableau d'object les adresses  de chaque process Snmpget pour pouvoir le tester et les detruire par la suite mais la questions est:  Comment faire ça ???

Pour le moment, je suis obligé de continuer a developper en Gambas v1.0.x
car tout le reste de mon projet est ecrit dans cette version et ce n'est que plus tard que je migrerais tout en Gambas v2.x.
Il me tarde d'ailleurs car il y a beaucoup de nouvelles fonctions que je voudrais utiliser.

Merci d'avance pour votre reponse

Un grand bravo pour votre logiciel "Gambas", je suis vraiment fan.
J'ai lu que pour finir de tester Gambas sur MacOs, vous auriez besoin de vous connecter sur un Mac et faire des tests.
Il se trouve que j'ai un Macbook Intel Core 2 duo que je peux mettre sur le reseau pour que vous puissiez faire vos tests. Vous me direz si cela vous interresse ou pas.
De plus je souhaiterais contribuer au projet Gambas mais je ne sais  pas  de quelle maniere. ?

Olivier CRUILLES

----Message d'origine----

>De: Benoit Minisini
>A: mailing list for french gambas users
>Date: Thu, 24 Apr 2008 09:44:08 +0200
> See http://spamassassin.org/tag/ for more details.
> Report problems to
> http://sf.net/tracker/?func=add&group_id=1&atid=200001
>Sujet: Re: [Gambas-user-fr] Memory problem on a software
>
>
>
>
>On jeudi 24 avril 2008, linus wrote:
>> Hello,
>>
>> I don't know if I must write this Email in english or in french.
>> I try in french because it's more easy for me but if it's necessary I
>> can translate it in english. Thank you in advance for your answer.
>>
>> ----------------------------
>
>C'est une mailing-list en français, alors je pense que le français s'impose,
>non ?
>
>>
>> Je suis actuellement en train de développer un petit logiciel Gambas en
>> mode console uniquement (pas de graphique) dont le but est d'exécuter
>> des requêtes Snmp vers des divers équipements réseau.
>>
>> Description du fonctionnement logiciel:
>>
>> 1 - Lire le fichier de configuration des requêtes a effectuer
>>
>> Ex:
>> # TYPE:HOSTNAME:VERSIONSNMP:COMMUNAUTE:RRD_DB:TIMER:OIDs LIST
>> #
>>
>> SNMP:10.34.2.205:2c:public:/data/RRD_files/frocr05_10.34.2.205-Linux-Linux_
>>Ethernet.rrd:60:ifInOctets.2#ifOutOctets.2#ifInErrors.2#ifOutErrors.2
>>
>> SNMP:10.34.2.205:2c:public:/data/RRD_files/frocr05_10.34.2.205-Linux-Linux_
>>Cpu.rrd:300:ssCpuUser.0#ssCpuSystem.0#ssCpuIdle.0 #
>>
>> SNMP:10.35.75.11:2c:gpcisco:/data/RRD_files/10.35.75.11-1-cisco_router_cpu-
>>Cpu-1.rrd:300:1.3.6.1.4.1.9.2.1.58.0
>>
>> SNMP:10.35.75.11:2c:gpcisco:/data/RRD_files/10.35.75.11-6-cisco_router_memo
>>ry-Memory-2.rrd:300:1.3.6.1.4.1.9.9.48.1.1.1.5.1#1.3.6.1.4.1.9.9.48.1.1.1.6.
>>1
>>
>> SNMP:10.35.75.11:2c:gpcisco:/data/RRD_files/10.35.75.11-15-cisco_router_net
>>work_ethernet-FastEthernet0-1-3.rrd:150:ifInOctets.2#ifOutOctets.2#ifInError
>>s.2#ifOutErrors.2
>>
>> SNMP:10.35.75.11:2c:gpcisco:/data/RRD_files/10.35.75.11-32-cisco_router_net
>>work_ethernet-Vlan1-4.rrd:150:ifInOctets.8#ifOutOctets.8#ifInErrors.8#ifOutQ
>>Len.8
>>
>> SNMP:10.35.75.11:2c:gpcisco:/data/RRD_files/10.35.75.11-49-cisco_router_net
>>work_ethernet-Tunnel3-5.rrd:150:ifInOctets.9#ifOutOctets.9#ifInErrors.9#ifOu
>>tErrors.9
>>
>> SNMP:10.35.75.11:2c:gpcisco:/data/RRD_files/10.35.75.11-66-cisco_router_net
>>work_ethernet-Vlan666-6.rrd:150:ifInOctets.10#ifOutOctets.10#ifInErrors.10#i
>>fOutErrors.10
>>
>> SNMP:10.35.75.11:2c:gpcisco:/data/RRD_files/10.35.75.11-83-cisco_router_net
>>work_ethernet-Vlan888-7.rrd:150:ifInOctets.11#ifOutOctets.11#ifInErrors.11#i
>>fOutErrors.11
>>
>> 2 - Détermination des différents Timer a définir:
>>
>> Ici, si on analyse le champ TIMER de chaque ligne, on peux mettre en
>> évidence 3 Timer différents:
>>
>> 60 secondes
>> 150 secondes
>> 300 secondes
>>
>> 3 - Lancement d'autant de Classe CTask qu'il y a de Timer différents
>> (ici 3 timers)
>>
>>
>> Description de la Classe CTask
>>
>> Afin de pouvoir exécuter chaque requête SNMP à intervalle régulier, la
>> Classe CTask lance en sous process la Classe CTimer.
>>
>> La classe CTimer remonte régulièrement un évènement indiquant qu'il est
>> temps d'exécuter les requêtes SNMP.
>>
>> L'exécution des requêtes SNMP est alors effectué par la Classe CTask en
>> lançant autant des Classes CSnmp qu'il y a
>> de lignes de configuration définies dans le fichier de configuration
>> pour un Timer donné.
>>
>> La Classe CSnmp se charge de lancer a sont tour une commande en SHELL
>> pour effectuer le requête SNMP
>>
>> Ex: snmpget -v 2c -c gpcisco 10.35.75.11
>> ifInOctets.11#ifOutOctets.11#ifInErrors.11#ifOutErrors.11
>>
>> Les informations en retour de cette commande sont alors récupérés
>> pour être tracé dans un fichier de logs.
>>
>>
>> Problème rencontré:
>>
>>
>> Il apparaît que ce petit logiciel ai des fuite de mémoire, en effet,
>> au fur et a mesure que les Process SNMP sont lancé,
>> les objets associés a ces Process de soit jamais libérés.
>>
>> Je fais appel a vous dans l'espoir que quelqu'un pourra m'indiquer ou se
>> situe mon erreur de programmation ou mon erreur
>> d'approche de l'utilisation de l'Orienté Object en Gambas.
>>
>> Ci-joint dans cet Email les sources du logiciel en Gambas 1.0... et
>> Gambas 2.5...
>>
>> Nota:
>>
>> a) Pour utiliser le logiciel, après avoir décompacter les sources,
>> il vous faudra renseigner le fichier 'gbUpdated.ini'
>>
>> b) Afin de mettre en évidence plus rapidement le problème de fuite
>> de mémoire, j'ai diminuer la valeur des Timers dans les
>> Classe CTask comme suit
>>
>> PRIVATE SUB setDelay_Write(delay AS Integer)
>> $Delay = delay * 350 ' Cette valeur doit être
>> normalement égale a 1000
>> iCtimer.setDelay = $Delay
>> END
>>
>>
>> c) Pour visualiser les résultats des requêtes SNMP, il suffit
>> d'executer dans un terminal la commande suivante:
>>
>> tail -f CHEMIN_SOURCE_LOGICIEL/gbUpdated.log
>>
>>
>> Merci beaucoup d'avance car après beaucoup d'heure de travail, j'arrive
>> dans une impasse.
>
>En regardant vite fait le code, j'ai vu de nombreuses bizarreries pour ne pas
>dire pire.
>
>Le code en lui-même a l'air bien compliqué pour faire ce que vous décrivez.
>
>Je pense que les fuites de mémoires sont dues à la logique de votre programme
>et pas à Gambas.
>
>Je vous suggère déjà de nettoyer le code: indentation, renommage des variables
>et des propriétés, utilisation de la syntaxe de Gambas 2...
>
>Ensuite il faut afficher un message chaque fois que vous créez un objet et
>qu'il est libéré (mais ça vous l'avez déjà fait) pour déterminer quels objets
>ne sont pas libérés. Sans cette information, difficile de savoir ce qui se
>passe !
>
>Ce que je trouve étrange, c'est que, à priori, un objet CTask déclenche sa
>série d'objets CSnmp en réponse au timer, sans vérifier que la série
>précédente est bien terminée.
>
>Quelques remarques sinon:
>
>- Pourquoi la classe CTimer ? Pourquoi exécuter "usleep" en processus
>externe ??? Les timers de Gambas sont normalement suffisamment précis, et
>utilisent même une attente active lorsque leur résolution est inférieure à
>10ms.
>
>- Pourquoi "FOR IndexList = 0 TO (NbreLigne)" à la ligne 57 de CTask.class ?
>Ce n'est pas "NbreLigne - 1" ?
>
>- Split() renvoie un tableau de chaînes. Inutile d'initialiser la variable
>recevant le résultat avec un autre tableau de chaînes vide.
>
>- Inutile de faire LAST.Kill dans le gestionnaire de l'évènement Kill d'un
>processus. Si ce gestionnaire se déclenche, c'est que le processus est déjà
>terminé. Quant au "FLUSH #LAST", il ne sert à rien non plus, le processus est
>mort.
>
>- Ce n'est pas bien de tuer votre processus 'snpmget' dès l'instant où il
>écrit sur la sortie erreur standard. Mais vous devez avoir vos raisons,
>peut-être qu'il ne s'arrêterait pas tout seul autrement.
>
>Cordialement,
>
>--
>Benoit Minisini
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>Don't miss this year's exciting event. There's still time to save $100.
>Use priority code J8TL2D2.
>http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>_______________________________________________
>Gambas-user-fr mailing list
>Gambas-user-fr@...
>https://lists.sourceforge.net/lists/listinfo/gambas-user-fr
>

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Gambas-user-fr mailing list
Gambas-user-fr@...
https://lists.sourceforge.net/lists/listinfo/gambas-user-fr