Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?

Fehler in Core Data unter Mac OS X 10.6 und 10.6.1

Für Entwickler ist CoreData eine große Erleichterung: Es vereinfacht die Art und Weise stark, wie Programme mit Datenbanken interagieren. Stark zusammengefasst ausgedrückt ist Core Data die Abstraktionsschicht, über die Programm und Datenbank kommunizieren. Datenbankelemente müssen nicht vollständig in den Arbeitsspeicher befördert werden, stattdessen arbeitet Core Data mit Verweisen auf Objekte, die zudem nur nach Bedarf geladen werden. Vor knapp zwei Jahren, Mac OS X 10.5 Leopard war gerade frisch auf dem Markt, hatten wir einen schwerwiegenden Fehler in Core Data ausfindig gemacht, der auch zu Datenverlust führen konnte.
Anscheinend waren wir auch bei Snow Leopard die ersten, denen ein weiterer, schwererer Fehler in Core Data auffiel. Nachdem bei einem neuen Programm eine Woche Fehlersuche zu keinem Ergebnis führte und nur widersinnige Ergebnisse hervorbrachte, kamen wir schließlich einem Fehler in Core Data auf die Schliche. Über Apples Entwicklerzugang reichten wir ein Testprojekt ein, mit dem wir das Problem belegten und nachwiesen, unter welchen Umständen ein ärgerlicher Fehler auftritt.
Die Apple Developer Connection bestätigte unsere Vermutung: Es handelt sich tatsächlich um einen schwerwiegenden und bisher unentdeckten Fehler in Mac OS X 10.6 Snow Leopard, der auch in Mac OS X 10.6.1 noch vorhanden ist. Betroffen hiervon sind alle Anwendungen, die Core Data nutzen. Apple scheint im geschilderten Fall ein großes Problem beim Verteilen bestimmter Aufgabe auf mehrere Prozessorkerne zu haben. Lässt man ein Testprogramm auf zwei Kernen unter Snow Leopard laufen, erhält man beim Abruf von 100.000 Objekten 0 bis 2 falsche Angaben zu den Relations. Wird das selbe Programm auf dem selben Rechner mit 8 aktivierten Kernen ausgeführt, erhält man 5-10 falsche Angaben. In unserem Fall führte dies zu erst einmal nicht nachvollziehbaren Programmabstürzen, theoretisch wäre aber auch Datenverlust möglich.
Eine genauere Schilderung des Problem finden Sie über den angegeben Link. Keine Angaben wollte Apple machen, wann das Problem behoben wird.

Weiterführende Links:

Kommentare

barabas14.09.09 10:50
Vor allem wäre es zunächst auch einmal Interessant welche Programme davon betroffen sind (..oder sein könnten).
0
Fenvarien
Fenvarien14.09.09 10:52
Theoretisch jedes Programm, das auf CoreData setzt. Ohne große Datenmengen und ohne vier oder mehr Prozessorkerne ist es aber unwahrscheinlich, darauf zu stoßen. Beim Mac Pro hingegen war das genannte Programm schlicht und einfach nicht zu benutzen, während es auf allen andern Macs problemlos lief. Deaktiviert man beim Mac Pro Prozessorkerne, so lief es auch.
Up the Villa!
0
Stefan S.
Stefan S.14.09.09 11:31
wow! Kriegt ihr eure Fehlersuche-Ausfallzeiten kulanterweise erstattet?
0
Fenvarien
Fenvarien14.09.09 11:41
Nein, aber man muss Apples Reaktionszeiten loben; nach zwei Mails hatten wir schon direkten Kontakt mit dem Entwicklerteam.
Up the Villa!
0
pummelfee14.09.09 11:44
Schon irgendwie ein kleiner Skandal, dass das System bereits am 28.8. erschienen ist und ich es heute immer noch nicht bedenkenlos produktiv einsetzen kann. Vielleicht ist 10.6.2 ja benutzbar... Für mich kein großes Ding weil ich ja noch 10.5 habe. Aber ich stelle mir die armen Säue vor, die sich gerade einen neuen Mac kaufen wollen/müssen.
0
Marcel Bresink14.09.09 11:46
Du meine Güte. Fehler dieser Art gibt es doch Dutzende in Leopard und Snow Leopard. Es ist leider üblich, dass Software-Entwickler hunderte von Arbeitsstunden darin investieren müssen, Workarounds und Regressionstests für die ganzen Fehler im System auszuarbeiten.

