Cannot fork: Cannot allocate memory | BlockingInformParent

[mumpitzstuff]

Also Leak bei Perl > 2.24?

Kann mir jetzt noch jemand erklären weshalb das mit noleak() verschwindet? Hat dafür jemand eine Erklärung?

[herrmannj]

wird sich in den source von perl finden lassen. Aber "bug" sagt ja auch dass es auch so gehen sollte - aber eben nicht tut.

hmmmm.... Anfangen alle regex(e) zu kapseln... (?)

Aus gegebenem Anlass: https://forum.fhem.de/index.php/topic,84372.msg983856.html#msg983856

[mumpitzstuff]

Ich habe mal einen Bug reported:

https://github.com/Perl/perl5/issues/17218

[Nestor]

archlinux perl v5.30.0
leak function: 740MB
noleak function: 7.74MB

[der-Lolo]

Ich habe den Codeschnipsel in meine 99_Utils gepackt und einen reload gemacht.

Dumme frage: wie rufe ich die Funktion auf..?

[Morgennebel]

Devuan ASCII 2.0 / perl 5.24.1 - kein Speicherproblem

Ciao, -MN

[mumpitzstuff]

Zwischenzeitlich haben sich die Perl Jungs gemeldet. Wenn es stimmt, dann ist der Bug in allen Perl Versionen ab 5.27 enthalten. Soweit ich mich erinnere war der andere leak Bug mit 5.26 behoben. Deshalb ist die 5.26 wahrscheinlich die stabilste Version, zumindest was die von uns nachvollzogenen Bugs angeht. Falls also jemand die Möglichkeit hat die Perl Version zu wechseln, scheint mir aktuell das die sicherste Hausnummer zu sein.

Die Probleme treten übrigens fast ausschließlich beim Kompilieren der Regex Ausdrücke auf, was letztendlich bedeutet, dass es aktuell keine gute Idee ist, diese innerhalb eines Moduls ständig neu zu kompilieren. Das sieht man daran, das wenn man im Script einen leak Aufruf entfernt, der Bug nicht mehr auftritt, weil der Ausdruck const ist und Perl das merkt.
Hat man also regular Expressions die sehr häufig ausgeführt werden müssen und nutzt man dabei Variablen für die Ausdrücke (die sich ändern von Aufruf zu Aufruf), dann sollte man die Ausdrücke mir qr// vorkompilieren und sich irgendwo im Speicher ablegen. Durch Verwendung der vorkompilierten Ausdrücke tritt dann der Leak nur einmalig auf, was mitunter verkraftbar  ist.

[Nestor]

I tested Perl v5.26 on macOS and it is also leaking.

Code Auswählen Erweitern

/usr/bin/time -lp /opt/local/bin/perl5.26 Desktop/leaktest.pl
571363328  maximum resident set size = 571MB

[rudolfkoenig]

Zwischenzeitlich haben sich die Perl Jungs gemeldet.

Hab das commit angeschaut, braeuchte aber laenger, um sinnvoll beitragen zu koennen. Vermutlich fehlt "nur" ein SvREFCNT_dec_NN
Durch Diff-Lesen bin ich auf dem modifier /a gestossen, damit tritt das Problem unter 5.30 _nicht_ auf.
Das waere mAn eine Loesung mit weniger Seiteneffekten.

I tested Perl v5.26 on macOS and it is also leaking.

This contradicts the comment of dur-randir from the linked perl-issue site.

[Nestor]

These are Perl packages from MacPorts, all leaking except for 5.24

Code Auswählen Erweitern

/usr/bin/time -l /opt/local/bin/perl5.24 Desktop/leaktest.pl > /dev/null
   5017600  maximum resident set size

/usr/bin/time -lp /opt/local/bin/perl5.26 Desktop/leaktest.pl > /dev/null
807833600  maximum resident set size

/usr/bin/time -lp /opt/local/bin/perl5.28 Desktop/leaktest.pl > /dev/null
802365440  maximum resident set size

