Am ehesten sagt das Apple etwas...

Du kannst versuchen einen NMI auszulösen (je nach Modell verschieden), das gibt dann einen forcierten Kernel Panic. Nach dem Neuboot gibts eine Datei panic.log die man dann an Apple schicken kann.

Scheint übrigens alle paar Jahre mal bei jemand vorzukommen (2004): forums.macosxhints.com/archive/index.php/t-27736.html

-- hns

Original von kressevadder
Schon wieder!

Ich werde mich mal mit den pcap Spielereien etwas zurückhalten. Mal sehn ob der Fehler dann auch auftritt.

hmm ich spiel auch mit pcap und hab keine solche einträge. machste was besonderes ?

ich haette jetzt mal ne pcap frage: sniffst du oder liest du die daten aus einem pcap file (ich hab probleme mit files die meinen speicher sprengen ;))

gruss
j.

hmm ja werde sowas probieren demnaechst mal

gruss
j.

hmm also ich sehe das doch richtig, folgende fehlermeldung:

CocoaPacketAnalyzer(11746,0x182c400) malloc: *** vm_allocate(size=1665622016) failed (error code=3)
CocoaPacketAnalyzer(11746,0x182c400) malloc: *** error: can't allocate region
CocoaPacketAnalyzer(11746,0x182c400) malloc: *** set a breakpoint in szone_error to debug

heisst doch dass es ein problem mit dem speicher gibt oder?...komisch ist nur das die app erst 1.5GB RSIZE verbraucht und eigentlich noch nen paar GB Ram frei sind.

gruss
j.

hmm scheint als hat es noch nicht mal was mit der libPCAP zu tun

ich les das pcap file in einem externen thread ein. dort ist noch alles ok. in dem moment wo ich die 450 000 Packets(Dicts in einem Array) wieder in den Haupthread schiebe machts b0000m.....

doofe idee - aber
wenn ich das richtig verstehe will der dort 1.5GB VM anfordern...
kann es möglicherweise sein das die ensprechede platte voll ist? oder grundsätzlich der VM erschöpft ist? gibts eine obergrenze wieviel slices auf platte liegen können?

Original von chartus
doofe idee - aber
wenn ich das richtig verstehe will der dort 1.5GB VM anfordern...
kann es möglicherweise sein das die ensprechede platte voll ist? oder grundsätzlich der VM erschöpft ist? gibts eine obergrenze wieviel slices auf platte liegen können?

sowas dachte ich auch erst aber es ist noch massig real memory und noch mehr massig HD space vorhanden...slices scheinen auch egal zu sein (passiert auch bei frisch gestarteten system).


Ein mutableArray müsste doch locker 450 000 Dicts halten koennen oder ?

Original von kressevadder

Quellcode

1. NSLog (@"Start");
2. int c;
3. NSMutableArray *array = [NSMutableArray array];
4. for ( c=0;c<450000;c++) {
5. NSMutableDictionary *adict = [NSMutableDictionary dictionary];
6. [adict setObject: [[NSProcessInfo processInfo] globallyUniqueString] forKey:@"hurz"];
7. [array addObject:adict];
8. if ( c % 1000 == 0) {NSLog (@"%i", c);}
9. }

ja, geht problemlos. Parst du die pcap files? Da kann man schnell schone Speicherlecks einbauen

yep ich oeffne das file mit pcap_open_offline und mach dann den pcap_loop. ein speicherleck kann ich bei kleinen files (<10000 packets) nicht entdecken....alles autoreleased. läuft alles soweit ok. nur jetzt habe ich eben mal ein grosses file (61MB, 450 000 Packets) und alles geht crazy

bis lang habe ich das parsen immer in einem worker thread (über DO) gemacht. also ein dictionary pro packet. die dicts hatte ich in einem array gesammelt und wenn alle packets da drin sind habe ich den array über den DO-proxy zum haupthread geschickt. dort dann die dicts weiterverarbeitet (array controller und outline view objekte) und in den array controller geladen.

momentan glaub ich dass ich da einfach zu viel overhead erzeuge. immerhin werden die dicts ja ein paar bytes haben (da sind auch header und teilweise payload als nsdata enthalten), über den thread kopiert und dann noch in den array controller...

wenn ich das ganze ohne worker thread mache und alles ziemlich direkt in den array controller lade dann verbraucht die app zwar 1.4GB RAM aber sie schmiert nicht ab. nur 450 000 packets analysieren dauert auch nen bisserl und in der zeit spinning beach ball zu sehen ist auch nicht angenehm....;)

wie kann ich den size in bytes von einem cocoa object erfahren? sizeof() liefert komische werte mit objekten.

so erstmal was futtern dann weiterforschen....bei ideen nur her damit!

gruss
j.

Original von Jens
in dem moment wo ich die 450 000 Packets(Dicts in einem Array) wieder in den Haupthread schiebe machts b0000m.....

Ah, das hört sich danach an, daß es Probleme mit der Verwaltung der VM Speicherseiten im Kernel gibt. Der Kernel muß für alle angeforderten Seiten von allen Prozessen eine Verwaltungsstruktur besitzen. Üblich sind 4kB pro Seite, einzig IBMs POWER4 und alle Nachfolger können auch 16MB Seiten verwalten. Jede der virtuell angeforderten Pages muß entweder im RAM liegen oder auf der Platte vorhanden sein. Die Schwierigkeit dabei ist nun, daß die Verwaltungstruktur im Kernel begrenzt ist. Wenn der Kernel intelligent ist, verwaltet er nacheinander angeforderte Seiten für einen Prozeß möglichst in einer Struktur. Das erfordert einiges an Caching. Leider sieht es so aus, daß MacOS X keine brauchbare Verwaltung der Speicherseiten hat.