Ich hoffe nur, dass diese ständigen Falschmeldungen "es gibt keine bekannten Fehler mehr im Update 10.x.y", die aus einer falschen Übersetzung des Fachbegriffs "known issues" herrühren, endlich mal aufhören. Schätzungsweise dürfte die Zahl der bekannten Fehler in Mac OS X im vier- bis fünfstelligen Bereich liegen.
-1
Marcel Bresink14.09.09 11:50
pummelfee:
Auch das ist leider kein "Skandal", sondern übliches Vorgehen von Apple.

Manche Features, die in Mac OS X 10.5 Leopard Server vorhanden sein sollen, aber bei denen schon in der Beta-Phase, also lange vor der Veröffentlichung, bekannt war, dass sie nicht richtig arbeiten, funktionieren auch heute, nach 8 Updates noch nicht.
0
ExMacRabbitPro14.09.09 11:57
Im Ernst: Die Daten Zugriffsschicht stellt sozusagen die Kronjuwelen einer App dar. Gibt es dort Probleme (Bugs, Performance, etc...) ist die ganze App schrott - egal wie toll der Rest des Programms auch ist.
Das Thema "Übergang von relationalen Datenmodellen zu Objekten" ist auch sehr alt und schon x-Fach beackert worden und alle Jahre wieder kommt einer mit einem neuen Ei des Kolumbus.
Ich würde mich NIE - was den Datenzugriff angeht - für meine App auf ein Fremdes Framework verlassen (außer natürlichen den direkten Treiber/Schnittstelle für die jeweilige DB).
Denn geht dort etwas in die Hose und ich kann nix selbst daran machen, ist man der Looser.
Eine kleine Persistenzschicht selbst zu implementieren ist kein so großes Hexenwerk und hat den Vorteil, dass man selbst die Fehler suchen und auf die eigenen Bedürfnisse hin optimiert implementieren kann - das zahlt sich immer aus.
Diese ganzen tollen "automatismus Dinger" wie z.B. Core Data, Binding oder sogar die Property Generierung sind vielleicht gut um auf Developer Shows ein "WOW" beim Publikum zu ereugen - aber nicht für eine ernsthafte Entwicklung.
0
Mendel Kucharzeck
Mendel Kucharzeck14.09.09 11:58
Das krasse an dem Fehler ist aber, dass er tatsächlich alle Core-Data-Anwendungen, die den Workaround nicht nutzen, zu sehr merkwürdigem verhalten verleiten kann und unter Umständen sogar zu Datenverlust führen kann.

Dass in Leo Server manche Sachen nicht korrekt funktionieren, stimmt. Aber das betrifft nur eine kleine, meist sehr versierte Anwenderschaft. Der Fehler in CoreData kann jeden treffen, zumal CoreData sehr häufig eingesetzt wird, weil es eigentlich ein klasse Framework ist.

Bugs sind im AppKit wirklich tonnen vorhanden, meist aber von der Natur, dass diese einfach zu umschiffen sind und direkt auftreten. Die "Datenhaltungsklassen", wie zum Beispiel das serialisieren und deserialisieren von NSDictionaries sind meist fehlerfrei. Wenn NSButton XYZ im Modus ZYX nicht richtig gezeichnet wird ist das zwar ärgerlich, aber leicht zu umschiffen.
0
Mendel Kucharzeck
Mendel Kucharzeck14.09.09 12:02
ExMacRabbitPro
Da stimme ich dir nicht zu. CoreData selbst zu implementieren wäre ein extremer Aufwand (ja, habe ich schon selbst gemacht, beispielsweise in MobileFamilyTree 1, das war ein eigener Datenbank-Wrapper mit einer sqlite3-Datenbank). CD ist mehr als eine kleine persistenz-schicht.

Auch bei KVO-Bindings stimme ich dir nicht zu. Bindings sind super für GUI-Programmierung und wenn man das Prinzip verstanden hat, auch super zu verwenden. Hat mir in MacStammbaum extrem viel Arbeit erspart und in Verbindung mit CoreData erleichtert es viele alltägliche Problemchen (Master-Detail-View etc).

0
ExMacRabbitPro14.09.09 12:13
Mendel Kucharzeck

Natürlich ist Core Data mehr als eine kleine Persistenz Schicht! Das habe ich auch nie behauptet. Das muss auch so sein, da Core Data einen umfangreichen, möglichst universalen Funktionsumfang anbieten muss.
Wenn man dann aber mal untersucht wie viel davon die einzelnen Anwendung wirklich verwenden, dann sieht sie Sache oft anders aus. Dies ist nämlich meist ein wesentlich kleinerer Funktionsumfang. Und diesen individuell zu implementieren - das fällt dann i.d.R. locker in den Bereich des machbaren.
Das habe ich gemeint.
0
matzee14.09.09 13:52
Nutzt iTunes CoreData? Habe dort nämlich seit dem Update leichte Probleme mit doppelten bzw. nicht mehr vorhandenen Einträgen sowie wilden Umsortierungen der Titelnummern.
0
ex_apple_user_neu14.09.09 14:42
Ihr dürft Euch auf die Schuler klopfen.
Ist das ein Blog? Dann darf man die erste Person verwenden.

