linux - easytag - kid3
entendiendo la salida de pmap (2)
Estaba intentando ver el mapa de memoria de un proceso en Linux x86-64 usando el comando pmap -x . Me confundí mirando la salida del pmap. Particularmente para las entradas para mapear bibliotecas dinámicas. Hay varias entradas para ellos (en realidad 4 para la mayoría de todas, y algunas tienen 3 entradas). A continuación se muestra un ejemplo.
Address Kbytes RSS Dirty Mode Mapping
00000036ca200000 88 64 0 r-x-- libpthread-2.5.so
00000036ca216000 2044 0 0 ----- libpthread-2.5.so
00000036ca415000 4 4 4 r---- libpthread-2.5.so
00000036ca416000 4 4 4 rw--- libpthread-2.5.so
La segunda fila para cada una de las bibliotecas siempre tiene un tamaño de 2 MB, mientras que no tiene permiso de página. En todas las bibliotecas parece que su RSS es SIEMPRE cero. Las dos últimas filas también tienen el mismo tamaño (que es el tamaño de página base) y los mismos permisos (algunas bibliotecas no tienen mapeo rw).
¿Alguien tiene alguna explicación para esto? Tengo la sensación de que, posiblemente, el cargador realiza la asignación con la protección de solo lectura para leer los metadatos de la biblioteca, mientras que la parte con el permiso ejecutable en realidad es el código de la biblioteca. Yo podría, sin embargo, estar equivocado.
Pero no tengo ni idea de esa fila intermedia. ¿Sin permiso y sin usos? ¿Alguien tiene algunas palabras de sabiduría aquí?
También vi unas cuantas páginas que aparecen en la memoria anónima y que no tienen establecido ningún bit de modo. ¿Qué representan estos?
En primer lugar, puede darse el caso de que un mismo proceso pueda usar más de una instancia de uso de memoria. No sé si esto es lo que quieres saber. He visto que, mientras utilizaba un navegador en Linux, con solo una pestaña abierta y usando el comando superior, muestra más de 4 usos en la lista de uso de memoria, cubriendo más de 10 mb de memoria. Creo que está bien debido a la mayor cantidad de subprocesos que se ejecutan por el mismo proceso.
Este enlace puede ser útil, ya que, en el ejemplo de uso en sí, si observa, la asignación del comando -x muestra una mayor cantidad de uso.
http://www.cyberciti.biz/tips/howto-find-memory-used-by-program.html
Estas páginas "----" protegidas son páginas de protección para evitar que los punteros indicen entre el código y los segmentos de datos de la biblioteca. Solo existen en el espacio virtual del proceso y existen para causar un fallo si un puntero pasa el final del segmento.
Si estos no se incluyeran en un archivo de biblioteca compartida, diría que sirven como un búfer para expandir las asignaciones en, por ejemplo, malloc o el crecimiento de la pila. Por ejemplo, glibc solicita grandes porciones de espacio de direcciones del kernel para arenas de asignación de subprocesos locales y luego las consume lentamente para asignaciones de malloc. En un PMAP mucho más grande de una JVM que estoy viendo, hay algunas docenas de ellas, cada una de ellas siguiendo una página RW o completando el espacio entre dos grandes asignaciones de RW y los límites entre ellas cambian a medida que las páginas RW se expanden. En X86_64, las páginas de protección como esta pueden usar el sistema de protección de memoria de la CPU para detectar malas referencias de punteros.