System.IndexOutOfRangeException beim Serialisieren (Mögliche E/A-Racebedingung)

Ich habe das folgende Problem beim serialisieren einer eigenen Klasse. Exakt dieses Objekt kann ich nicht serialisieren, jedoch andere Werte mit der gleichen Klasse funktionieren.

Die Fehlermeldung kann ich selber nicht ganz deuten. Was soll ich machen oder warum kann ich das Objekt aus dem Speicher nicht auf die Festplatte speichern?

Nutze VS 2013 mit .Net Framework 4.5

Du hast da jetzt nicht allen ernstes ein Array mit 1 Milliarde Floats drin?

O.o

Also ein paar Millionen sind ja noch zu verkraften, aber über einer Milliarde?

Eine Idee, warum das nicht geht, hab ich aber auch nicht. Der einzige Gedanken-ANsatz ist Multi-Threading, das Stichwort Threadsicher steht in der Exception, vielleicht kollidiert da ja was.

Ansonsten schau doch mal in die InnerException, vielleicht steht da was.

Das Zauberwort heißt "Big Data"

Hallo digi333,

Exakt dieses Objekt kann ich nicht serialisieren, jedoch andere Werte mit der gleichen Klasse funktionieren.

mit gleichgroßer Datenmenge oder ist die Datenmenge bei den Objekten, die funktionieren, (wesentlich) kleiner?

Greifst du während des Serialisierens von einem anderen Thread auf das Objekt bzw. Array zu?

herbivore

Die Daten sind dort etwas kleiner und ich greife mit keinem anderen Thread auf das Objekt oder die Festplatte zu.

Mich wundert halt nur, dass ich die Daten im Speicher habe, aber diese nicht auf die Festplatte schreiben kann. Seltsam!

Ich versteh nich, was das eine mit dem anderen zutun hat.
MrSparkles Einwand sagt eigentlich alles. Denn effizient ist Dein Vorhaben nicht; im Gegenteil: es ist dazu fehleranfällig.

Hi digi333,

ich kann das ganze auch nicht nachvollziehen. Wie kommst du überhaupt darauf, daß es am Speicher liegt? Das Bild in deinem ersten Beitrag zeigt keine SystemOutOfMemoryException, sondern eine IndexOutOfRangeException. Woher die kommt, kann man ohne eine genauere Beschreibung von dir und ohne Code nicht sagen. Aber der StackTrace sollte dich auf die richtige Spur bringen. Siehe auch [Artikel] Debugger: Wie verwende ich den von Visual Studio?.

Christian

Ich versteh nich, was das eine mit dem anderen zutun hat.
MrSparkles Einwand sagt eigentlich alles. Denn effizient ist Dein Vorhaben nicht; im Gegenteil: es ist dazu fehleranfällig.

Nein... tut es nicht. Es ist jediglich ein nicht auf die Frage bezogener Hinweis.

Warum ich so viele Floats brauche hat tatsächlich mit einer komplizierten zueinander gewichtungsabhängigen Berechnung zu tun, bei der die Daten komplett und gleichzeitig verfügbar sein müssen. Die Ergebnisse möchte ich daher serialisieren um weitere Gewichtungen vornehmen zu können. Egal. Darüber solltet ihr euch aber keinen Kopf machen.

ich kann das ganze auch nicht nachvollziehen. Wie kommst du überhaupt darauf, daß es am Speicher liegt? Das Bild in deinem ersten Beitrag zeigt keine SystemOutOfMemoryException, sondern eine IndexOutOfRangeException. Woher die kommt, kann man ohne eine genauere Beschreibung von dir und ohne Code nicht sagen. Aber der StackTrace sollte dich auf die richtige Spur bringen. Siehe auch
> .

Speicher? Wer sagte das es daran liegt. Es liegt im Speicher aber läßt sich nicht speichern auf Festplatte.

Danke für die Hinweise, aber bezogen auf die Fragen waren sie nicht. (Standardantwort in diesem Forum ist immer "such irgendwo in der HOW-TO-XYZ" oder "richtig Debuggen"... dann schreibt doch besser nichts.

Du hast (wahrscheinlich) aufgrund Deiner uneffizienten Herangehensweise zu viele Daten, als dass der Standard-Serializer damit umgehen könnte.
Daher kommt es zur Exception und daher landet nichts auf der Platte - einfaches Spiel.

Das Problem kommt schließlich nicht bei der Datenhaltung im Speicher, sondern beim Serialisieren zustande. Entweder es ist eine nicht dokumentierte Exception des BinaryFormatters oder es passiert beim Zugriff auf Deine Matrix (Pcd) - wobei keiner weiß, was dahinter steckt..
Würde aber tippen, dass es eben beim Schreiben des Speichers passiert (oder vom Speicher auf die HDD).
Lösung: effizienteren Code, inkl. Caching / Splitting implementieren, der so eine Datenmenge eben handlen kann.

Du bist nebenbei ziemlich überheblich und frech, dafür, dass Du Hilfe verlangst / erwartest / erhoffst - das mal nebenbei und aus persönlicher Sicht, ohne, dass ich damit das ganze Forum (oder nur ein Teil) repräsentiere.

Sollte der standard BinaryFormatter wirklich probleme mit der größe haben, könntest du ja mal probe weiße die ISerializable Schnittstelle implementieren und das serialisieren selbst handeln.
Ev. die größeren Datenmengen dann dort drin komprimiert halten.

Hallo zusammen,

für meinen Geschmack ist das "Mögliche E/A-Racebedingung" aus der Fehlermeldung zu kurz gekommen. (Ich habe es deshalb mal mit in den Titel geschrieben.