OBO Le 04/04/2014 à 09:48 ah, le monde vermeilleux de Mozilla...
Haa le monde merveilleur de vo(mi)zilla
Proud to be CAKE©®™
GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.
Windows Phone n'est quand même pas un succès majeur dans les ventes - il a coulé la part de marché de Nokia ^^
En high-end, il y avait d'abord les iPhones, puis la famille Android a pris le gros du marché. En low-end pas cher, il y a plus léger, et Windows Phone n'est pas le seul à vouloir se faire une place au soleil.
En Europe, il se retrouve avec 10% du marché, soit la moitié de l'iPhone. C'est pas mal du tout, je trouve
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)
<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant
Et je pense que Nokia avait coulé avant de se lancer dans Windows Phone, c'est au contraire ce qui leur permet de rebondir maintenant. Il faudrait trouver des courbes pour vérifier ça.
Que cache le pays des Dieux ? -
Forum Ghibli -
Forum LittéraireLa fin d'un monde souillé est venue. L'oiseau blanc plane dans le ciel annonçant le début d'une longue ère de purification. Détachons-nous à jamais de notre vie dans ce monde de souffrance. Ô toi l'oiseau blanc, l'être vêtu de bleu, guide nous vers ce monde de pureté. - Sutra originel dork.
Super cher pour un truc complètement inutile...
Proud to be CAKE©®™
GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.
ouais enfin le mec dit qu'il voit pas comment un read de 64K peut recuperer autant de donnees... mais il suffit d'en faire plein, a des moments differents, qui du coup readent potentiellement des @ differentes, et tu dois pouvoir recuperer un paquet de buffers de 64K avec des bribes de plein de trucs.
et on s'en fout des autres process... si ce code la est linke dans un webserver, c'est l'adress-space du serveur et suivant les implems, il doit avoir les donnees qu'il manipule (pages, fichiers, whatever), mappes en memoire et potentiellement recuperables par cette faille.
et le mec est etonne qu'on recupere autre chose que de la memoire "freshly allocated"... il a vraiment aucune idee de comment fonctionne malloc ou c'est moi? (meme pas que des "modern implementations", justement, des pas modern aussi et surtout)
c'est a voir comme un random probe d'un peu moins de 64K en memoire.
ce qui me surprend le plus c'est que ca ne crashe pas souvent.
avec une granularite de pages de 4K, on doit tres facilement taper dans des pages pas commit, sauf sur des serveurs qui ont deja leur virtual-address space surcharge, et avoir des access violations / segfaults dans le memcpy.
HURRRR !
mais tu controles pas l'adresse! elle est fournie par un malloc!, et la longueur bidouillable est sur 16 bits.
deja, dans le code qui cite c'est l'adresse de destination de la copie qui est allouee par un malloc(), celle que tu recupere, on s'en fout de celle-la.
et pour l'adresse source, admettons que ce soit alloue par un malloc.
justement ! on s'en branle de controler l'adresse...
qu'elle soit allouee par un malloc ou pas.
tu multiplie ca plein de fois et ca te fait comme un sampling-profile de la memoire, a partir du moment ou il y a un volume d'alloc/free suffisant.
hint: malloc implemente par en gros une liste chainee de blocs, sauf si t'utilise des implems de mallocs tres specifiques qui evitent la fragmentation de la memoire virtuelle avec des block-allocators ou autres.
meme en faisant des probes de 64K a quelques millisecondes d'intervalle, jpense que t'as de grandes chances que le ptr alloue par malloc tombe a des endroits tres differents, et en tout cas proche d'autres blocs precedemment alloues et qui contiennent potentiellement des datas "interessantes", qui seront recuperees dans la foulee par le memcpy.
HURRRR !
ben pourquoi pagefault? c'est probablement retourné du milieu de la heap, qui a des pages préallouées pour éviter de sbrk() tout de suite...
)
»