Memory leakage bei eigenem Modul

[Torben]

Hallo,

ich habe ein Modul geschrieben, um mir den Fahrplan des ÖPNV vor meiner Haustür auf einem Display anzeigen zu lassen. Die Abfrage läuft über HttpUtils_NonblockingGet und funktioniert auch wunderbar. Mein Problem ist, dass sich der von fhem genutzte Speicher durch mein Modul immer weiter erhöht bis quasi die kompletten 2GB von meinem Odroid voll sind und fhem nicht mehr läuft. Es liegt auch auf jeden Fall an meinem Modul und nicht an einem anderen. Ich habe es deaktiviert und dann keine Probleme mehr. Vermutlich ist es ein allgemeines perl-Thema. Leider kenne ich mich nicht genug aus und hoffe, dass mir jemand einen Tipp geben kann.

Gruß
Torben

[viegener]

2 Dinge sind mir aufgefallen

1) es gab wohl Probleme mit memory leaks im XML parser, von denen nicht klar ist, ob diese gefixt sind.
2) der dispose wird nicht aufgerufen, wenn der eval block in einen Fehler läuft. Der dispose scheint wichtig zu sein, damit der Speicher freigegeben wird. Du könntest den Parser vielleicht ausserhalb des evals definieren und dann den dispose danach aufrufen, dann wird er auf jeden Fall durchlaufen. Allerdings nur, wenn Du regelmässig hier in den catch läufst.

[Torben]

Hallo viegener,

vielen Dank für die Hinweise. Der zweite Punkt ist mir nach meinem Post auch noch aufgefallen und ich habe es so gefixt:
- Variable vor dem try definiert
- dispose sowohl im try-Block, als auch im catch-Block.
Nun läuft FHEM mit dem Modul seit Sonntag ohne Speicherprobleme.
Es scheint also wirklich daran gelegen zu haben. Der Server (auch über die reguläre Website) unseres ÖPNV ist immer mal wieder nicht erreichbar oder liefert keine anständigen Daten. Daher ist das Modul häufiger in den catch gelaufen.

Gruß
Torben

[viegener]

Hallo viegener,

Nun läuft FHEM mit dem Modul seit Sonntag ohne Speicherprobleme.
Es scheint also wirklich daran gelegen zu haben. Der Server (auch über die reguläre Website) unseres ÖPNV ist immer mal wieder nicht erreichbar oder liefert keine anständigen Daten. Daher ist das Modul häufiger in den catch gelaufen.

Gruß
Torben

Das mit den irregulären Daten hatte ich wg. des try / catch vermutet.
Schön das es wieder geht!