Discussion :

[f56bre]

Salut,

Lorsque je fais ceci pas de problème

Code :

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

ptr = (float *)malloc( 3*sizeof(float) );

mais losrque je fais cela

Code :

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

ptr = (float *)malloc(4225*3*sizeof(float) );

cette ligne provoque un arrêt de mon programme.
Pourtant j'ai 512Mo de RAM et je tente un allocation de 76Ko, ça ne peut être un dépassement de mémoire (j'ai redémarré le pc et lancé uniquement le programme pour être sûr).
Peut-être n'aime t'il pas trop l'allocation de gros blocs?

[Emmanuel Delahaye]

Lorsque je fais ceci pas de problème

Code :

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

ptr = (float *)malloc( 3*sizeof(float) );

mais losrque je fais cela

Code :

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

ptr = (float *)malloc(4225*3*sizeof(float) );

cette ligne provoque un arrêt de mon programme.

C'est pas possible. La cause est ailleurs. Montre le code réduit au minimum qui pose problème. Et vire moi ces casts inutiles.

http://emmanuel-delahaye.developpez....tes.htm#malloc

[f56bre]

j'ai remplacé le malloc par un boucle de realloc et celle-ci s'arrête (arrêt d'execution du programme) avant d'avoir terminé.
Pour les cast c'est parce que j'utilise le malloc dans un programme en C++ mais avec l'opérateur new j'avais le même problème.

[Emmanuel Delahaye]

j'ai remplacé le malloc par un boucle de realloc et celle-ci s'arrête (arrêt d'execution du programme) avant d'avoir terminé.
Pour les cast c'est parce que j'utilise le malloc dans un programme en C++ mais avec l'opérateur new j'avais le même problème.

Tant que je ne vois pas le code qui plante, je ne peux rien dire.

[gege2061]

cette ligne provoque un arrêt de mon programme.

Le standard Unix98 réclame que malloc(), calloc(), et realloc() positionne errno à ENOMEM en cas d'échec. La Glibc suppose qu'il en est ainsi (et les versions glibc de cette routine le font). Si vous utilisez une implémentation personnelle de malloc qui ne positionne pas errno, certaines routines de bibliothèques peuvent échouer sans donner de raison dans errno.
Lorsqu'un programme se plante durant un appel à malloc(), calloc() ou realloc(), ceci est presque toujours le signe d'une corruption du tas (zone de mémoire dans laquelle sont allouées les variables dynamiques). Ceci survient généralement en cas de débordement d'un bloc mémoire alloué, ou en libérant deux fois le même pointeur.

[f56bre]

merci

Lorsque j'ai remplaçé ma séquence malloc+ecriture par realloc+erciture+realloc+ecriture+... je tentais d'écrire dans de la mémoire non allouée d'où le pb. Pour le malloc je vais réétudier mon code parce que je m'excuse auprès d' Emmanuel Delahaye mais il est un peut bordelique et je ne pouvais en extraire un bout facilement.

[Emmanuel Delahaye]

Pour le malloc je vais réétudier mon code parce que je m'excuse auprès d' Emmanuel Delahaye mais il est un peut bordelique et je ne pouvais en extraire un bout facilement.

Oui, ma requête

Montre le code réduit au minimum qui pose problème.

n'était pas anodine. C'est une bonne manière de tester la qualité du code écrit. C'est aussi une méthode de déboguage bien connue...

L'expérience montre que le code bordélique :

• ne fonctionne pas
• tombe en marche par hasard
• ne peux pas être dépanner
• ne peux pas évoluer.

Je te conseille donc de changer de manière de travailler et d'apprendre à écrire du code propre. On en poste ici régulièrement. Pose des questions si besoin est.

Il y a quelques informations censées être utiles sur mon site et sur mon blog...

[denoo]

moi j'ai fait un simple programme de test pour malloc avec turbo C 2.01
et je n'ai pas pu dépasser 62244 octets
alors emmanuel, pourqoi ?

[Emmanuel Delahaye]

moi j'ai fait un simple programme de test pour malloc avec turbo C 2.01
et je n'ai pas pu dépasser 62244 octets
alors emmanuel, pourqoi ?

La norme C89 impose que la taille maximale d'un objet (statique ou alloué) soit supérieure à 32767. Le contrat est donc respecté. (Marche plus :sweat: ?)

Retour sur la préhistoire de l'informatique...

D'autre part, il faut se souvenir que Turbo C 2.01 est un compilateur travaillant en mode x86 réel 16-bit avec des segments de données qui ont une taille maximale de 65536 bytes (64k). Tu arrives à 62244 pour un objet, c'est pas si mal.

Ensuite, le nombre de segments mémoire accessibles (limité par le DOS à 10 : les fameux 640k) dépendent du modèle de mémoire. En modèle large (le plus compatible), on a accès à plusieurs segments. On peut donc définir en théorie 7 ou 8 objets de cette taille. Mais il y a peut être d'autres contraintes que j'ignore et qui limitent les possibilités...

http://fr.wikipedia.org/wiki/X86_32

[Médinoc]

EN DOS 16bits, les pointeurs sans modificateur sont généralement des pointeurs courts (16 bits, aussi appelés pointeur "near"). Donc, malloc() retourne également un pointeur court ("near"), et est donc forcé d'allouer dans cet espace d'adressage restreint.

Dans l'EDI DOS que j'avais (Microsoft QuickC), le SDK proposait la fonction _fmalloc() qui elle, retournait un pointeur long (pointeur "far").

[Emmanuel Delahaye]

EN DOS 16bits, les pointeurs sans modificateur sont généralement des pointeurs courts (16 bits, aussi appelés pointeur "near"). Donc, malloc() retourne également un pointeur court ("near"), et est donc forcé d'allouer dans cet espace d'adressage restreint.

Dans l'EDI DOS que j'avais (Microsoft QuickC), le SDK proposait la fonction _fmalloc() qui elle, retournait un pointeur long (pointeur "far").

Et ça change quoi ? La taille d'un segment est de 64k en mode réel. C'est intangible.

Le seul intérêt de farmalloc() ou de travailler en modèle large, ce que j'ai déjà recommandé, c'est d'augmenter le nombre de segments disponibles. Mais pas la taille de ceux-ci...

[Médinoc]

Bien sûr.
Je n'ai pas dit le contraire. Mais j'ai sans doute mal compris la question, au temps pour moi.