Grosse Datenmengen mit malloc

[abc (Gast)]

Hallo,

Im Rahmen eines Projekt muss ich Speicher belegen um die Daten einer 
Datei auszulesen - vieel Speicher. Zumindest meint LeakSanitizer das.

Ich versuche ueber malloc ca. 120000byte zu belegen, bekomme beim 
ausfuehren allerdings die Fehlermeldung

Direct leak of 120000 byte(s) in 1 object(s) allocated from:

Ich habe leider keine Idee, wie ich das ganze umgehen kann. Ich bin fuer 
jeden noch so kleinen Tipp dankbar!

Cheers

[Jim M. (turboj)]

Du musst halt auch mal free() ausführen, wenn Du mit der Verarbeitung 
fertich bist.

Ansonsten lst meine Glaskugel grade in Reparatur.

[Rene H. (Gast)]

Ohne Code kann man da nichts sagen, sorry.

[Noch einer (Gast)]

> Du musst halt auch mal free() ausführen

oder die Warnung ignorieren. Meist ist malloc() ohne free() ein Fehler.

Wenn du den Speicher bis zum Programmende brauchst, kannst du das free() 
auch weglassen. Beim Programmende wird sowieso der ganze Speicher wieder 
freigegeben.

[Lukas K. (carrotindustries)]

abc schrieb:
> Im Rahmen eines Projekt muss ich Speicher belegen um die Daten einer
> Datei auszulesen - vieel Speicher.

Mitunter brauchst du das garnicht: Du kannst das das Betriebssystem für 
dich machen lassen:
Bein Unixen mit mmap, auf Win32 nennt sich's MapViewOfFile

[Kaj (Gast)]

Waere echt cool wenn du auch mal sagen wuerdest um welchen 
compiler/tools es geht

http://clang.llvm.org/docs/LeakSanitizer.html

LeakSanitizer is only supported on x86_64 Linux.

Schau dir das Beispiel an. Das free() fehlt -> Bumm, fehlermeldung.
Zu jedem malloc gehoert auch ein free, zu jedem new ein delete.

Ja, am ende des programms koennte man es weglassen, ist aber nicht 
sauber.

abc schrieb:
> Ich versuche ueber malloc ca. 120000byte zu belegen, bekomme beim
> ausfuehren allerdings die Fehlermeldung
Das leakt (sorry, aber das wortspiel lass ich mir nicht nehmen :D ) aber 
nicht an malloc!

abc schrieb:
> Ich habe leider keine Idee, wie ich das ganze umgehen kann.
Umgehen schon mal gar nicht. Das Problem beheben ist das einzig richtige 
was du mach solltest, und das ist ganz einfach: ein free() einbauen.

[Pandur S. (jetztnicht)]

> Wenn du den Speicher bis zum Programmende brauchst, kannst du das free()
auch weglassen. Beim Programmende wird sowieso der ganze Speicher wieder
freigegeben.

Dann kann man gleich ein globales, statisches Array definieren..

[Carl D. (jcw2)]

Für's lesen einer Datei in einen großen Puffer gibt es
"Memory Mapped Files".
Dann kümmert sich nämlich das OS um die Details.

[Rainer V. (rudi994)]

Oder vllt. hier unter "Suppressions" (Fehlermeldung unterdrücken): 
https://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizer

[Der Andere (Gast)]

Oh D. schrieb:
> Dann kann man gleich ein globales, statisches Array definieren..

Nicht, wenn man zur compile Zeit nicht weiss wie groß die Datei ist.

Carl D. schrieb:
> Für's lesen einer Datei in einen großen Puffer gibt es
> "Memory Mapped Files".

Wäre die saubere Lösung

[Planlos (Gast)]

Rainer V. schrieb:
> Oder vllt. hier unter "Suppressions" (Fehlermeldung unterdrücken):
> https://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizer

Wenn bei dir im Auto die Kühlwasser-Leuchte angeht, dann häckst du auch 
mit Riesen-Aufwand den Motor-Controller, um die Warnleuchte 
auszublenden, anstatt einfach Wasser nachzufüllen?

Anderer Vorschlag: das Programm in einer VM laufen lassen, den 
VM-Controller die Aktivität&Ausgabe vom LeakSanitizer erkennen lassen 
(einfache Bilderkennung & OCR), und mit einem kleinen, schwarzen, 
Always-On-Top Popup die Fehlermeldung im Fenster abdecken?

Meine Vermutung: der TE will die Datei sowieso nur einmal von Anfang bis 
Ende Zeilenweise durchlesen, Lösungsvorschläge mit mmap, und/oder 
korrekter Verwendung von free() gehen am eigentlichen Problem vorbei.

[Oliver S. (oliverso)]

abc schrieb:
> vieel Speicher.
> ...
> ca. 120000byte

Na ja, "vieel"...
Selbst im Original-PC mit 640kB RAM waren 117kB nicht wirklich "vieel".

Oliver

[Rufus Τ. F. (rufus)]

Oliver S. schrieb:
> Selbst im Original-PC mit 640kB RAM waren 117kB nicht wirklich "vieel".

Aber nur sehr kompliziert anzusprechen, weil das mehr als 64 kB sind. 
Dank der Segmentitis, an der der PC damals (oder lange danach noch im 
"real mode") litt, bedurfte es dort aufwendiger Konstruktionen 
(Speichermodell "huge"), um mit Datenblöcken zu hantieren, die mehr als 
ein Segment belegten. Und das war natürlich eine Performancebremse.

[Der Andere (Gast)]

Rufus Τ. F. schrieb:
> damals

Als Programmierer noch echte Kerle waren

duck und weg...

[Dirk B. (dirkb2)]

Oliver S. schrieb:
> Selbst im Original-PC mit 640kB RAM waren 117kB nicht wirklich "vieel".

Der Original-PC hatte nur 16 oder 64 kB RAM. Später auch 256.

[Rufus Τ. F. (rufus)]

Dirk B. schrieb:
> Der Original-PC hatte nur 16 oder 64 kB RAM

In dieser Konfiguration dürfte ihn kaum jemand kennengelernt haben, 
wirklich verbreitet hat sich das Ding erst in der Inkarnation als XT. 
Ohne Cassettenrecorderschnittstelle, aber mit 8 statt 5 Slots.