problème avec un new[]

Version imprimable

11/11/2006, 22h00
f56bre

problème avec un new[]

Salut,

J'ai une classe contenant un pointeur que j'initialise dans le constructeur à NULL. Une autre classe contient un pointeur vers ma première classe ainsi qu'une méthode dans laquelle j'alloue la mémoire nécessaire à mon premier pointeur. Cette allocation fonctionne très bien pour un tableau de 300 floats mais quand je passe à 3000 ça fait planter le programme. J'avoue que je ne vois pas où est le problème.

ps : voici la ligne qui plante

Code:

buffer->ptr = new float[ 3000 ];

buffer étant bien sûr une istance de ma première classe.
11/11/2006, 22h12
Invité

Cette ligne est évidemment juste. Tu t'attendais à quoi ? On n'est pas dans ta tête, on ne va pas indiquer les erreurs de ton code en lisant juste cette ligne.

Merci de réfléchir avant de poser une question, il est évident que dans l'état actuel ça sert à rien.

Pour ce qui est du "plantage" (sur lequel on ne sait rien non-plus), essaye un débuggeur.
11/11/2006, 22h19
f56bre

Il est évident que j'attend ici des retours d'expériences sur ce genre d'erreurs pour ceux qui connaissent les problèmes qui peuvent advenir avec l'opérateur new et les compositions de classes. Si t'en as pas en stock tant pis je m'en passerais...
11/11/2006, 23h02
thewho

Bonjour,

Citation:

Envoyé par f56bre

Il est évident que j'attend ici des retours d'expériences sur ce genre d'erreurs pour ceux qui connaissent les problèmes qui peuvent advenir avec l'opérateur new et les compositions de classes. Si t'en as pas en stock tant pis je m'en passerais...

Et pourtant, quoi que tu puisses en penser, remram44 a raison.

A moins que tu nous prennes pour des devins, auquel cas, ce sera 60 € la réponse.

Je reprends donc la remarque de remram44 à mon compte : comment veux-tu qu'on t'aide à la vue de la seule ligne que tu daignes nous montrer, et qui, comme tu le sais très bien, est syntaxiquement correcte ?
11/11/2006, 23h58
khayyam90

j'ai oublié ma boule de cristal mais je vais tenter : buffer est-il alloué ? S'il ne l'est pas, un appel à buffer->ptr donne un plantage.
12/11/2006, 00h47
koala01

conseil de base pour poser une question: aidez nous à vous aider...

Salut,

Syntaxiquement, la ligne est des plus correcte...

En se basant sur cette seule ligne, il faut bien prendre conscience que l'on n'a aucune information qui nous permette de t'aider...

Comme indiqué par khayyam90 :salut:, une des premières idées qui viennent en tete est le fait que buffer n'est pas alloué...

La deuxième idée qui peut venir en tete est, tout simplement, l'impossiblité du système de trouver un espace mémoire contigu de 3000 floats... (ce qui fait, selon les compilateurs, pas loin de 3000*64 bits...soit... 187ko environ)

Maintenant, si tu veux plus de précision, sois sympa, et donne nous un code minimum compilable qui nous permette de reproduire le phénomène ;)

Voici mon code

La classe Buffer

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
class Buffer
{
    public:
 
        float * ptr;
        int taille_ptr;
 
 
    public:
        Buffer();
        ~Buffer();
 
};

Le constructeur et le destructeur

Code:

1
2
3
4
5
6
7
8
9
10
11
12
 
Buffer::Buffer()
{
    ptr = NULL;
    taille_ptr = 0;
}
 
 
Buffer::~Buffer()
{
    delete[] ptr;
}

Voici la classe Bloc qui contient le pointeur vers la classe Buffer

Code:

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
 
class Bloc{
 
    private:
 
        /* les coordonnées en x et y servent à savoir ou est placé le bloc
           sur lequel on travail */
        unsigned int coordonnee_x;
        unsigned int coordonnee_y;
 
        SDL_Surface * heightmap;
 
        Buffer * buffer;
 
    public:
 
 
        Bloc( unsigned int coord_x = 0 , unsigned int coord_y = 0 );
        ~Bloc();
 
