Discussion :

[K007024]

Bonjour,

Je me bat sur quelque chose de sans doute très simple depuis un petit moment.
La solution doit etre toute c**** et le problème doit se situer entre l'écran et la chaise.

Voici mon code :

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
    const double* pY1 = mongetter    
    const double* pX1 = mongetter
    double *pY2;
    double *pX2;
    pY2 = new double[i2];
    pX2 = new double[i2];
    double xi;
    wxMessageBox("A");
    for (int i = 0; i < i2; i++)
    {
        xi = (1 - i /(i1-1.0)) * pX1[0] + (i /(i2-1.0)) * pX1[i1-1];
        *(pX2+i) = xi;
        *(pY2+i) = 0;
        wxMessageBox("A " + wxString::Format(wxT("%d\n%lf\n%lf"), i, xi, *(pX2+i)));
    }
wxMessageBox("B");
 
 
// transmission à une autre méthode

Le code est sale (pas mal de test et de modifs) mais le problème est le suivant : avec la message box, ça passe, sans, ça crash (après "A" et avant "B").

Note1 : j'ai essayé avec du double* pX2 = new double[i2] et le soucis est le même.
Note2 : je ne viens pas du C++...
Note3 : idéalement j'aimerais dégager xi et l'initialisation de pY2

Merci d'avance,
K


edit :

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
    /** Get old containers and prepare new containers (time/value) */
    const double* pY1 = tmongetter    
    const double* pX1 = mongetter 
    double* pY2 = new double[i2];
    double* pX2 = new double[i2];
    double xi;
    wxMessageBox("A");
    for (int i = 0; i < i2; i++)
    {
        xi = (1 - i /(i1-1.0)) * pX1[0] + (i /(i2-1.0)) * pX1[i1-1];
        pX2[i] = 0; //double(xi);
        pY2[i] = 0;
        //wxMessageBox("A " + wxString::Format(wxT("i = %d\nX = %lf\nX = %lf\nY = %lf"), i, xi, pX2[i], pY2[i]));
    }
wxMessageBox("B");

Le code ci-dessus fonctionne, sauf quand je décommente le double(xi);
Ce serait donc un soucis avec xi...qui serait levé si je l'utilise ponctuellement dans un messagebox...

edit : avec la ligne ci dessous ça passe. Mais si ça marche dans mon cas, je perds en précision et la solution n'est pas très convenable...(donc je suis preneur d'une vraie résolution de mon soucis)

Code :

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

 pX2[i] = floor(xi*100)/100;

[prgasp77]

Qu'est-ce que ça donne en pas à pas avec un débogueur ?

Que valent pX1, pY1, pX2, pY2 (affiche ou teste la valeur des pointeurs) ?
Que vaut i1 (il ne serait pas =0 des fois ?) ?

Cdlt,

[K007024]

Qu'est-ce que ça donne en pas à pas avec un débogueur ?

Que valent pX1, pY1, pX2, pY2 (affiche ou teste la valeur des pointeurs) ?
Que vaut i1 (il ne serait pas =0 des fois ?) ?

Cdlt,

pX1, pY1 sont les temps et les valeurs d'un enregistrement.
pX1 représente un compte en microseconde (toujours positif ou nul).

pX2, pY2 sont les contenaires du futur signal rééchantillonné.
Je dois reconstruire un pX2 avant de pouvoir interpoler pour avoir mon pY2.

Le i1 n'est jamais égal à 0 (c'est testé en amont : la variable n'aurait pas été créee si l'enregistrement était vide).


Le soucis semble venir du x1 qui va taper dans les N heures (N<24) en microseconde...et avec les digits d'une division.
Mais normalement, un double c'est du long float donc c'est du 10^308. Un soucis de décimale avec trop de digit je pense.
Ce que je ne comprends pas c'est comment un double ne peut pas rentrer dans un array de double >.< (on passe en overflow ?)

[prgasp77]

Plusieurs choses :

