Excepción de desasignación de memoria cuando se usa free ()

Question

Excepción de desasignación de memoria cuando se usa free ()

#1 de Michael Karas (5 votos)

3

Actualmente estoy trabajando en un proyecto que requiere cierta asignación y desasignación de arreglos grandes en un PIC32MX775. Tengo un tamaño de memoria de almacenamiento dinámico dedicado de 1500 bytes, que debería ser más que suficiente y anteriormente he tenido el sistema asignando y desasignando la memoria correctamente cuando utilizo tipos flotantes estándar. Sin embargo, recientemente he introducido un nuevo tipo de variable:

typedef struct{
char index;
float gain;
float freq;   }RM_EQ_SORT_ELEMENT;

Desde que reemplazé tres arreglos separados, he tenido problemas para desasignar la memoria usando la función 'free ()' desde entonces. A continuación se muestra un ejemplo de los arreglos y cómo intento liberarlos:

float* freq = (float*)malloc(NO_OF_FREQS*sizeof(float)); // For the unsorted average frequency
RM_EQ_SORT_ELEMENT* sortArray = (RM_EQ_SORT_ELEMENT*)malloc(NO_OF_FREQS*sizeof(RM_EQ_SORT_ELEMENT));

//**Some more code here that uses the arrays**

if(freq != NULL){
   free(freq);
}

if(sortArray != NULL){
   free(sortArray);
}

Mientras se realiza la depuración, el código saltará al bucle 'excep_bp' que se encuentra en la parte inferior del archivo exceptions.c incluido, cuando el PIC32 llegue a cualquiera de las declaraciones libres anteriores. Si se cambia su orden se produce el mismo resultado.

¿Hay algún problema común que pueda ocurrir al desasignar una memoria como esta con un PIC32? También entiendo que podría ser capaz de depurar este problema más a fondo, cualquier consejo sobre qué hacer en esta situación ayudaría.

pic memory debugging exception pointers

pregunta Thomas Grainge

1 respuesta

Lea otras preguntas en las etiquetas pic memory debugging exception pointers

Salida de reloj pobre desde Spartan6 FPGA Preocupaciones en los tiempos de conmutación del puente H con una línea de control de puerta común (una)

score 5 · Answer 1

Es posible que cuando agregue el nuevo tipo de datos a sus arreglos de datos asignados, su mayor tamaño esté exponiendo un error de apagado en su código. Si por casualidad está accediendo a una matriz por demasiados elementos, es muy probable que esté corrompiendo el (los) encabezado (s) que el administrador del montón pone entre los bloques de MALLOCed. Cuando aparece GRATIS y depende de esta información de encabezado para que sea correcta, toda la naturaleza de las cosas puede ir mal cuando está dañada.

Cuando tenías el tamaño de elemento más pequeño en tus arreglos, es posible que un error lo haya desactivado, pero es posible que los encabezados de MALLOC no se corrompan de manera dañina inmediata.

También hay formas específicas del compilador en las que funcionan las rutinas del administrador del montón. Es posible que en algunos casos el administrador pueda asignar espacio en cierto número mínimo de bloques de tamaño byte. Es simplemente posible que en su caso más simple que parecía funcionar hubiera un espacio de bloque no utilizado en el área de MALLOC que se estaba tragando su tamaño más pequeño por un error sin daño. Cuando vienes con un tamaño de elemento mayor, tal vez el administrador del montón no esté siendo tan amable contigo.

Excepción de desasignación de memoria cuando se usa free ()

Publicaciones recientes del blog

1 respuesta