IRQ Serielle Schnittstelle

Message
Author
User avatar
Janka
Posts: 3585
Joined: 11. Feb 2006 19:10

#16 Post by Janka »

Nein, ein select mit timeout in einer Schleife ist die richtige Vorgehensweise. Einen Timer zu benutzen und dann regelmäßig einen Leseversuch zu machen ist wieder eine busyloop, nur eben mit Wartezeit drin.

Janka
Ich vertonne Spam immer in /dev/dsp statt /dev/null.
Ich mag die Schreie.

macke_a

#17 Post by macke_a »

Hallo Janka...

Ok, soweit - so gut...das System funktioniert (erstmal) !
Allerdings habe ich ein neues Problem, was ich mir nicht erklären kann.

Am Anfang meines Programmes kann ich die Daten 100% empfangen,bearbeiten und dementsprechend auswerten. Der serielle Puffer meldet mir umgehend den Erhalt meiner Daten!

Allerdings nach eine bestimmten Zeit so ca. 5 Minuten bekomme ich die Problem wieder, da mein System länger braucht um die Daten auszuwerten als vorher.
Ich bekomme den Inhalt meines Puffers wieder zu spät mitgeteilt.

Erst, also am Anfang nach Programmstart klappt alles gut und dann so etwas? Ich verändere keine relevanten Parameter! Das System bzw. mein Programm wird irgendwie träge...

Wie kann das ?

Gruss

User avatar
Janka
Posts: 3585
Joined: 11. Feb 2006 19:10

#18 Post by Janka »

Solche Probleme sind per se schon schwierig zu lokalisieren. Per Ferndiagnose kann ich da nur raten. Vermutung: Dein Programm hat ein Speicherleck und nach 5min ist das RAM komplett voll und der Rechner beginnt zu swappen.

Du kannst ja mal mit "ulimit -v ..." den maximal gestatteten Speicherbedarf deiner Shell (und jeweils der davon aufgerufenen Prozesse) auf wenige Megabyte begrenzen. Dann wird das Programm abgebrochen, wenn es die Grenze überschreitet. Nur so als Schnelltest.

Janka
Ich vertonne Spam immer in /dev/dsp statt /dev/null.
Ich mag die Schreie.

macke_a

#19 Post by macke_a »

Hallo Janka...
Dein Programm hat ein Speicherleck und nach 5min ist das RAM komplett voll und der Rechner beginnt zu swappen
Wie kann man so etwas verhindern ?
Gibt es eine programmiertechnische Lösung?

Bei ulimit -v bekomme ich als Rückgabewert "unlimited" !

Gruss macke_a

User avatar
Janka
Posts: 3585
Joined: 11. Feb 2006 19:10

#20 Post by Janka »

macke_a wrote:
Dein Programm hat ein Speicherleck und nach 5min ist das RAM komplett voll und der Rechner beginnt zu swappen
Wie kann man so etwas verhindern ?
Indem man es richtig programmiert. Ein Speicherleck entsteht beispielweise, indem man irgendwo malloc() aufruft, dann aber in bestimmten Situationen nicht mehr free(), wenn man den Speicherbereich nicht mehr braucht.
Bei ulimit -v bekomme ich als Rückgabewert "unlimited" !
Und da kannst du den auch verstellen.

$ man ulimit

Janka
Ich vertonne Spam immer in /dev/dsp statt /dev/null.
Ich mag die Schreie.

macke_a

#21 Post by macke_a »

Hallo Janka..
Indem man es richtig programmiert.
Danke für den Tip! Mit einer hohen Wahrscheinlichkeit wirst Du mit Deiner Vermutung auch recht haben.

malloc() rufe ich allerdings nirgendswo auf. Wo soll ich ansetzen, wenn ich nicht wie ich das Problem in den Griff bekomme. Im Prinzip mache ich irgendetwas falsch und das führt dazu, dass mein RAM ein Speicherleck hat.

Bis jetzt habe ich noch nie mit solch einen Problem zu tun gehabt!

Was gibt es denn für Möglichkeiten so ein Problem in den Griff zu bekommen wenn man nicht weis wo man ansetzen soll.

Vielleicht sind andere markante Punkte, wie z.B. malloc relevant auf die ich achten muss!

Gruss macke_a

User avatar
Janka
Posts: 3585
Joined: 11. Feb 2006 19:10

#22 Post by Janka »

Speicherlecks können von allen Aufrufen herühren, die dynamisch Speicher anfordern: malloc(), calloc(), brk(), sbrk(), mmap() . Es reicht auch, wenn eine Library, die man benutzt, intern diese Aufrufe verwendet, um Puffer bereitzustellen.

Meist wird von der Library erwartet, dass man zurückgegebene Puffer mit free() selbst freigibt, sobald man sie nicht mehr braucht, oder es gibt eine Library-Funktion, die das macht.

Janka
Ich vertonne Spam immer in /dev/dsp statt /dev/null.
Ich mag die Schreie.

Post Reply