1. Tente avec un débogueur pas-à-pas.
2. Tu ne nous as pas énoncés les symptomes ; du titre je suppose que l'application se termine prématurément, mais plus d'information serait appréciable.
3. Tente avec un débogueur pas-à-pas.
4. Je ne demandais pas ce que représentaient les pX1, etc. mais ce que valaient les variables (la valeur du pointeur).
5. Teste avec un débogueur pas-à-pas.
6. Si tu as activé les optimisations, il se peut que l'application se termine (::abort()) lors du calcul de xi mais que celui-ci ne soit pas effectué quand la valeur de xi n'est pas lue.
7. Tente avec un débogueur pas-à-pas.
8. Peux-tu faire générer un dump à ton application ?
9. Tente avec un débogueur pas-à-pas.

Tu l'auras compris, certains conseils / demandes sont plus importantes que d'autres .

[jo_link_noir]

Je ne trouve pas le débogueur pas pratique pour corriger les problèmes mémoire. Perso, avant de le lancer je passe par des outils comme asan (-fsanitize=address pour le compilo (voir aussi -lasan)) et valgrind/dr memory.

Sinon, quelles sont les tailles de mongetter et tmongetter ? Pourquoi des tableaux c-style plutôt que std::vector ?

[K007024]

Merci de vos pistes, je test ça au fur et à mesure que j'écris ce message.

Tout d'abord, concernant les tailles de getter et setter...ça peut aller de quelques données à plusieurs milliers. Dans mon cas test, les infos venant de getter et setter sont des array de 10 élément (un sinus échantillonné) et i2 vaut 20 (je veux passer d'un vecteur de 10 données à un de 20). En cas d'utilisation normal, il n'y a pas de limitation (hormis la mémoire bécane et celle de la bécane qui fait les records en amont). Pourquoi pas un vector...j'ai pesté contre le choix des array aussi. C'est un choix techno précédent sur lequel je ne suis pas maitre et duquel je ne peux pas m'affranchir...

Sinon, vu qu'on est dans la section "débuter" et que je ne connais pas les vagrid et autre asan, je vais faire en fonction de mes moyens via debugger.

Plusieurs choses :

1. Tente avec un débogueur pas-à-pas.
2. Tu ne nous as pas énoncés les symptomes ; du titre je suppose que l'application se termine prématurément, mais plus d'information serait appréciable.
3. Tente avec un débogueur pas-à-pas.
4. Je ne demandais pas ce que représentaient les pX1, etc. mais ce que valaient les variables (la valeur du pointeur).
5. Teste avec un débogueur pas-à-pas.
6. Si tu as activé les optimisations, il se peut que l'application se termine (::abort()) lors du calcul de xi mais que celui-ci ne soit pas effectué quand la valeur de xi n'est pas lue.
7. Tente avec un débogueur pas-à-pas.
8. Peux-tu faire générer un dump à ton application ?
9. Tente avec un débogueur pas-à-pas.

Tu l'auras compris, certains conseils / demandes sont plus importantes que d'autres .

Je me suis remis sur cette configuration ci :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
    const double* pY1 = mongetter    
    const double* pX1 = tmongetter    
    double* pY2 = new double[i2];
    double* pX2 = new double[i2];
    double xi;
    for (int i = 0; i < i2; i++)
    {
        xi = (1 - i /(i2-1.0)) * pX1[0] + (i /(i2-1.0)) * pX1[i1-1];
        //pX2[i] = floor(xi*100)/100;
        pX2[i] = xi;
        pY2[i] = 0;
        //wxMessageBox("A " + wxString::Format(wxT("i = %d\nX = %lf\nX = %lf\nY = %lf"), i, xi, pX2[i], pY2[i]));
    }

En release ça crash, pas d'information. SI l'une des deux ligne commentée est décommentée ça passe.
Je teste donc en debugger point par point.