Hat man journalistischen Anspruch, dann muss man - außer bei Kommentaren - die dritte Person verwenden.
0
Fenvarien
Fenvarien14.09.09 14:52
Er findet es albern, über sich in der dritten Person zu schreiben. Oder einfacher: Ich schreibe nicht über mich in der dritten Person
Up the Villa!
0
Mendel Kucharzeck
Mendel Kucharzeck14.09.09 15:04
ExMacRabbitPro
Ok, verstanden. Meist nutzen kleinere Anwendungen wirklich nur ein Subset, aber für größere Anwendungen wäre es wirklich Overkill, das nachzubauen. Würde selbst wenn man es sehr speziell auf den Problemfall anwendet, also kein generelles persistenzframework schreibt, monate dauern.

matzee
Nein, die nutzen kein CoreData.
0
ex_apple_user_neu14.09.09 15:29
Er findet es albern, über sich in der dritten Person zu schreiben. Oder einfacher: Ich schreibe nicht über mich in der dritten Person

Ja, das stimmt. Aber es wäre eleganter gewesen zu schreiben: "Synium Software hat festgestellt...." oder "Ein Mitarbeiter von Synium Software hat in seiner Freizeit festgestellt, dass ..."

0
Andreas Hofmann14.09.09 21:14
MTN

Nun ja, dass CoreData die Interaktion mit Datenbanken erleichtert ist wohl etwas hoch gegriffen. Da würde ich schon etwas erwarten, dass zumindest mehr als eine ausgewachsene SQL-Datenbank für die Persistenz benutzen kann, SQLite ist wie der Name schon sagt ein leichtgewicht. Das soll keine Abwertung von CoreData sein, aber manch einer denkt sonst vielleicht, CoreData würde sich als Abstraktionsschicht für beliebige Datenbanken nutzen lassen, Treiber dazwischen und fertig, aber dafür ist es (bisher) nicht konzipiert.

ExMacRabbitPro

Millionen von Web-Anwendungen im Netz, Firmenlösungen etc. machen doch genau das. Sie verlassen sich auf RDBMS wie Oracle, MySQL, PostgreSQL Microsoft SQL Server etc. um Daten zu speichern zu Filtern, zu verknüpfen, die Konsistenz des Datenmodells zu erhalten etc. Und die machen das sicherer, als die meisten es je könnten, wenn sie jedes mal das Rad neu erfinden müssten, weil über inzwischen schon Jahrzehnten entwickelt und von einem riesigen Anwenderkreis erprobt, der jeden Fehler findet. Und die Teile sind schon sehr abstrakt, betreffend z.B. referentielle Integrität steckt da sehr viel Automatismus drin, auf den ich zumindest nicht verzichten mag. CoreData setzt da nur eine weitere Schicht drauf, in Punkto backend leider sehr beschränkt. Aber auch hier gilt der Vorteil, dass das Rad nur ein mal erfunden werden muss und zwar richtig.

Das "richtig" ist das Problem. Wie schon richtig bemerkt, geht es dabei ums Herzstück der Anwendungen, hier kann man nicht mit der Bananen-Software-Mentalität dran gehen, wie man das von Apple immer mehr gewohnt ist. Hier muss Apple mit der selben Sorgfalt drangehen wie das bei RDMS im Allgemeinen erwartet wird. Wenn sich solche Fehler häufen, dann ist CoreData verbrannt, dann rührt das keiner mehr an, der eine halbwegs wichtige Anwendung herstellen möchte.

0
ExMacRabbitPro15.09.09 02:45
Andreas Hofmann

Ich denke, dass Du die Kernaussage meines Beitrags nicht vollständig verstanden hast - denn im Prinzip sagen wie beide das selbe...
0
Moogulator
Moogulator15.09.09 04:02
Hin und wieder verbrennen Apps mit Sat1-Ball und sterben. Das ist komisch. Es gibt aber auch Dinger, die besser laufen.

Apple ist heute wie MS auch, es läuft eben erst rund in einer Version 10.6.5 oder so, so schätze ich mal.
Ich habe eine MACadresse!
0
thekryz10.11.09 09:39
Ist das Problem mit 10.6.2 gelöst?
0

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.