/usr/bin/time -lp /opt/local/bin/perl5.30 Desktop/leaktest.pl > /dev/null
657444864  maximum resident set size


[mumpitzstuff]

Hab das commit angeschaut, braeuchte aber laenger, um sinnvoll beitragen zu koennen. Vermutlich fehlt "nur" ein SvREFCNT_dec_NN
Durch Diff-Lesen bin ich auf dem modifier /a gestossen, damit tritt das Problem unter 5.30 _nicht_ auf.
Das waere mAn eine Loesung mit weniger Seiteneffekten.

This contradicts the comment of dur-randir from the linked perl-issue site.

Kann ich für Perl 5.28 ebenfalls bestätigen. Vermutlich funktionieren beide Lösungen aus ähnlichen Gründen.

Kann man das in HTTPMOD mit dem modifier implementieren? Das wäre wirklich nur eine ganz kleine Änderung an 3-4 Stellen.

[herrmannj]

5.24 ist scheinbar auch betroffen, siehe https://stackoverflow.com/questions/43288921/perl-program-leaking-memory-when-compiling-regex

Eventuell distribution/Patchlevel abhängig. Ich meine mich zu erinnern das ich das unter 5.24 auch das erste mal gesehen habe

[rudolfkoenig]

Ich gehe von unterschiedlichen Regexp-Bugs aus, bei 5.24 war mW nur(?) DOIF betroffen.
regcomp.c ist ca 1MB gross, da ist Platz fuer mehrere Bugs.

[MadMax-FHEM]

Hier kommt/kam ja mächtig Schwung rein

Schon nachdem Rudi etwas bzgl. HTTPMOD bzw. DNS-Lookup (war es glaub ich) gefunden hatte hab ich mal meine Testsysteme einem Update unterzogen...
...und was soll ich sagen: toll!

Also ich habe ein Testsystem mit Stretch und eins mit Buster und bei beiden am 23.10. ein fhem Update durchgeführt...

Die beiden Systeme sind meine "Modul-Testsysteme", d.h. bevor ich ein Modul auf mein Hauptsystem loslasse wird es darauf getestet.

Bislang war eben das echodevice-Modul mein "Problemfall": Modul defined -> Speicher steigt / Modul "gelöscht" -> Speicher "normal"...

Das Buster-System war schon immer etwas besser (siehe Screenshot) aber trotzdem merklich...
...auf dem Stretch System konnte ich das Modul gar nicht wirklich nutzen, alle paar Tage Neustart (siehe Screenshot).

Nach dem Update sind beide Systeme ohne Speicheranstieg

Auf meinem Hauptsystem habe ich einige HTTPMOD (u.a. auch TV aber sehr seltener Update) und eigentlich kaum Anstieg, d.h. das System läuft mehr als einen Monat ohne Problem (ja schon leichter Speicheranstieg aber damit kann/konnte ich leben)...
Meistens mache ich vorher aus anderen Gründen einen Neustart

EDIT: habe nun mein Hauptsystem auch mal einem fhem Update unterzogen, mal sehen... (wobei ja wie geschrieben: dort kein [großes] Problem)

Stretch:
PI 3B+, perl: v5.24.1, dnsServer gesetzt

Buster:
PI 3B+, perl: v5.28.1, dnsServer gesetzt

Somit kann ich sogar das echodevice-Modul auf meinem Hauptsystem nutzen, ohne dieses (noch auf Stretch) updaten (also auf Buster) zu müssen...

Das "leak" Script leakt bei mir unter Stretch auch...
...unter Buster noch nicht getestet, wollte meinen "echodevice-Test" nicht "beeinflussen/stören"...

Gruß und danke, Joachim

[StefanStrobel]

Wenn ein /a Modifier schon ausreicht um das Problem zu lösen, dann könnte man den ja auf die Schnelle auch einfach per Attribut readingRegOpt einstellen.
Ich werde mir aber auf jeden Fall ansehen, ob es in HTTPMOD nicht sinnvoller ist, generell die Regexes direkt in der AttrFn zu compilieren.

Gruss
   Stefan