        int Rempli_buffer( unsigned int pas );
 
        int Charge_heightmap( char * source );
 
};

Et voici la fonction qui pose problème

Code:

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
30
31
int Bloc::Rempli_buffer( unsigned int pas )
{
    int nbr_mesh,i,j;
 
    if( buffer == NULL ) buffer = new Buffer;
 
    if( pas != 0 )
    {
        // calcul du nombre de mesh
        nbr_mesh = (int)heightmap->w/pas;
 
        buffer->ptr = new float[ (nbr_mesh+1)*(nbr_mesh+1)*3];
        buffer->taille_ptr = 0;
 
        for( j=0 ; j<=nbr_mesh ; j++ )
        {
            for( i=0 ; i<=nbr_mesh ; i++)
            {
                buffer->taille_ptr += 3;
 
                buffer->ptr[ 3*i + j*3*(nbr_mesh+1) ] = (float)i*pas;
                buffer->ptr[ 3*i + j*3*(nbr_mesh+1) + 1 ] = (float)j*pas;
                buffer->ptr[ 3*i + j*3*(nbr_mesh+1) + 2 ] = 0.0; 
            }
        }
 
    }
 
    return 0;
 
}

Lors de l'appel de cette dernière fonction une image .bmp de 1024*1024 est chargée dans heightmap et je prend un pas de 16, on a donc nbr_mesh = 64.
Sinon au niveau du constructeur de la classe Bloc rien de spécial, je met tous les pointeurs (dont buffer) à NULL.

12/11/2006, 11h24
zenux

Salut,

A mon avis, il ne passe pas dans cette condition : if( buffer == NULL ) buffer = new Buffer;

Initialise buffer à NULL dans le constructeur de Bloc.
12/11/2006, 13h05
f56bre

Justement j'initialise buffer à NULL dans le constructeur de Bloc mais pour être sûr qu'il passe bien dans la condition j'ai ajouté un fprintf(stderr,"passe ici"); et ... il passe bien dans le if.
12/11/2006, 13h08
Médinoc

