*nix Programme ansprechen?

  • Original von James
    Nö, ich meine schon -[NSString UTF8String] ;)

    Es geht doch darum die C-String Repräsentation eines NSString Objektes abzufragen?



    Ich habe ein NSString und brauche davon ei C-String um es der zlib zu übergeben. Habe es grad mit UTF8String probiert da gabs dann wieder Probleme mit falschen typen, werde ich mir später genauer angucken. Das andere Problem hat eine höhere Priorität. ;)


    Ruf mal innerhalb ObjectAlloc den "About-Requester" auf - da steht drin, was die einzelnen Farben zu bedeuten haben.

    Generell gilt - der Balken ist nur eine graphische Repräsentation des Zahlenwertes daneben und der steht - solange nicht "Count are Bytes" angewählt ist, die Summe der Instanzen und Retains des jeweiligen Objektes. Wenn Du da eines stehen hast, das wider Erwartens nicht mehr herunterzählt, dann solltest Du mal nachsehen, ob ein release fehlt. Es sei denn das Objekt wird von einem ARP geführt. Dann erfolgt die Freigabe der zugehörigen Objekte erst beim nächsten release dieses ARP's

    Dei Mark-Funktion ist auch ganz nütlich. Die kann man gut gebrauchen, wenn mal man den Zuwachs - also das Delta sehen will - z.B. wie der Objektallozierungstatus ist, wenn sich ein Programm mal "beruhigt" - sich also grundinitialisiert hat. Marke setzen und danach mal was machen - Buttons klicken etc.

    Spiele einfach mit herum. ich finde dass ObjectAlloc ein sehr wichtiges und auch nützliches Werkzeug ist, um Memoryleaks auf die Schliche zu kommen.

    Auch kann man dort gleich sehen, ob es manchmal nicht besser ist selbst einen ARP anzulegen und die Verwaltung der Instanzen nicht dem default ARP aufzubürden. ;)


    Ok so richtig verstehen tue ich das Programm noch nicht, aber ein String ist ziemlich stark gewachsen den habe ich mir im Instance Browser angeguckt. Da stehen dann alle möglichen Strings drin die ich mal irgendwo benutzt habe. Das meiste gehört zu der Status Anzeige, gehe ich von Current auf Total steht dort auchüberall wo es sein sollte freed Object.
    Habe obwohl ich nicht an einen erfolg geglaubt habe die 2 Zeilen rausgenommen

    Quellcode

    1. [statustextTF setStringValue:[NSString stringWithFormat:@"Checking Rom \"%@\"", [romFolderContents objectAtIndex:i]]];
    2. [statustextTF display];

    Was mich jetzt erstaunt ist dass er erst beim 253. durchlauf meinte nicht mehr kopieren zu können.

  • Da es ObjectAlloc ist, kannst Du nur sehen wieviele Objekte von einer Bestimmten Klasse erzeugt werden, und wieviele davon zu gewissen Zeitpunkten wieder zerstoert worden sind bzw. wieviele noch uebrig sind. Damit kann man normal sehr schoen sehen, ob man MemLeaks hat.
    In Deinem Fall, koenntest Du evtl. nach dem NSData Object schauen, dass ja immerhin 250 erzeugt und mit Daten gefuellt wird, und wieoft und auch wann es wieder zerstoert wird.


    Manfred

  • Der Fehler wird mir immer unheimlicher ;)
    Nach ungefähr einer Milliarde Programmdurchläufe habe ich rausgefunden dass hier beim 250. Schleifendurchlauf 0 zurückgegeben wird weil myGZFile==NULL zu sein scheint. warum auch immer, der Pfad stimmt jedenfalls. Ich habe dabei den code zum kopieren ausgeklammert und dann eben beim 250. mal 0 zurück bekommen.

    Quellcode

    1. -(unsigned long)gunzipUsingZlib:(NSString *)inFileName
    2. {
    3. NSLog(@"inFileName: %@", inFileName);
    4. char cstr[[inFileName length]+1];
    6. if(![inFileName getCString:cstr maxLength:([inFileName length]+1) encoding:NSASCIIStringEncoding])
    7. {
    8. NSBeep();
    9. NSLog(@"Error at getCString");
    10. return 0;
    11. }
    13. NSLog(@"cstr: %@", [NSString stringWithCString:cstr encoding:NSASCIIStringEncoding]);
    15. gzFile myGzFile = gzopen(cstr, "r");
    16. if(myGzFile != NULL)
    17. {
    18. NSLog(@"CRC check");
    19. NSMutableData *myGzData = [[NSMutableData alloc] init];
    20. char readbuffer[4096]; // some value divideable by 4
    21. int readlen = 0;
    22. while((readlen = gzread(myGzFile,(void *)&readbuffer[0],4096)) > 0)
    23. {
    24. // for readlen = 0 we are finished
    25. [myGzData appendBytes:(void *)readbuffer length:readlen];
    26. }
    28. unsigned long crc = crc32(0, (const uint8_t*)[myGzData bytes], [myGzData length]);
    29. [myGzData release];
    30. NSLog(@"CRC: %u", crc);
    31. return crc;
    32. }
    33. NSLog(@"Return 0");
    34. return 0;
    35. }
    Alles anzeigen


    Klammere ich den aufruf obiger Methode aus habe ich zwar auch einen crc von 0 aber kopieren geht ohne Probleme.

    Das mysteriöse daran ist allerdings wenn ich beides drin habe also nicht ausgeklammert ist bekomme ich noch den richtigen crc Wert kann aber nicht kopieren, beim nächsten bekomme ich auch noch den richtigen crc Wert kann aber wie gehabt nicht kopieren, danach bekomme ich dann erst 0 als crc zurück und das kopieren klappt nicht.

    Benutze ich nur nicht-gepackte Dateien wird eine andere Methode aufgerufen die mit hilfe der zlib den crc berechnet ohne zu entpacken, da klappt auch alles wunderbar, das crc berechnen und das kopieren.
    Ich verstehe echt nur noch Bahnhof, werde aber morgen (bzw. heute) einen misch aus .gz und nicht .gz Dateien probieren, aber erst geh ich schlafen ;)

  • Wann schliesst Du die Datei eigentlich wieder?
    Ich weiss nicht genau, was passiert, wenn man eine Datei so oft geoeffnet hat. Normalerweise darf da nix passieren. Aber trotzdem, koennte was undefinierbares ergeben. Die Handles werden wahrscheinlich erst bei Programmende wieder entsorgt.
    Ich wuerde sie direkt nach dem Abschluss des Lesevorgangs wieder schliessen.

    Im Uebrigen, brauchst Du fuer den NSLog() den C-String nicht wieder in einen NSString weandeln um ihn auszugeben. Fuer C-Strings gibts auch ein Format: "%s".

    Manfred

  • Original von asrael
    Wann schliesst Du die Datei eigentlich wieder?
    Ich weiss nicht genau, was passiert, wenn man eine Datei so oft geoeffnet hat. Normalerweise darf da nix passieren. Aber trotzdem, koennte was undefinierbares ergeben. Die Handles werden wahrscheinlich erst bei Programmende wieder entsorgt.
    Ich wuerde sie direkt nach dem Abschluss des Lesevorgangs wieder schliessen.


    Gotcha Asrael! :)

    Das ist es! - Das Problem ist, daß die Anzahl der Filehandles innerhalb eines Prozesses begrenzt sind.

    @MetalSnake: Du öffnest immer nur mittels gzopen() aber Du *solltest* den Handle auch nach dessen Benutzung wieder mittels gzclose() schliessen!

    Offensichtlich ist der Darwin Kernel auf eine max. Anzahl offener Filehandles von 250 pro Prozess begrenzt (so gebaut), was ja eigentlich auch ausreichen sollte ;)

  • Wisst ihr was? Ich geb mir die Kugel! Das kann doch alles nicht mehr wahr sein, an so einem dummen Fehler hänge ich jetzt schon seit Tagen?

    Aber eines versteh ich nicht, wieso bekomme ich noch den richtigen crc Wert aber er kann nicht mehr kopieren?


    -Eine verzweifelt heulende Schlange

  • Original von MetalSnake
    Wisst ihr was? Ich geb mir die Kugel! Das kann doch alles nicht mehr wahr sein, an so einem dummen Fehler hänge ich jetzt schon seit Tagen?

    Ach gräm Dich nicht! - Erst Manfreds Post rief in mir ein Deja-Vu hervor, denn ich hatte vor geraumer Zeit mal einen ähnlichen Bug auf einem Programm, welches unter Linux lief und da hab ich dann mal nachgeforscht, warum, nach einer bestimmten Anzahl von geöffneten Filehandles Schluss ist.

    Ich habe dann gelernt, dass man diesen "Anschlag" beim Bauen des Kernels bestimmen kann. ...

    Aber eines versteh ich nicht, wieso bekomme ich noch den richtigen crc Wert aber er kann nicht mehr kopieren?

    Was meinst Du exakt mit "er kann nicht mehr kopieren"? Die errechnete CRC?

    -Eine verzweifelt heulende Schlange

    Ach warum denn - Das gehört doch dazu zum Codieren - macht doch dann auch wieder Spass, wenn es weitergeht, nicht wahr? ;)

  • Original von James

    Aber eines versteh ich nicht, wieso bekomme ich noch den richtigen crc Wert aber er kann nicht mehr kopieren?

    Was meinst Du exakt mit "er kann nicht mehr kopieren"? Die errechnete CRC?


    Nein, die Datei kopieren mit dem NSFileManager. Die CRC wird nur verglichen und dann entschieden wo die Datei hin soll, und wie die heißen soll.

    Und danke für euer Mitgefühl *schluchtz* ;)

  • Wisst ihr was? Ich geb mir die Kugel! Das kann doch alles nicht mehr wahr sein, an so einem dummen Fehler hänge ich jetzt schon seit Tagen?

    Man sucht an den dämlichen Fehlern am löngsten. Die "komplizierten" Sachen hat man sich ja lange geung bewusst gemacht. Selbst wenn man noch einen Fehler macht, weiß man das meist recht schnell, weil das Thema "durchdrungen" ist.

    Das ist wirklich ganz normal.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Original von chartus
    wenn du zuviele dateien öffnest kannst du auch keine dateien mehr kopieren weil du dann einfach nichtmehr die nötigen filehandels vom system bekommst


    btw. dies laesst sich eigentlich (fast?) alles via CLI und dem befehl launchctl bzw. launchctl limit loesen denke ich.

    schoenes WE,
    jens
    malloc: *** vm_allocate(size=1665622016) failed (error code=3)