Tonton Th wrote on 24/06/2015 06:03:On 2015-06-23, Rambo wrote:Ben, heu .... j'avais la source complète de l'OS propriétaire qui me
&Un jour en parcourant le code au moyen du dump mémoire, je tombe sur un
commentaire: "Si vous passez ici, donnez moi un dollar"
Donc tu as le source complet, mais il faut quand même faire
des dumps mémoire pour voir ce qu'il y a dedans ?
Tu n'as pas l'impression que c'est louche ?
le dump mémoire n'est pas fait pour voir ce qu'il y a dans le code, le
dump mémoire est fait pour fournir une image informatique de l'état de
la machine au moment du plantage de la machine.
Ce dump sert à déterminer la cause du crash.
Il ne sert à rien de se plonger dans le code pour savoir ce qui s'est
passé. On doit connaître la valeur de toutes les variables et
l'historique des appels de procédure chronologiquement pour pouvoir
déterminer où çà a foiré et pourquoi. Ca s'appelle parfois: "Analyse du
Dump".
Tonton Th wrote on 24/06/2015 06:03:
On 2015-06-23, Rambo <Richmond.TYAMS@pircarre.be> wrote:
Ben, heu .... j'avais la source complète de l'OS propriétaire qui me
&
Un jour en parcourant le code au moyen du dump mémoire, je tombe sur un
commentaire: "Si vous passez ici, donnez moi un dollar"
Donc tu as le source complet, mais il faut quand même faire
des dumps mémoire pour voir ce qu'il y a dedans ?
Tu n'as pas l'impression que c'est louche ?
le dump mémoire n'est pas fait pour voir ce qu'il y a dans le code, le
dump mémoire est fait pour fournir une image informatique de l'état de
la machine au moment du plantage de la machine.
Ce dump sert à déterminer la cause du crash.
Il ne sert à rien de se plonger dans le code pour savoir ce qui s'est
passé. On doit connaître la valeur de toutes les variables et
l'historique des appels de procédure chronologiquement pour pouvoir
déterminer où çà a foiré et pourquoi. Ca s'appelle parfois: "Analyse du
Dump".
Tonton Th wrote on 24/06/2015 06:03:On 2015-06-23, Rambo wrote:Ben, heu .... j'avais la source complète de l'OS propriétaire qui me
&Un jour en parcourant le code au moyen du dump mémoire, je tombe sur un
commentaire: "Si vous passez ici, donnez moi un dollar"
Donc tu as le source complet, mais il faut quand même faire
des dumps mémoire pour voir ce qu'il y a dedans ?
Tu n'as pas l'impression que c'est louche ?
le dump mémoire n'est pas fait pour voir ce qu'il y a dans le code, le
dump mémoire est fait pour fournir une image informatique de l'état de
la machine au moment du plantage de la machine.
Ce dump sert à déterminer la cause du crash.
Il ne sert à rien de se plonger dans le code pour savoir ce qui s'est
passé. On doit connaître la valeur de toutes les variables et
l'historique des appels de procédure chronologiquement pour pouvoir
déterminer où çà a foiré et pourquoi. Ca s'appelle parfois: "Analyse du
Dump".
Le Wed, 24 Jun 2015 23:36:52 +0200,
Rambo écrivait :Tonton Th wrote on 24/06/2015 06:03:On 2015-06-23, Rambo wrote:Ben, heu .... j'avais la source complète de l'OS propriétaire qui me
&Un jour en parcourant le code au moyen du dump mémoire, je tombe sur un
commentaire: "Si vous passez ici, donnez moi un dollar"
Donc tu as le source complet, mais il faut quand même faire
des dumps mémoire pour voir ce qu'il y a dedans ?
Tu n'as pas l'impression que c'est louche ?
le dump mémoire n'est pas fait pour voir ce qu'il y a dans le code, le
dump mémoire est fait pour fournir une image informatique de l'état de
la machine au moment du plantage de la machine.
Ce dump sert à déterminer la cause du crash.
Il ne sert à rien de se plonger dans le code pour savoir ce qui s'est
passé. On doit connaître la valeur de toutes les variables et
l'historique des appels de procédure chronologiquement pour pouvoir
déterminer où çà a foiré et pourquoi. Ca s'appelle parfois: "Analyse du
Dump".
Mouarf. Si tu n'as pas le code source à côté, cela ne sert
strictement à rien. Et même avec le code source, c'est assez
difficilement interprétable parce qu'une routine à l'autre bout du
code peut corrompre la mémoire (la pile, le tas, ce que tu veux...).
Le principal intérêt d'un dump mémoire, c'est de savoir où cela a
planté, peut-être pourquoi, mais pas plus. Essayer de remonter la
pile est commencer à faire l'hypothèse que rien ne l'a écrasé au
passage.
Enfin, tu peux faire cette hypothèse.
JKB
Le Wed, 24 Jun 2015 23:36:52 +0200,
Rambo <Richmond.TYAMS@pircarre.be> écrivait :
Tonton Th wrote on 24/06/2015 06:03:
On 2015-06-23, Rambo <Richmond.TYAMS@pircarre.be> wrote:
Ben, heu .... j'avais la source complète de l'OS propriétaire qui me
&
Un jour en parcourant le code au moyen du dump mémoire, je tombe sur un
commentaire: "Si vous passez ici, donnez moi un dollar"
Donc tu as le source complet, mais il faut quand même faire
des dumps mémoire pour voir ce qu'il y a dedans ?
Tu n'as pas l'impression que c'est louche ?
le dump mémoire n'est pas fait pour voir ce qu'il y a dans le code, le
dump mémoire est fait pour fournir une image informatique de l'état de
la machine au moment du plantage de la machine.
Ce dump sert à déterminer la cause du crash.
Il ne sert à rien de se plonger dans le code pour savoir ce qui s'est
passé. On doit connaître la valeur de toutes les variables et
l'historique des appels de procédure chronologiquement pour pouvoir
déterminer où çà a foiré et pourquoi. Ca s'appelle parfois: "Analyse du
Dump".
Mouarf. Si tu n'as pas le code source à côté, cela ne sert
strictement à rien. Et même avec le code source, c'est assez
difficilement interprétable parce qu'une routine à l'autre bout du
code peut corrompre la mémoire (la pile, le tas, ce que tu veux...).
Le principal intérêt d'un dump mémoire, c'est de savoir où cela a
planté, peut-être pourquoi, mais pas plus. Essayer de remonter la
pile est commencer à faire l'hypothèse que rien ne l'a écrasé au
passage.
Enfin, tu peux faire cette hypothèse.
JKB
Le Wed, 24 Jun 2015 23:36:52 +0200,
Rambo écrivait :Tonton Th wrote on 24/06/2015 06:03:On 2015-06-23, Rambo wrote:Ben, heu .... j'avais la source complète de l'OS propriétaire qui me
&Un jour en parcourant le code au moyen du dump mémoire, je tombe sur un
commentaire: "Si vous passez ici, donnez moi un dollar"
Donc tu as le source complet, mais il faut quand même faire
des dumps mémoire pour voir ce qu'il y a dedans ?
Tu n'as pas l'impression que c'est louche ?
le dump mémoire n'est pas fait pour voir ce qu'il y a dans le code, le
dump mémoire est fait pour fournir une image informatique de l'état de
la machine au moment du plantage de la machine.
Ce dump sert à déterminer la cause du crash.
Il ne sert à rien de se plonger dans le code pour savoir ce qui s'est
passé. On doit connaître la valeur de toutes les variables et
l'historique des appels de procédure chronologiquement pour pouvoir
déterminer où çà a foiré et pourquoi. Ca s'appelle parfois: "Analyse du
Dump".
Mouarf. Si tu n'as pas le code source à côté, cela ne sert
strictement à rien. Et même avec le code source, c'est assez
difficilement interprétable parce qu'une routine à l'autre bout du
code peut corrompre la mémoire (la pile, le tas, ce que tu veux...).
Le principal intérêt d'un dump mémoire, c'est de savoir où cela a
planté, peut-être pourquoi, mais pas plus. Essayer de remonter la
pile est commencer à faire l'hypothèse que rien ne l'a écrasé au
passage.
Enfin, tu peux faire cette hypothèse.
JKB
JKB wrote on 25/06/2015 14:29:Le Wed, 24 Jun 2015 23:36:52 +0200,
Rambo écrivait :Tonton Th wrote on 24/06/2015 06:03:On 2015-06-23, Rambo wrote:Ben, heu .... j'avais la source complète de l'OS propriétaire qui me
&Un jour en parcourant le code au moyen du dump mémoire, je tombe sur un
commentaire: "Si vous passez ici, donnez moi un dollar"
Donc tu as le source complet, mais il faut quand même faire
des dumps mémoire pour voir ce qu'il y a dedans ?
Tu n'as pas l'impression que c'est louche ?
le dump mémoire n'est pas fait pour voir ce qu'il y a dans le code, le
dump mémoire est fait pour fournir une image informatique de l'état de
la machine au moment du plantage de la machine.
Ce dump sert à déterminer la cause du crash.
Il ne sert à rien de se plonger dans le code pour savoir ce qui s'est
passé. On doit connaître la valeur de toutes les variables et
l'historique des appels de procédure chronologiquement pour pouvoir
déterminer où çà a foiré et pourquoi. Ca s'appelle parfois: "Analyse du
Dump".
Mouarf. Si tu n'as pas le code source à côté, cela ne sert
strictement à rien. Et même avec le code source, c'est assez
difficilement interprétable parce qu'une routine à l'autre bout du
code peut corrompre la mémoire (la pile, le tas, ce que tu veux...).
Le principal intérêt d'un dump mémoire, c'est de savoir où cela a
planté, peut-être pourquoi, mais pas plus. Essayer de remonter la
pile est commencer à faire l'hypothèse que rien ne l'a écrasé au
passage.
Enfin, tu peux faire cette hypothèse.
JKB
Exact, en fait j'aurais dû écrire:
Il ne sert à rien de se plonger dans le code SANS LE DUMP pour savoir ce qui s'est
passé.
JKB wrote on 25/06/2015 14:29:
Le Wed, 24 Jun 2015 23:36:52 +0200,
Rambo <Richmond.TYAMS@pircarre.be> écrivait :
Tonton Th wrote on 24/06/2015 06:03:
On 2015-06-23, Rambo <Richmond.TYAMS@pircarre.be> wrote:
Ben, heu .... j'avais la source complète de l'OS propriétaire qui me
&
Un jour en parcourant le code au moyen du dump mémoire, je tombe sur un
commentaire: "Si vous passez ici, donnez moi un dollar"
Donc tu as le source complet, mais il faut quand même faire
des dumps mémoire pour voir ce qu'il y a dedans ?
Tu n'as pas l'impression que c'est louche ?
le dump mémoire n'est pas fait pour voir ce qu'il y a dans le code, le
dump mémoire est fait pour fournir une image informatique de l'état de
la machine au moment du plantage de la machine.
Ce dump sert à déterminer la cause du crash.
Il ne sert à rien de se plonger dans le code pour savoir ce qui s'est
passé. On doit connaître la valeur de toutes les variables et
l'historique des appels de procédure chronologiquement pour pouvoir
déterminer où çà a foiré et pourquoi. Ca s'appelle parfois: "Analyse du
Dump".
Mouarf. Si tu n'as pas le code source à côté, cela ne sert
strictement à rien. Et même avec le code source, c'est assez
difficilement interprétable parce qu'une routine à l'autre bout du
code peut corrompre la mémoire (la pile, le tas, ce que tu veux...).
Le principal intérêt d'un dump mémoire, c'est de savoir où cela a
planté, peut-être pourquoi, mais pas plus. Essayer de remonter la
pile est commencer à faire l'hypothèse que rien ne l'a écrasé au
passage.
Enfin, tu peux faire cette hypothèse.
JKB
Exact, en fait j'aurais dû écrire:
Il ne sert à rien de se plonger dans le code SANS LE DUMP pour savoir ce qui s'est
passé.
JKB wrote on 25/06/2015 14:29:Le Wed, 24 Jun 2015 23:36:52 +0200,
Rambo écrivait :Tonton Th wrote on 24/06/2015 06:03:On 2015-06-23, Rambo wrote:Ben, heu .... j'avais la source complète de l'OS propriétaire qui me
&Un jour en parcourant le code au moyen du dump mémoire, je tombe sur un
commentaire: "Si vous passez ici, donnez moi un dollar"
Donc tu as le source complet, mais il faut quand même faire
des dumps mémoire pour voir ce qu'il y a dedans ?
Tu n'as pas l'impression que c'est louche ?
le dump mémoire n'est pas fait pour voir ce qu'il y a dans le code, le
dump mémoire est fait pour fournir une image informatique de l'état de
la machine au moment du plantage de la machine.
Ce dump sert à déterminer la cause du crash.
Il ne sert à rien de se plonger dans le code pour savoir ce qui s'est
passé. On doit connaître la valeur de toutes les variables et
l'historique des appels de procédure chronologiquement pour pouvoir
déterminer où çà a foiré et pourquoi. Ca s'appelle parfois: "Analyse du
Dump".
Mouarf. Si tu n'as pas le code source à côté, cela ne sert
strictement à rien. Et même avec le code source, c'est assez
difficilement interprétable parce qu'une routine à l'autre bout du
code peut corrompre la mémoire (la pile, le tas, ce que tu veux...).
Le principal intérêt d'un dump mémoire, c'est de savoir où cela a
planté, peut-être pourquoi, mais pas plus. Essayer de remonter la
pile est commencer à faire l'hypothèse que rien ne l'a écrasé au
passage.
Enfin, tu peux faire cette hypothèse.
JKB
Exact, en fait j'aurais dû écrire:
Il ne sert à rien de se plonger dans le code SANS LE DUMP pour savoir ce qui s'est
passé.
JKB wrote on 25/06/2015 14:29:Le Wed, 24 Jun 2015 23:36:52 +0200,
RamboTonton Th wrote on 24/06/2015 06:03:On 2015-06-23, RamboBen, heu .... j'avais la source complète de l'OS propriétaire
qui me
&Un jour en parcourant le code au moyen du dump mémoire, je tombe sur
un
commentaire: "Si vous passez ici, donnez moi un dollar"
Donc tu as le source complet, mais il faut quand même faire
des dumps mémoire pour voir ce qu'il y a dedans ?
Tu n'as pas l'impression que c'est louche ?
le dump mémoire n'est pas fait pour voir ce qu'il y a dans le code, le
dump mémoire est fait pour fournir une image informatique de
l'état de
la machine au moment du plantage de la machine.
Ce dump sert à déterminer la cause du crash.
Il ne sert à rien de se plonger dans le code pour savoir ce qui s'est
passé. On doit connaître la valeur de toutes les variables et
l'historique des appels de procédure chronologiquement pour pouvoir
déterminer où çà a foiré et pourquoi. Ca
s'appelle parfois: "Analyse du
Dump".
Mouarf. Si tu n'as pas le code source à côté, cela ne sert
strictement à rien. Et même avec le code source, c'est assez
difficilement interprétable parce qu'une routine à l'autre bout
du
code peut corrompre la mémoire (la pile, le tas, ce que tu veux...).
Le principal intérêt d'un dump mémoire, c'est de savoir
où cela a
planté, peut-être pourquoi, mais pas plus. Essayer de remonter la
pile est commencer à faire l'hypothèse que rien ne l'a
écrasé au
passage.
Enfin, tu peux faire cette hypothèse.
JKB
Exact, en fait j'aurais dû écrire:
Il ne sert à rien de se plonger dans le code SANS LE DUMP pour savoir ce
qui s'est
passé.
JKB wrote on 25/06/2015 14:29:
Le Wed, 24 Jun 2015 23:36:52 +0200,
Rambo
Tonton Th wrote on 24/06/2015 06:03:
On 2015-06-23, Rambo
Ben, heu .... j'avais la source complète de l'OS propriétaire
qui me
&
Un jour en parcourant le code au moyen du dump mémoire, je tombe sur
un
commentaire: "Si vous passez ici, donnez moi un dollar"
Donc tu as le source complet, mais il faut quand même faire
des dumps mémoire pour voir ce qu'il y a dedans ?
Tu n'as pas l'impression que c'est louche ?
le dump mémoire n'est pas fait pour voir ce qu'il y a dans le code, le
dump mémoire est fait pour fournir une image informatique de
l'état de
la machine au moment du plantage de la machine.
Ce dump sert à déterminer la cause du crash.
Il ne sert à rien de se plonger dans le code pour savoir ce qui s'est
passé. On doit connaître la valeur de toutes les variables et
l'historique des appels de procédure chronologiquement pour pouvoir
déterminer où çà a foiré et pourquoi. Ca
s'appelle parfois: "Analyse du
Dump".
Mouarf. Si tu n'as pas le code source à côté, cela ne sert
strictement à rien. Et même avec le code source, c'est assez
difficilement interprétable parce qu'une routine à l'autre bout
du
code peut corrompre la mémoire (la pile, le tas, ce que tu veux...).
Le principal intérêt d'un dump mémoire, c'est de savoir
où cela a
planté, peut-être pourquoi, mais pas plus. Essayer de remonter la
pile est commencer à faire l'hypothèse que rien ne l'a
écrasé au
passage.
Enfin, tu peux faire cette hypothèse.
JKB
Exact, en fait j'aurais dû écrire:
Il ne sert à rien de se plonger dans le code SANS LE DUMP pour savoir ce
qui s'est
passé.
JKB wrote on 25/06/2015 14:29:Le Wed, 24 Jun 2015 23:36:52 +0200,
RamboTonton Th wrote on 24/06/2015 06:03:On 2015-06-23, RamboBen, heu .... j'avais la source complète de l'OS propriétaire
qui me
&Un jour en parcourant le code au moyen du dump mémoire, je tombe sur
un
commentaire: "Si vous passez ici, donnez moi un dollar"
Donc tu as le source complet, mais il faut quand même faire
des dumps mémoire pour voir ce qu'il y a dedans ?
Tu n'as pas l'impression que c'est louche ?
le dump mémoire n'est pas fait pour voir ce qu'il y a dans le code, le
dump mémoire est fait pour fournir une image informatique de
l'état de
la machine au moment du plantage de la machine.
Ce dump sert à déterminer la cause du crash.
Il ne sert à rien de se plonger dans le code pour savoir ce qui s'est
passé. On doit connaître la valeur de toutes les variables et
l'historique des appels de procédure chronologiquement pour pouvoir
déterminer où çà a foiré et pourquoi. Ca
s'appelle parfois: "Analyse du
Dump".
Mouarf. Si tu n'as pas le code source à côté, cela ne sert
strictement à rien. Et même avec le code source, c'est assez
difficilement interprétable parce qu'une routine à l'autre bout
du
code peut corrompre la mémoire (la pile, le tas, ce que tu veux...).
Le principal intérêt d'un dump mémoire, c'est de savoir
où cela a
planté, peut-être pourquoi, mais pas plus. Essayer de remonter la
pile est commencer à faire l'hypothèse que rien ne l'a
écrasé au
passage.
Enfin, tu peux faire cette hypothèse.
JKB
Exact, en fait j'aurais dû écrire:
Il ne sert à rien de se plonger dans le code SANS LE DUMP pour savoir ce
qui s'est
passé.
Le vendredi 26 Juin 2015 à 00:07 par Rambo :
Il ne sert à rien de se plonger dans le code SANS LE DUMP pour savoir ce
qui s'est
passé.
Je crois surtout que soit tu confonds dump et deboguage, soit tu n'as
sources / n'a jamais eu à faire du tracage de bug.
Un dump te servira jamais à voir ce qui cloche dans les sources /
d’exécution par rapport aux sources, il va uniquement te dire l'état
au moment du plantage.
Le vendredi 26 Juin 2015 à 00:07 par Rambo :
Il ne sert à rien de se plonger dans le code SANS LE DUMP pour savoir ce
qui s'est
passé.
Je crois surtout que soit tu confonds dump et deboguage, soit tu n'as
sources / n'a jamais eu à faire du tracage de bug.
Un dump te servira jamais à voir ce qui cloche dans les sources /
d’exécution par rapport aux sources, il va uniquement te dire l'état
au moment du plantage.
Le vendredi 26 Juin 2015 à 00:07 par Rambo :
Il ne sert à rien de se plonger dans le code SANS LE DUMP pour savoir ce
qui s'est
passé.
Je crois surtout que soit tu confonds dump et deboguage, soit tu n'as
sources / n'a jamais eu à faire du tracage de bug.
Un dump te servira jamais à voir ce qui cloche dans les sources /
d’exécution par rapport aux sources, il va uniquement te dire l'état
au moment du plantage.