Ich wollte die ganze Zeit mal testen, ob man die interne VM Seitenverwaltung in MacOS X durch Userprozesse trashen kann. Dazu muß man es erreichen, daß die Seiten total fragmentieren, d.h. der Kernel die Seiten für die einzelnen Prozesse nicht mehr zusammenhängend verwalten kann. Sollte dies eintreten, dann schmiert das OS in Extremfall ab. Ich bekomme diese Ausgabe, wenn ich versuche 550.000 4k Blöcke (4k == eine Seite) via malloc() zu allozieren. Naja, das Wochenende werde ich mal weiter dran rumbasteln und sehen, was passiert, wenn man erst richtig wild in verschiedenen Prozessen Speicher anfordert und wieder freigibt.
Mit C++ wäre es kein Thema, da gibt es Placement new und das Problem ist aus der Welt. Da kann man dann einen riesen Block für alle Objekte auf einmal anlegen, und die Objekte werden in den bereits allozierten Speicher konstruiert. Ob Objective-C so etwas kann, weiß ich nicht, aber ich habe so meine Zweifel.

Ich habe da keine Zweifel, weil bei Objective-C die Allzierung ohnehin eine Methode des Klassenobjektes ist und -init einen Zeiger zurückgeben darf. Bei zahlreichen Klassen zur Optimierung +alloc/-init überschrieben.

Allerdings weiß ich nicht, ob ich das so lösen würde. Irgendwie finde ich das gefrickelt.

Original von tjp
Ich wollte die ganze Zeit mal testen, ob man die interne VM Seitenverwaltung in MacOS X durch Userprozesse trashen kann. Dazu muß man es erreichen, daß die Seiten total fragmentieren, d.h. der Kernel die Seiten für die einzelnen Prozesse nicht mehr zusammenhängend verwalten kann. Sollte dies eintreten, dann schmiert das OS in Extremfall ab. Ich bekomme diese Ausgabe, wenn ich versuche 550.000 4k Blöcke (4k == eine Seite) via malloc() zu allozieren. Naja, das Wochenende werde ich mal weiter dran rumbasteln und sehen, was passiert, wenn man erst richtig wild in verschiedenen Prozessen Speicher anfordert und wieder freigibt.

Ich glaube nicht daß das gelingt. Lt. felinemenace.org/~nemo/mach/manpages/vm_allocate.html ist vm_allocate ein Mach-Kernel-Call aus dem User-Space heraus.

D.h. Du füllst den User-Virtual-Memory - und der Kernel versucht das auf RAM und Disk abzubilden. Wenn das voll wird, dann wird er schon eine Strategie haben wie er damit umgeht. Er lagert nämlich immer mehr der anderen Prozese aus. Z.B. die Menüzeile, die Status-Uhr, den Window-Server... Aber OSX ist mir deshalb noch nicht gecrasht. Es wird allerdings seeeeeehr lahm. Z.B. dauert es 30 Sek bis die Uhr weiterzählt. Memory Monitor zeigt dann auch erst mal eine schöne ansteigende Speicherbedarfsrampe. Und dann geht das freudige Swappen los (1-2000 In/Outs pro Sekunde).

Und ob die Seiten zusammenhängend im Speicher liegen spielt keine Rolle. Das kann ja die MMU umsortieren.

Und noch eine Limitierung: Dur hast 32bit für Adressen, also 4GByte Adressraum. Der ist nicht vollständig verfgbar, sondern nur ca. 2GB. Ein Teil ist TEXT (d.h. Programmcode), ein Teil ist DATA (d.h. die Variablen und der malloc-Heap). Und ein Teil ist Stack.

Was ich zum diskutierten Problem eher glaube ist ein unerkannter 32-Bit-Overflow und dass signed/unsigned durcheinandergerät.

-- hns

Original von Jens
komisch ist nur das die app erst 1.5GB RSIZE verbraucht und eigentlich noch nen paar GB Ram frei sind.

Nee, das ist eigentlich nicht komisch. OS X (zumindest bis 10.4) kann soweit ich weiß eh nur 2GB Data-Space verwalten, also 31 bit. Egal wieviel RAM drin ist. Mehr RAM heißt nur, daß mehrere Prozesse gleichzeitig im RAM liegen können ohne das geswappt wird.

Wie vorhin geschrieben: ein Teil der 4GByte Adressraum sind Programmcode (incl. Dynamic Libraries), ein Teil ist Stack und nur der Rest kann per malloc() belegt werden. Und der ist vielleicht mit 1,5GB RSIZE schon voll.

Zugriff auf Dateien > 2 GByte braucht eine völlig andere Strategie.

-- hns

Ok, die Doku sagt, man kann NSMutableDictionary die Speichergröße vorher mitteilen. Das sollte er einmal ausprobieren, da alle Objekte von NSProcessInfo die Daten sich teilen, es könnte sein daß dies ausreichend ist. Wenn es andere Daten wären müßte er dieser aber in einem von Hand verwaltetem Speicherblock reinpacken. Wie siehst's mit den Keys aus? Muß man die in einen eigenen Speicherblock werfen?

Das stellt sich dann eine Frage: Wie bekomme ich die exakte Größe eines Objekts für das notwendige
heraus?

Ob das nun Gefrickel ist oder nicht, es ist der einzig gangbare Weg, solange Apple den Kernel nicht ändert.