OVH Cloud OVH Cloud

[HS] Question système

7 réponses
Avatar
Baptiste Mathus
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigA97B4EC9B27243FF723CC6C3
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Salut à tous,

Je fais un petit programme censé tester un point précis de la gestion de la
mémoire sous Linux. J'essaie de déclencher des segfault en écrivant ds la
mémoire octet par octet à partir d'un endroit que j'ai alloué.

Comme il me semble qu'une page fait généralement 4ko sous mon os préféré. Le
nombre d'octets au bout duquel j'obtiens une segfault ne devrait jamais dépasser
4096, non ? (voire 8192 avec des pages de 8ko).

Or le nombre est bcp plus gd que ça : 137400. Soit j'ai fait une connerie ds les
15 lignes que j'ai écrites (honte sur moi) soit je comprends plus...

**********************
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>

#define ALLOC_SIZE 10

int j;

void catch_segfault(int num)
{
printf("segfault attrapée : j = %d\n",j);
exit(0);
}
int main(void)
{
int i;
signal(SIGSEGV,catch_segfault);

char *t= (char*) malloc(ALLOC_SIZE*sizeof(char));
j=0;
while(1)
{
t[j]='\0';
j++;
}

return 0;
}
**********************

Y a-t-il un moyen de connaitre la taille des pages que le noyau en cours
d'utilisation va utiliser ? (quelque part dans /proc j'imagine).

D'avance merci.
--
Baptiste <Batmat> Mathus
Baptiste at Mathus point org
http://www.batmat.net
OpenPGP : 0xE8EC628F
---------
Si chacun de nous a une idée et que nous les partageons, nous repartirons
tous les deux avec deux idées... C'est ça le Libre.

--------------enigA97B4EC9B27243FF723CC6C3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBvL40NdWOPujsYo8RAvUxAJ478Gd18g1kUd6MJEHiVLDdx3WJswCbBC5F
mxdU5rb8scI8IeOSweP+dPM=
=dW1j
-----END PGP SIGNATURE-----

--------------enigA97B4EC9B27243FF723CC6C3--


--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

7 réponses

Avatar
Francois Cerbelle
--LZvS9be/3tNcYl/X
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Le Sun, Dec 12, 2004 at 10:54:57PM +0100, Baptiste Mathus ecrit :
Salut à tous,
Je fais un petit programme censé tester un point précis de la
gestion de la mémoire sous Linux. J'essaie de déclencher des
segfault en écrivant ds la mémoire octet par octet à partir d'un
endroit que j'ai alloué.
Comme il me semble qu'une page fait généralement 4ko sous mon os
préféré. Le nombre d'octets au bout duquel j'obtiens une segfault
ne devrait jamais dépasser 4096, non ? (voire 8192 avec des pages de
8ko).
Or le nombre est bcp plus gd que ça : 137400. Soit j'ai fait une
connerie ds les 15 lignes que j'ai écrites (honte sur moi) soit je
comprends plus...


[...]
Y a-t-il un moyen de connaitre la taille des pages que le noyau en
cours d'utilisation va utiliser ? (quelque part dans /proc
j'imagine).


---end quoted text / fin de citation---

Salut,
Je n'ai pas de réponse à ta question, juste le résultat de ton
programme sur mon systeme :
:~$ ./test
segfault attrapée : j = 135160

Ce qui confirme tes résultats sur un noyau
Linux oceane 2.6.8-1-k7 #1 Thu Oct 7 02:47:47 EDT 2004 i686 GNU/Linux
dans une installation Debian. Je n'ai pas le courage de redémarrer sur
mon LFS en 2.6.8 aussi, mais je suppose que, même avec un noyau pur,
le résultat sera le même.

A+
Fanfan
--
Soyons reconnaissants aux personnes qui nous donnent du bonheur ;
elles sont les charmants jardiniers par qui nos âmes sont fleuries.
[Marcel Proust]

--LZvS9be/3tNcYl/X
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBvM0Vn0FdfiSfsswRAlw4AKCWtx6joTZ+uo7InH7PiOSsMxC+FgCeMvEB
SSO9yWZvcmAD8YX7eXGelRU =MxOi
-----END PGP SIGNATURE-----

--LZvS9be/3tNcYl/X--


--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Avatar
Jean-Charles Salzeber
--xHFwDpU9dbj6ez1V
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Dans sa prose du dimanche 12 décembre de l'an de grâce 2004 à 22h54, Baptiste Mathus s'exprimait ainsi:
Salut à tous,

