Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum>Software>Mac OS X mit Problemen bei realloc()

Mac OS X mit Problemen bei realloc()

sagrada
sagrada02.05.0602:33
Tja, was sagt man dazu:
Ich gebe das mal zur Diskussion frei!
0

Kommentare

Stefan Lühr
Stefan Lühr02.05.0604:11
RAM ist doch billig

mfg

Stefan
0
Rantanplan
Rantanplan02.05.0605:29
LOL, was'n das für ne abgefuckte Type Bild von hier:

Der verlinkte Source für realloc tut tatsächlich nix in dem Fall. Muß man aber mal näher untersuchen, was das in der Realität bedeutet.

(Bild von Admin entfernt)
„Wenn ich nicht hier bin, bin ich auf dem Sonnendeck“
0
Dieter02.05.0609:06
Nun ja, das ist nicht Einzigartig bei Mac OS X. Ich vermute, dass man sich die System-Calls spart und den großen Block in einen Pool einhängt und weitere Speicheranforderungen mit einer internen Aufteilung des freigegeben Block befriedigt. (System-Calls werden im Vergleich zu ein bisschen Verwaltung in Libs als "teuer" angesehen).

Mal probieren:
- 100MB alloc
- realloc 10kB
- 90x1MB alloc
Steigt der Speicherbedarf? Ich kann es erst heute Abend mal testen ...
0
Dieter02.05.0609:46
Erster Code-Review sagt mir, dass da wirklich nichts passiert, auch meine Hypothese trifft es wohl nicht.
Ich würde sagen da hat jemand geschlampt. Zwar ist der vergrößernde ReAlloc IMHO häufiger anzutreffen (mit abschließenden free), als der verkleinernde, aber es ist auch abhängig vom Einsatzzweck. @@:apple: Sollte man mal nachbessern.
0
sagrada
sagrada02.05.0613:18
Stefan Lühr:
Sicherlich ist RAM nicht mehr so teuer wie früher, aber wenn dir das egal ist, dass dir hunderte von MB eventuell flöten gehen finde ich das sehr merkwürdig.

Rantanplan:
Wo hast du das Bild her und was hat es mit dem Topic zu tun?

Dieter:
Denke auch, dass das unbedingt beseitigt werden muss. Ist nur die Frage, wie man Apple das klar macht?
0
Rantanplan
Rantanplan02.05.0615:00
sagrada

Wo ich das Bild her habe? Meine Güte, schon mal was von Google gehört? Das ist der Schreiber des recht eigenartig formulierten Textes, auf den du verlinkt hast. Was das mit dem Thema zu tun hat? Wenn ich so eine Schreibe lese, dann möchte ich schon gerne wissen, wer sich so schlecht ausdrückt. Und dann stieß ich auf den Urheber im Bild. Naja, ich beurteile Sinn- und Glaubhaftigkeit von Aussagen halt auch auf Grund meiner Einschätzung des Autors. Nenne es Vorurteil, mir ist das wurscht wie du das nennst. Ich nenne es Menschenkenntnis.

Dieter

Sehe ich auch so. Sieht nach "ich bin zu faul einen seltenen Fall zu implementieren" aus, der dann "vergessen" wurde. Der von diesem Felix heraufbeschworene Fall mit 100 MB alloc und dann realloc auf 10 kB dürfte in der Realität sowieso nie vorkommen. Trotzdem. In der Summe macht auch Kleinvieh Mist und gerade bei Apps die lange laufen oder im Hintergrund ständig laufen, liefe in so einem Szenario langsam der virtuelle Speicher zu.
„Wenn ich nicht hier bin, bin ich auf dem Sonnendeck“
0
sagrada
sagrada02.05.0615:38
Rantanplan:
Du brauchst dich nicht rechtfertigen. Ich kenne den Autor bloß nicht und war etwas verwundert, warum du auf einmal bei diesem Thema ein Bild postest. Nichts für ungut.
Ich glaube auch nicht alles, was irgendwelche Menschen in ihren Blogs veröffentlichen. Der Link aus seinem Blogeintrag war jedoch überzeugend genug.
0
Rantanplan
Rantanplan02.05.0619:23
Also, ich habe das mal mit einem Testprogrämmchen durchgespielt. Das führt die für diesen Testfall nötigen Schritte aus:

1. es alloziert 100 MB

2. es füllt den Block zur Hälfte mit Daten

3. es realloziert diesen Block auf 10 kByte

4. es gibt den reallozierten Block frei

Vor Schritt 1 und nach jedem weiteren Schritt lasse ich mir den Status per ps ausgeben.