1. Avec le debugger, pas de crash... (alors que sans, j'ai un crash)
2. Vu qu'avec le debugger pas de crash, je n'ai pas plus d'info que monsoft a cesser de fonctionner windows etc
3. idem.
4. à la fin du for : pX1 = 0x821d7e8, oX2 = 0x81d1800, xi = 9100000 (mais au court d'un for xi peut prendre des valeurs du genre 6.9122060681020032e-308 (limite du double ?)
6. Optim ? Kezako ? (je ne maitrise pas mais j'ai hérité du setting -s, -O3 -march=core2. Tu penses que le -03 strip all symbol grom binary (minimize size) pourrait etre la source du probleme ? Je suis neuf sur ces questions...
8. Qu'est-ce qu'un dump ? (sus forum debuter, hein ;-)

[foetus]

Regarde plutôt du côté de pX1[i1-1]: si i1 que tu ne donnes pas la valeur, et supérieur au nombre d'éléments de pX1 cela crashe.

Après que le debugger crashe 1 ligne plus loin, ce n'est pas normal, mais occasionnel

[K007024]

i1 représente le nombre d'éléments des array du signal 1 (pX1, pY1).
Il est forcement supérieur à 1 (mais il n'y a pas de protection dans cette partie-ci du soft et c'est une erreur, je corrige).
De même pX1[i1-1] pourrait valoir 0 mais ce n'est pas le cas sur mon test qui crash (puis physiquement...).

Par contre, j'aurais peut être intérêt à mettre i1-1 et plus globalement pX1[i1-1] à l'extérieur de la boucle dans une variable créée pour l'occasion.


...ça m'ennuie assez ces problèmes non reproductibles en debug >.>

[prgasp77]

Je ne trouve pas le débogueur pas pratique pour corriger les problèmes mémoire. Perso, avant de le lancer je passe par des outils comme asan (-fsanitize=address pour le compilo (voir aussi -lasan)) et valgrind/dr memory.

Je suis d'accord, mais ...

Sinon, vu qu'on est dans la section "débuter" et que je ne connais pas les vagrid et autre asan, je vais faire en fonction de mes moyens via debugger.

Ceci dit, il va falloir maintenant.

Ajoute ces paramètres à ta ligne de compilation : -fsanitize=address -fno-omit-frame-pointer et lance ton programme de cette façon : ./binary 2>&1 | asan_symbolize.py | c++filt.

• asan_symbolize.py
• c++filt

Plus d'info : http://clang.llvm.org/docs/AddressSanitizer.html

Valgrind est aussi un merveilleux outil. Sur une distribution linux, packet_handler install valgrind. Guide rapide valgrind.
Sur windows, il faut passer par wine .

Un "dump" est un fichier qui peut être généré par une application lors d'un crash (en réalité, c'est le système qui à cette charge). Il contient plein d'informations sur l'incident, comme la stack trace, la valeur des variables lors du crash, etc... Sur linux, ulimit permet d'activer la génération de ces cores.


Tente de compiler en -O2, et sans -O0 (ô-zéro) et dis-nous si crash il y a.
Bon courage.

[Médinoc]

D'ou viennent mongetter et tmongetter?

[K007024]

D'une autre partie du soft, en amont et déjà verrouillée (le nom des méthodes chainées n'apportait pas pour mon probleme).

Sinon, nouvelle avancée :

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
   const double* pY1 = mongetter;
    const double* pX1 = tmongetterr;
    double* pY2 = new double[i2];
    double* pX2 = new double[i2];
    double xi, AvPercent;
    double x1_min = pX1[0];
    double x1_max = pX1[i1-1];
    double x1_dif = x1_max - x1_min;
 
    for (int i = 0; i < i2; i++)
    {
        AvPercent = i /(i2-1.0);
        pX2[i] = AvPercent * x1_dif + x1_min;
        pY2[i] = 0;
    }

Comme ça, ça passe. Et il n'y a plus de floor.

Vu l'investigation menée précédemment...je ne sais pas.
Le problème venait soit de la précision xi (ou cf. la remarque au dessus concernant le calcul) soit des optim couplé au xi (pas modifiée pour la résolutin, c'est toujours en -s -O3 -march=core2 chez moi)