Limitaciones de tamaño de almacenamiento inusual en VS2003 C++

visual-c++ malloc

Question

Tengo una aplicación C ++ que usa grandes conjuntos de datos, y me he dado cuenta al probar que se está quedando sin memoria, mientras todavía hay mucha memoria disponible. Reduje el código a un caso de prueba de ejemplo de la siguiente manera;

void MemTest()
{
size_t Size = 500*1024*1024; // 512mb
if (Size > _HEAP_MAXREQ)
TRACE("Invalid Size");
void * mem = malloc(Size);
if (mem == NULL)
TRACE("allocation failed");
}

Si creo un nuevo proyecto MFC, incluya esta función y ejecútela desde InitInstance, funciona bien en modo de depuración (memoria asignada como se esperaba), pero falla en el modo de lanzamiento (malloc devuelve NULL). Un solo paso a través de la liberación en los tiempos de ejecución C, mi función se inline obtengo el siguiente

// malloc.c
void * __cdecl _malloc_base (size_t size)
{
void *res = _nh_malloc_base(size, _newmode);
RTCCALLBACK(_RTC_Allocate_hook, (res, size, 0));
return res;
}

Llamar a _nh_malloc_base

void * __cdecl _nh_malloc_base (size_t size, int nhFlag)
{
void * pvReturn;
// validate size
if (size > _HEAP_MAXREQ)
return NULL;
''
''

Y (tamaño> _HEAP_MAXREQ) devuelve verdadero y por lo tanto mi memoria no se asigna. Poner un reloj en el tamaño vuelve con los 512MB exptected, lo que sugiere que el programa está enlazando en una biblioteca de tiempo de ejecución diferente con un _HEAP_MAXREQ mucho más pequeño. Al expandir las carpetas de VC ++ para _HEAP_MAXREQ se muestra el esperado 0xFFFFFFE0, por lo que no puedo entender qué está sucediendo aquí. ¿Alguien sabe de algún cambio CRT o versiones que causarían este problema, o me estoy perdiendo algo mucho más obvio?

Editar: Según lo sugerido por Andreas, al mirar esto debajo de esta vista de ensamblaje se muestra lo siguiente;

--- f:/vs70builds/3077/vc/crtbld/crt/src/malloc.c ------------------------------
_heap_alloc:
0040B0E5 push 0Ch
0040B0E7 push 4280B0h
0040B0EC call __SEH_prolog (40CFF8h)
0040B0F1 mov esi,dword ptr [size]
0040B0F4 cmp dword ptr [___active_heap (434660h)],3
0040B0FB jne $L19917+7 (40B12Bh)
0040B0FD cmp esi,dword ptr [___sbh_threshold (43464Ch)]
0040B103 ja $L19917+7 (40B12Bh)
0040B105 push 4
0040B107 call _lock (40DE73h)
0040B10C pop ecx
0040B10D and dword ptr [ebp-4],0
0040B111 push esi
0040B112 call __sbh_alloc_block (40E736h)
0040B117 pop ecx
0040B118 mov dword ptr [pvReturn],eax
0040B11B or dword ptr [ebp-4],0FFFFFFFFh
0040B11F call $L19916 (40B157h)
$L19917:
0040B124 mov eax,dword ptr [pvReturn]
0040B127 test eax,eax
0040B129 jne $L19917+2Ah (40B14Eh)
0040B12B test esi,esi
0040B12D jne $L19917+0Ch (40B130h)
0040B12F inc esi
0040B130 cmp dword ptr [___active_heap (434660h)],1
0040B137 je $L19917+1Bh (40B13Fh)
0040B139 add esi,0Fh
0040B13C and esi,0FFFFFFF0h
0040B13F push esi
0040B140 push 0
0040B142 push dword ptr [__crtheap (43465Ch)]
0040B148 call dword ptr [__imp__HeapAlloc@12 (425144h)]
0040B14E call __SEH_epilog (40D033h)
0040B153 ret
$L19914:
0040B154 mov esi,dword ptr [ebp+8]
$L19916:
0040B157 push 4
0040B159 call _unlock (40DDBEh)
0040B15E pop ecx
$L19929:
0040B15F ret
_nh_malloc:
0040B160 cmp dword ptr [esp+4],0FFFFFFE0h
0040B165 ja _nh_malloc+29h (40B189h) 

Con los registros de la siguiente manera;

EAX = 009C8AF0 EBX = FFFFFFFF ECX ​​= 009C8A88 EDX = 00747365 ESI = 00430F80 EDI = 00430F80 EIP = 0040B160 ESP = 0013FDF4 EBP = 0013FFC0 EFL = 00000206

Entonces, la comparación parece estar en contra de la constante correcta, es decir, @ 040B160 cmp dword ptr [esp + 4], 0FFFFFFE0h, también esp + 4 = 0013FDF8 = 1F400000 (mis 512mb)

Segunda edición: el problema estaba realmente en HeapAlloc, según la publicación de Andreas. Cambiar a un nuevo montón separado para objetos grandes, usando HeapCreate & HeapAlloc, no ayudó a aliviar el problema, ni intentó usar VirtualAlloc con varios parámetros. Algunos experimentos adicionales han demostrado que cuando la asignación de una gran sección de la memoria contigua falla, dos bloques más pequeños que producen la misma memoria total están bien. por ejemplo, donde falla un malloc de 300MB, 2 mallocs de 150MB funcionan bien. Por lo tanto, parece que necesitaré una nueva clase de matriz que pueda vivir en varios fragmentos de memoria grandes en lugar de un único bloque contiguo. No es un problema importante, pero hubiera esperado un poco más de Win32 en este día y edad.

Última edición: Lo siguiente arrojó 1.875GB de espacio, aunque no contiguo

#define TenMB 1024*1024*10
void SmallerAllocs()
{
size_t Total = 0;
LPVOID p[200];
for (int i = 0; i < 200; i++)
{
p[i] = malloc(TenMB);
if (p[i])
Total += TenMB; else
break;
}
CString Msg;
Msg.Format("Allocated %0.3lfGB",Total/(1024.0*1024.0*1024.0));
AfxMessageBox(Msg,MB_OK);
}

Answer 1

¿Puede ser que el depurador te está jugando un truco en el modo de lanzamiento? Ni el paso único ni los valores de las variables son confiables en el modo de lanzamiento.

Probé tu ejemplo en VS2003 en modo de lanzamiento, y cuando solo paso, al principio parece que el código aterriza en la línea return NULL , pero cuando continúo pisando continúa eventualmente en HeapAlloc , supongo que es esta función la que está fallando , mirando el desmontaje if (size > _HEAP_MAXREQ) revela lo siguiente:

00401078 cmp dword ptr [esp+4],0FFFFFFE0h 

así que no creo que sea un problema con _HEAP_MAXREQ .