Je fais un petit programme censé tester un point précis de la gestion de
la mémoire sous Linux. J'essaie de déclencher des segfault en écriv ant
ds la mémoire octet par octet à partir d'un endroit que j'ai alloué.

Comme il me semble qu'une page fait généralement 4ko sous mon os
préféré. Le nombre d'octets au bout duquel j'obtiens une segfault n e
devrait jamais dépasser 4096, non ? (voire 8192 avec des pages de 8ko).

Or le nombre est bcp plus gd que ça : 137400. Soit j'ai fait une conner ie
ds les 15 lignes que j'ai écrites (honte sur moi) soit je comprends plu s...



Je confirme (plus ou moins)
- sous Linux:
$ ./segfault
segfault attrapée : j = 135160

- sous OpenBSD;
$ ./segfault
segfault attrapée : j = 4048

Donc linux a alloué 33 pages (avec un entête de 8 octets)
OpenBSD a alloué 1 page (avec entête de 48 octets)

Je suppose que Linux "optimise" les requêtes en fonction de la mémoire
disponible et de la gourmandise de l'application (reste à vérifier)
Celà se passe ou au niveau du noyau, ou au niveau de la libc.

JC

--xHFwDpU9dbj6ez1V
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBvN6RxufF3OoTgFwRAl+HAKCLtO4Bq7qHiQyGCpxhLtpvY8TLmgCdFmPQ
g/cuazS0Uv202pCSOs7DdFA =sBfS
-----END PGP SIGNATURE-----

--xHFwDpU9dbj6ez1V--


--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Avatar
Baptiste Mathus
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigB7E448B9877979DA48744FBC
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit



Francois Cerbelle a écrit :
Le Sun, Dec 12, 2004 at 10:54:57PM +0100, Baptiste Mathus ecrit :

Salut à tous,
Je fais un petit programme censé tester un point précis de la
gestion de la mémoire sous Linux. J'essaie de déclencher des
segfault en écrivant ds la mémoire octet par octet à partir d'un
endroit que j'ai alloué.
Comme il me semble qu'une page fait généralement 4ko sous mon os
préféré. Le nombre d'octets au bout duquel j'obtiens une segfault
ne devrait jamais dépasser 4096, non ? (voire 8192 avec des pages de
8ko).
Or le nombre est bcp plus gd que ça : 137400. Soit j'ai fait une
connerie ds les 15 lignes que j'ai écrites (honte sur moi) soit je
comprends plus...



[...]

Y a-t-il un moyen de connaitre la taille des pages que le noyau en
cours d'utilisation va utiliser ? (quelque part dans /proc
j'imagine).



---end quoted text / fin de citation---

Salut,
Je n'ai pas de réponse à ta question, juste le résultat de ton
programme sur mon systeme :
:~$ ./test
segfault attrapée : j = 135160

Ce qui confirme tes résultats sur un noyau
Linux oceane 2.6.8-1-k7 #1 Thu Oct 7 02:47:47 EDT 2004 i686 GNU/Linux
dans une installation Debian. Je n'ai pas le courage de redémarrer sur
mon LFS en 2.6.8 aussi, mais je suppose que, même avec un noyau pur,
le résultat sera le même.


Merci.
Bon, alors j'ai vraiment pas compris la gestion de la mémoire alors...
Par contre, je me suis pas trompé :

#include <stdio.h>
#include <unistd.h>
int main(void)
{
int page_size = getpagesize();
printf("Taille d'une page du système = %dn", page_size);
return 0;
}

ça affiche bien 4096... Alors franchement, les quelques 135000 octets avant
d'avoir une erreur me laissent perplexe :/

@++

--
Baptiste <Batmat> Mathus
Baptiste at Mathus point org
http://www.batmat.net
OpenPGP : 0xE8EC628F
---------
Si chacun de nous a une idée et que nous les partageons, nous repartirons
tous les deux avec deux idées... C'est ça le Libre.

--------------enigB7E448B9877979DA48744FBC
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBvN7uNdWOPujsYo8RAiNZAJ9oQ90FFEyQrfkAvv98w2tqJLsVVwCglkJp
J1aWb/NxPcFuvwhZ1RgLe+8 =9v4R
-----END PGP SIGNATURE-----

--------------enigB7E448B9877979DA48744FBC--