tu devrais vérifier si le new ne lance pas une exception std::bad_alloc (oui, je ne sais pas qui a eu cette idée géniale, mais le new par défaut ne renvoie plus NULL si l'allocation échoue... :mur:

J'ai échangé la ligne d'allocation par ça
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 try { buffer->ptr = new float[ (nbr_mesh+1)*(nbr_mesh+1)*3 ]; } catch(bad_alloc& ex) { ofstream f("erreur.txt"); if (f.is_open()) { f << ex.what() << endl; f.close(); } }
Et pas de fichier erreur.txt créé (si je met un simple fprintf(stderr,...) dans le catch rien n'est écrit non plus). Il ne semble pas aller dans le catch.

12/11/2006, 14h29
f56bre

J'ai entouré ce bloc par 2 fprintf(stderr,"ici"); et seul le premier est effectué. L'erreur est donc bien là
12/11/2006, 14h46
loufoque

Bah apparemment, t'as un gestionnaire d'exceptions global merdique qui te les affiche pas.
12/11/2006, 15h02
f56bre

Et il y a une solution pour ça?
12/11/2006, 15h13
Médinoc

Récupérer localement l'exception avec un try/catch() et l'afficher...
Genre, ce qu'est supposé faire ton dernier code...
12/11/2006, 15h23
f56bre

J'avoue que j'ai du mal à saisir la différence, peux-tu me donner un exemple?
12/11/2006, 16h04
f56bre
J'ai essayé cette version là pour l'allocation
Code:

1 2 buffer->ptr = new (nothrow) float [(nbr_mesh+1)*(nbr_mesh+1)*3]; if( buffer->ptr == 0 ) fprintf(stderr,"erreur d'allocation");
Mais toujours rien, pourtant le programme s'arrète avec un status 3 (code::blocks avec GCC).
12/11/2006, 16h09
Médinoc

Cela peut également être le résultat d'une corruption du tas entre la dernière allocation et celle-ci.
Vérifie que tu n'as pas fait un dépassement de buffer ou un truc du genre...
12/11/2006, 17h09
f56bre

L'allocation précedant celle-ci est celle de buffer (j'ai d'ailleur ajouté la même gestion d'erreur d'allocation que pour le ptr) et entre les 2 il n'y a rien.

J'ai recompilé avec les options de debug puis fait un "run to cursor" en plaçant ce dernier après la ligne d'allocation de ptr. J'ai alors des valeurs pour bloc et buffer mais pour ptr j'ai "No symbol "ptr" in current context". Si je place le curseur un peu plus loin (là ou je rempli le tableau ptr) j'ai logiquement une segmentation fault.
12/11/2006, 18h23
f56bre

J'ai ajouté cette ligne juste avant l'allocation de ptr

Code:

float * ptr2 = new float[100000];

histoire de tester si une allocation était possible et aucun soucis de ce côté.
12/11/2006, 23h40
Luc Hermitte

Cela sent la corruption de mémoire sans rapport avec la ligne que tu nous montres.

De sûr j'ai repéré un problème lié aux copies que tu n'as pas interdites. Après, les vecteurs m'entretiennent trop dans ma fainéantise pour que je regarde plus précisément le code (gérant mal la mémoire ; et à 100 lieues d'un ECM) d'un autre à une heure pareille. :roll:
13/11/2006, 00h05
f56bre

C'est justement parce que je galère avec mon code que je poste, sachant qu'il y a sur ce forum des gens bien plus qualifié. Pourrais-tu m'éclairer sur les copies non interdites? Qu'est-ce qu'un ECM?
13/11/2006, 00h37
Luc Hermitte

Exemple
Complet -> compile et reproduit le problème observé
Minimal -> rien de superflu (beaucoup de superflu dans l'extrait que tu as donnée -- pas celui avec juste le new, qui était tout sauf complet)

Deux avantages aux ECM:
- On est plus susceptibles de regarder -- ce que tu décris sent à plein nez la corruption qui fait tout planter 5 minutes après (/500 lignes de codes après...) ; cherchez pas ailleurs avec vos try-catch, il y a largement assez de mémoire pour charger une image ; ceci dit il y a une superbe fuite dans ta fonction de remplissage
- Trouver l'ECM permet à celui dans le besoin de comprendre et voir à partir de quel moment cela ne va plus, et de réfléchir au pourquoi. Bref, à progresser.

Et en toute honnêteté (et je suis surpris qu'après deux pages je sois le premier à t'y pousser ; j'ai manqué un message?), les vecteurs sont tes amis. Surtout pour gérer des tableaux dynamiques. Tu y gagneras en robustesse, maintenabilité, cachets d'aspirine consommés, ...
NB: les vecteurs ne dispensent pas plus tard d'apprendre à manipuler correctement la mémoire -- pour au final retourner vers les vecteurs ou toute autre solution RAII adaptée au problème (-> FAQ!)
13/11/2006, 11h25
f56bre

Ok pour les vecteurs mais mon tableau est en fait un tableau de sommets destinés à être envoyés à glDrawElement qui réclame un pointeur vers un tableau de vertices. Sinon j'avoue que j'ai beau y regarder de plus près je ne vois pas la belle fuite memoire dans ma fonction de remplissage:oops:
13/11/2006, 11h48
Jean-Marc.Bourguet

Tu peux vraisemblablement passer &vect[0].
13/11/2006, 23h09
Luc Hermitte

La fuite de mémoire est au niveau de ton new.
L'allocaton n'étant pas dans le constructeur, j'en déduis que la fonction peut être appellée plusieurs fois. Au deuxième appel, cela fuira. A moins qu'il y ait une fonction de libération. De toutes façon, pour corriger ton problème, il faut revoir/reprendre l'intégralité des cycles de vie (éventuellement multiples) de tes zones de mémoires allouées dynamiquement.

Si j'ai d'autres conseils à donner:
- que Buffer ait l'entière responsabilité de ses membres => interdiction à l'extérieur de modifier quoique ce soit -- cf encapsulation, couplage, ...
- nbr_mesh porte mal son nom (vu qu'il contient le nombre - 1)