Erstmal ganz allgemein: was passiert da überhaupt? Nach dem Programmstart belegt das Programm sehr wenig Speicher, logischerweise. Das sieht man dann in der ersten Ausgabe von ps. Nach dem Allozieren der 100 MB sieht man zwei Dinge: a) da Programm belegt nur minimal mehr physikalischen Speicher, aber b) es hat sich 100 MB Adressraum (virtuellen Speicher) gekrallt.

Nochmal für Nicht-Softwareentwickler: Speicher anfordern bedeutet nicht, daß physikalischer Speicher belegt wird, es handelt sich nur um einen Adressraum (+ggf. Platz im Swap-File). Erst wenn Daten in diesen Bereich geschrieben werden, wird physikalisches RAM belegt. Das ist ein großer Unterschied.

Im Schritt zwei wird nun die Hälfte der 100 MB mit Daten vollgeschrieben. Erst jetzt schwitzt die CPU (siehe ps-Ausgabe) und es dauert auch eine Weile (Anmerkung: erstaunlich lang für den schnellen iMac), danach sind 50 MB reales RAM belegt und weiterhin natürlich 100 MB virtueller Speicher.

Das was der Herr aus dem verlinkten Blog-Beitrag in etwas primitiver Alltagssprache versuchte auszudrücken kommt nun in Schritt 3: der zuvor angeforderte Block von 100 MB soll verkleinert werden - dafür gibt es eine Standardfunktion - auf 10 kB. Das im Blog beschriebene Ereignis ist aber: der Block wird nicht geschrumpft. Er belegt nach wie vor 100 MB, obwohl ich davon nur noch 10 kB benutzen darf (weil ich ihn offiziell auf diese Größe geschrumpft habe). Darüber mokiert sich der Herr Felix nun. Über die Auswirkungen dieses Verhaltens schreibe ich später noch was, sofern mir die Zeit nicht ausgeht

Ok, noch schnell den letzten Schritt: der Speicher wird freigegeben, zu erwarten ist, daß sich das auch in der Ausgabe von ps niederschlägt (was es tut).

Da beim Einfügen als Text die Ausrichtung in Spalten nicht erhalten bleibt, füge ich die Ergebnisse mal als Bilder ein. Zuerst das - nach dem Duchsehen der Darwin-Source das zu erwartende - Ergebnis für OS X 10.4.6:
„Wenn ich nicht hier bin, bin ich auf dem Sonnendeck“
0
Rantanplan
Rantanplan02.05.0619:35
RSS ist der physikalisch belegte Speicher, VSZ ist der belegte virtuelle Speicher. Beide Angaben in kByte. Die Leerzeilen kommen daher, weil ich zwischendurch auf eine Eingabe warte, um auch "von außen" mal kucken kann, was das Programm tut.

Erste Ausgabe: vor Schritt 1, es belegt 36 M virtuellen Speicher und 740 k physischen Speicher.

Zweite Ausgabe: nach Schritt 1, also 100 M wurden alloziert. Sieht man auch schön am virtuellen Speicher, der physische ändert sich kaum.

Dritte Ausgabe: Speicher wird zur Hälfte gefüllt. Jetzt sieht man, daß die CPU-Last (als ps ausgeführt wurde) bei über 40% lag und auch über 50 M physischer Speicher belegt sind.

Vierte Ausgabe: jetzt wird es interessant, jetzt wurde der Block auf 10 k verkleinert. Wie man sieht: keine Änderung am belegten Speicher, physisch und virtuell.

Fünfte Ausgabe: nach dem Freigeben des Speichers, der Speicherbedarf ist wieder (fast) auf die Anfangswerte zurückgeschrumpft.

--------------------------

Jetzt was Witziges. Beziehungsweise dem Herrn Felix würde das in seinem blinden OSX-Hass nicht in den Kram passen Ich habe das gleiche Progrämmchen mal unter FreeBSD 4.8 laufen lassen, einfach aus Interesse. Der Witz ist, daß sich FreeBSD genauso verhält Wobei die 4er-Linie ja nicht mehr die taufrischeste ist, vielleicht hat sich das in der 5er geändert, aber ich denke mal, daß nicht, weil OS X auf der 5er basiert.

Hier die Ausgabe von FreeBSD 4.8, wobei man die letzte Zeile auch nicht überbewerten sollte (Felix würde es sicher), denn dort sieht man, daß nach dem Freigeben des Speichers der aber immer noch belegt wird. Ich würde mal behaupten: da würde das ps einfach zu schnell geforkt