--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Avatar
Yves Rutschle
On Sun, Dec 12, 2004 at 10:54:57PM +0100, Baptiste Mathus wrote:
Je fais un petit programme censé tester un point précis de la gestion de la
mémoire sous Linux. J'essaie de déclencher des segfault en écrivant ds la
mémoire octet par octet à partir d'un endroit que j'ai alloué.



Si tu veux regarder ce que fait le noyau, il vaut mieux
utiliser directement les appels systèmes (section 2 du
manuel): malloc est une fonction de la libc, et tu ne sais
pas ce que la libc fait. L'autre chose à regarder est bien
entendu les sources.

Comme il me semble qu'une page fait généralement 4ko sous mon os préféré.



Ça dépend en fait de l'architecture, c'est 4Ko en i386
effectivement.

Y a-t-il un moyen de connaitre la taille des pages que le noyau en cours
d'utilisation va utiliser ? (quelque part dans /proc j'imagine).



Dans les sources, au début de include/asm/page.h. Dans
/proc, je ne sais pas.

En compilant ton programme avec uclibc, on trouve ce à quoi
tu t'attends. Donc, glibc bien fait des choses dans ton dos:

:~$ i386-uclibc-linux-gcc -o try try.c
:~$ ./try
segfault attrapée : j = 4088

Je suppose que glibc pense que c'est malin de pré-attribuer
plein de mémoire vue que Linux ne l'attribue pas tant
qu'elle n'est pas utilisée (ça économise des appels
systèmes).

Y.


--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Avatar
Francois Cerbelle
--t0UkRYy7tHLRMCai
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Le Mon, Dec 13, 2004 at 01:13:05AM +0100, Jean-Charles Salzeber ecrit :
Je suppose que Linux "optimise" les requêtes en fonction de la mémoire
disponible et de la gourmandise de l'application (reste à vérifier)
Celà se passe ou au niveau du noyau, ou au niveau de la libc.


---end quoted text / fin de citation---

J'ai pas le temps aujourd'hui, mais "strace" pourrait peut-etre lever
le doute sur le responsable de ce comportement etrange.

Fanfan
--
- Le pastis se trouble quand on le mouille. Les filles, c'est
l'inverse...
[Dicton Breton]

--t0UkRYy7tHLRMCai
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBvWZIn0FdfiSfsswRAi6vAKDDJ+8AkRDM5Wfxl6CNqiQ3QvL0WACglfUO
y+FCOHx3jjMnF51dEGdc4nY =QFIN
-----END PGP SIGNATURE-----

--t0UkRYy7tHLRMCai--


--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Avatar
Stephane Bortzmeyer
On Mon, Dec 13, 2004 at 01:14:35AM +0100,
Baptiste Mathus wrote
a message of 94 lines which said:

ça affiche bien 4096... Alors franchement, les quelques 135000
octets avant d'avoir une erreur me laissent perplexe :/



L'appel système d'allocation de mémoire se nomme brk(2). malloc(3) est
un sous-programme qui tourne en mode utilisateur pour rendre plus
conviviale l'allocation mémoire. Il demande en général bien plus de
mémoire que ce qu'a réclamé le programmeur, pour la distribuer ensuite
à loisir (alors que brk, de plus bas niveau, alloue exactement ce qui
est demandé).

Le comportement que vous observez est donc parfaitement normal.

Cf. les sources de la GNU libc, répertoire "malloc/" ou bien
http://www.malloc.de/en/index.html.





--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Avatar
Thomas Pimmel
Salut,

Le dimanche 12 Décembre 2004 22:54, Baptiste Mathus a écrit :

Or le nombre est bcp plus gd que ça : 137400. Soit j'ai fait une connerie
ds les 15 lignes que j'ai écrites (honte sur moi) soit je comprends plus...



Non, pas d'erreurs à priori. Mais il me semblerait logique que les segments
non-réservés ne fassent pas l'objet d'un traitement de la mmu. Tant que ton
programme ne tape pas dans de la mémoire allouée par un autre prog, pas de
raison d'avoir une interruption... non ? (Je dis ça, mais bon...)

Autre test à effectuer : prévois une boucle de delai de trente secondes entre
l'allocation et le remplissage. Pendant ce temps, lance d'autres applications
gourmandes (genre gimp) et regarde ce que ça fait.

A+, Tom
--
Thomas Pimmel
email :
http : http://tom.ringard.org


--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact