std::bad_alloc est-elle bien utile…

Version imprimable

08/12/2016, 15h33
camboui

std::bad_alloc est-elle bien utile…
Je viens de faire un test tout simple afin de vérifier/modifier certaines habitudes de codage, du genre:
Code:

1 2 3 4 5 6 7 8 9 10 try { voidptr = ::operator new(stupid_big_value); if (voidptr) ...; } catch (std::bad_alloc &) { ... }
Sous Windows et Visual Studio 2015, machine avec 8GB de mémoire physique, j'ai alloué quelques terrabytes...

Code:

stupid_big_value = 8ull * 1024 * 1024 * 1024 * 65536;

... Et aucune exception n'est levée 8O

Certains diront que c'est normal, la mémoire (virtuelle) est réservée mais non commitée.
Je n'ose pas faire un memset(voidptr, 0, stupid_big_value), mais ce serait amusant de voir quand le système se fige...

En bref, à quoi bon perdre son temps à essayer de récupérer un std::bad_alloc ou vérifier la nullité d'un pointeur après allocation, si, à priori, la mémoire est toujours "allouée".
08/12/2016, 15h55
koala01

Salut,

Je me suis amusé il y a peu à voir la taille la plus grande que le système était prêt à m'allouer pour un std::vector sous linux (avec seulement 6 Gb de mémoire et 2Gb de swap ;) ) pour y placer les différents types primitifs, et cette taille va de std::numeric_limits<std::ptr_t>::max() à std::numeric_limits<std::ptr_t>::max()/2, ce qui implique que la taille susceptible d'être allouée dépend de la première limite atteinte entre l'ensemble de la mémoire disponible et le nombre d'adresses devant être représentées ;)

Il faut cependant garder en tête qu'une application n'est que rarement seule à fonctionner sur un ordinateur, et que l'utilisation de la mémoire (physique et virtuelle) dépend de ce que font toutes les applications qui tournent à un instant T de l'utilisation de ton ordinateur ;)

Pour moi, manière générale, si une exception de type bad_alloc a été lancée, le mieux que tu aies à faire est sans doute encore de laisser planter correctement l'application, sans essayer de résoudre le problème : il se peut que ton application (celle dans laquelle l'allocation échoue) n'utilise que très peu de mémoire allouée dynamiquement, mais que le système en ait -- tout simplement -- donné tellement à d'autres applications qu'il n'est purement et simplement plus en mesure d'en donner la moindre parcelle à aucune application :P

Cependant, je conçois aussi que l'on peut vouloir faire "quelque chose" avant de laisser planter l'application, par exemple, en sauvegardant son dernier état valide (qui correspond peut être à l'état de l'application juste avant que bad_alloc ne soit lancé). Cela ne devrait cependant pas t'empêcher de relancer l'excetpion pour faire en sorte que l'application s'arrête ;)

Ce code, appelé directement depuis le main(), Visual Studio 2013 Pro:

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
#include <climits>
#include <memory>
#include <iostream>
using namespace std;
 
void TestAlloc()
{
	cout << (sizeof(void*)*CHAR_BIT) << " bits." << endl;
	size_t stupid_big_value = 8ull * 1024 * 1024 * 1024 * 65536;
	try
	{
		void* voidptr = ::operator new(stupid_big_value);
		if (voidptr)
		{
			cout << "Allocation successful." << endl;
			::operator delete(voidptr);
		}
		else
			cout << "Operator new returned nullptr instead of throwing." << endl;
	}
	catch (bad_alloc const &)
	{
		cout << "Operator new threw bad_alloc." << endl;
	}
}

Résultat en Debug Win32 et Release Win32 (avec warnings à la compilation parce que ça tronque la taille, qui se retrouve à zéro):

Code:

1
2
32 bits.
Allocation successful.

Résultat en Debug x64 et Release x64:

Code:

1
2
64 bits.
Operator new threw bad_alloc.

08/12/2016, 16h57
jo_link_noir

Le fait qu'il n'y ai pas d'exception pour les grosses allocations vient d'une option kernel (et probablement de la bibliothèque d’allocation sous-jacente).

Sous Linux par exemple, certaines implémentations de malloc refilent toujours un pointeur valide qui réservera la mémoire à la première utilisation. Résultat, l'allocateur ne sais pas que le pointeur est invalide et l'utilisateur va faire planter son application¹ à la première utilisation du pointeur en accédant une zone mémoire qui ne lui ai pas attribué.

¹ Ou une application au hasard avec l'OOM Killer.
14/12/2016, 10h10
camboui

Merci à tous pour vos réponses.

Je ne comprends pas ce qui s'est passé: la semaine dernière aucune exception n'était levée, et maintenant bien...
Que s'est-il passé passé entre les deux ?
Rien... si ce n'est le WE et que tout le monde s'est reposé, y compris mon ordi :zoubi:

Bref, désolé de vous avoir dérangé. Maitenant j'ai bien un bad_alloc.
Mais je risque d'encore me retourner dans mon lit pendant quelques nuits à me demander pq je n'en avais pas...
14/12/2016, 17h15
Astraya

Vu la taille de l'allocation, je pencherais pour une allocation échouant à cause de la fragmentation de la mémoire. Qui varie d'un état à l'autre de la machine, sachant qu'il s'agit d'une allocation contiguë en mémoire.