PS: nicht über die unterschiedlichen Namen wundern, ich habs einfach beim Kopieren auf den FreeBSD-Rechner anders genannt

PPS: ich werd mir das später auf einem Linux-Rechner mal ankucken
„Wenn ich nicht hier bin, bin ich auf dem Sonnendeck“
0
Rantanplan
Rantanplan02.05.0620:33
So, auf einem SuSE 9.3 konnte ich es noch ausprobieren, da funktioniert das Reallozieren wie man naiverweise erwarten würde, siehe anhängende Ausgabe.

PS: da ich auf dem virtuellen Server keine 100 MB allozieren kann, sind es hier nur 1 MB die zu 10 kB verkleinert werden.
„Wenn ich nicht hier bin, bin ich auf dem Sonnendeck“
0
MacMark
MacMark02.05.0620:42
Es wird de facto 50 MB Speicher an Daten belegt. Ein Reallozieren soll dann dem Programm die Daten aus dem Speicher werfen? Da würde das Programm wohl abstürzen.
Als es keine Daten in dem Umfang mehr benötigt, gibt es allen Speicher ab bis zur geforderten Grenze.

Schlagt mich tot, aber jedes andere Verhalten macht doch keinen Sinn.
„@macmark_de“
0
Stefan Lühr
Stefan Lühr02.05.0621:00
Endlich mal einer, der sich damit auskennt

Habe ich das richtig verstanden, dass der Fehler bei BSD 4 auftaucht?

mfg

Stefan
0
Rantanplan
Rantanplan02.05.0621:10
MacMark
Als es keine Daten in dem Umfang mehr benötigt, gibt es allen Speicher ab bis zur geforderten Grenze.

Schlagt mich tot, aber jedes andere Verhalten macht doch keinen Sinn.

Naja, so sollte es ja sein, aber es gibt halt nix frei bis zur (neuen) geforderten Grenze.

Der Fall den der Herr Felix da konstruiert ist natürlich ziemlich an den Haaren herbeigezogen. Außerdem inhaltlich falsch, weil ein malloc() ohne Schreiben von Daten keinen physischen Speicher belegt, sondern nur nen Adressraum. Trotzdem schon ein wenig hemdsärmelig, beim Verkleinern einfach garnix zu tun.

Ich wollte vorhin mal kucken, wie das im aktuellen FreeBSD gelöst ist, aber so durch einfaches Durchlesen des entsprechenden Sources bin ich nicht drauf gekommen. Die verwenden eine Speicherverwaltung, in der jeweils größere Blöcke fester Abstufung verwendet werden. Den Source vom 4.8er habe ich mir jetzt nicht reingezogen, aber zumindest liefert das Testprogramm ein vergleichbares Verhalten zu OS X.

Deswegen meine vorsichtige Einschätzung: dieses Verhalten hat OS X von FreeBSD geerbt.
„Wenn ich nicht hier bin, bin ich auf dem Sonnendeck“
0
Rantanplan
Rantanplan02.05.0621:11
Stefan Lühr
Habe ich das richtig verstanden, dass der Fehler bei BSD 4 auftaucht?

Das Testprogramm zeigt mit FreeBSD 4.8 das gleiche Verhalten, ja.

Falls es jemanden interessiert paste ich das Testprogramm mal hier rein, vielleicht habe ich auch einen Denkfehler drin
„Wenn ich nicht hier bin, bin ich auf dem Sonnendeck“
0
Rantanplan
Rantanplan02.05.0621:24
Wobei ich aus dem Source des 4.8er FreeBSD (libc stdlib malloc.c) auch nicht so recht schlau werde.
„Wenn ich nicht hier bin, bin ich auf dem Sonnendeck“
0
Dieter02.05.0623:34
Hat jemand schon folgendes Szenario probiert?

- 100MB alloc
- realloc 10kB
- 9x10MB alloc

So wie der Code aussieht wird der freigegebene Teil nicht als Pool für "kleinere" Speicheranforderungen genutzt, sondern am Ende sollte ich 190MB verbraucht haben... Recht unglückliche Implementierung!
0
Rantanplan
Rantanplan02.05.0623:41
Dieter

Gerade ausprobiert: der weitere alloc(), der eigentlich in den freigewordenen Teil paßt bläht dann entsprechend den virtuellen Speicherbedarf weiter auf.
„Wenn ich nicht hier bin, bin ich auf dem Sonnendeck“
0
Rantanplan
Rantanplan02.05.0623:47
Trotzdem, mich würde mal unabhängig davon, ob realloc() nun Mist baut oder woher das nun stammt, was anderes interessieren. Ich verdiene seit 15 Jahren meine Brötchen mit Softwareentwicklung. Und zwar auch recht hardwarenah und "low levelig" genug um malloc() und Konsorten häufig genutzt zu haben. Und ich kann mit Bestimmtheit sagen, daß ich realloc() noch nie verwendet habe, weil ich noch nie in meinen Projekten einen Bedarf dafür hatte. Mal abgesehen davon, daß 100 MB zu allozieren und das dann auf wenige Kilo zu shrinken auch nur einem blutigen Anfänger einfallen könnte. Seit OO-Zeiten könnte ich mir überhaupt nicht vorstellen, wozu ich einen realloc() bräuchte, das kommt - meine Ansicht - da in der Praxis überhaupt nicht vor.

Wie siehts denn bei euch Kollegen aus? realloc() schon mal verwendet bzw. Bedarf dafür gehabt?
„Wenn ich nicht hier bin, bin ich auf dem Sonnendeck“
0
Dieter03.05.0600:03
Ja, aber eher zum wachsen lassen von dynamischen Bereichen, deren Größe nicht vorhersagbar ist. Wenn alles verarbeitet, dann alles auf einmal freigeben. Verkleinerndes realloc() habe ich glaube ich seit Studienzeiten nicht mehr gemacht, zumindest kann ich mich nicht erinnern...
0
MacMark
MacMark03.05.0601:23
Außerdem ist von "enlarge" (vergrößern) die Rede. Über Verkleinern steht da nichts.
Und "tries" deutet wohl auf Bedingungen hin, unter denen es nur funktioniert, sprich "nicht immer". Das hatte ich oben schon angedeutet.
„@macmark_de“
0
Rantanplan
Rantanplan03.05.0602:12
seaside
Und bitte kommt mir nicht mit der Aussage, dass das Photo auf irgendeiner Site zu finden war.

Mach dir nicht ins Hemd, das Bild ist offizieller Teil eines Kongressberichtes, siehe hier: Zu wem es gehört ist auch ersichtlich, schließlich steht das Impressum in dem Link ganz ganz oben.
„Wenn ich nicht hier bin, bin ich auf dem Sonnendeck“
0
Rantanplan
Rantanplan03.05.0602:16
seaside
Dieses 'tries to...' liest sich etwas merkwürdig, oder? Ach, weiss auch nicht, zu spät...

Nö, das ist nicht komisch sondern normal. Egal welche Speicherverwaltungsstrategie man verwendet, aber immer liegen irgendwelche allozierten Blöcke hintereinander. Einfach mal zwischendrin einen größer machen geht halt nicht immer (wohl eher selten, außer intern sind die Blöcke sowieso größer). Deswegen liefert realloc() auch einen Pointer zurück, denn es ist nicht garantiert (deswegen "tries to"), daß der Block vergrößert werden konnte. Falls das nicht möglich ist, wird ein neuer Block der gewünschten Größe alloziert, der alte Inhalt dort rein kopiert und der neue Pointer zurückgeliefert. Verkleinern ist immer "in place" möglich und eigentlich gehts auch nur um das Verhalten von realloc() unter OS X in diesem Fall.
„Wenn ich nicht hier bin, bin ich auf dem Sonnendeck“
0
seaside03.05.0600:38
Rantanplan<br>
Der verlinkte Source für realloc tut tatsächlich nix in dem Fall. Muß man aber mal näher untersuchen, was das in der Realität bedeutet.

Na sagt mal! Von Persönlichkeitsrechten von Menschen - mal abgesehen von Copyright - habt Ihr auch noch nix gehört, oder?

Denkt mal drüber nach, wie IHR reagieren würdet, wenn jemand EURR Fotos irgendwo postet. Und bitte kommt mir nicht mit der Aussage, dass das Photo auf irgendeiner Site zu finden war.

MTN Bitte löscht das Bild umgehend!
0
seaside03.05.0600:45
Die Doku von realloc sagt:

>>>
The realloc() function tries to change the size of the allocation pointed
to by ptr to size, and return ptr. If there is not enough room to
enlarge the memory allocation pointed to by ptr, realloc() creates a new
allocation, copies as much of the old data pointed to by ptr as will fit
to the new allocation, frees the old allocation, and returns a pointer to
the allocated memory. realloc() returns a NULL pointer if there is an
error, and the allocation pointed to by ptr is still valid.
<<<

Dieses 'tries to...' liest sich etwas merkwürdig, oder? Ach, weiss auch nicht, zu spät...
0

Kommentieren

Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.