Problemi gravi di Memory Leak con QML/Javascript

[m2dtkast]

Salve;
se al posto della data letta assegni una stringa statica, il comportamento del consumo cambia?

[marco_88]

Il problema che solo per prendere l'ora da una richiesta http per prenderla dalla memoria e aggiornarla sulla grafica, io mi aspetterei non di non avere significativi aumenti, ma di non averli affatto, o mi sbaglio? È normale che anche se poco aumenta la memoria per una funzione così stupida, come leggere l'ora di sistema e aggiornarla nella grafica ogni secondo?

Perchè come ripeto, anche se aumentasse poi dovrebbe anche liberarsi, perchè a lungo andare anche di poco potrebbe poi diventare un problema. Ora provo ad eseguirlo anche nel pc lo stesso codice che sta girando ora e vediamo.

Saluti,
Marco

[m2dtkast]

Per chiarire,
solitamente qml é compilato JIT (se non erro, di default).
Quindi gli oggetti non sono "preallocati" in quanto tale, ma per ogni singola richiesta (request) uscente, il codice in quanto tale
é rieseguito; di conseguenza si noterá un certo consumo "dinamico" di memora.
Qt solitamente si "mangia" parecchia memoria specialmente nel boot dell eseguibile (dato il caricamento di tutte le dipendenze);
in piu, lo Scene graph non é "leggerissimo", e in cima poi chiaramente si trovano gli asset (foto etc).

Valgrind solitamente é abbastanza specifico nell identificare problemi di leak.

https://doc.qt.io/qtcreator/creator-valgrind-overview.html

Non so se é gia stato provato?

[marco_88]

@m2dtkast Ho fatto questa prova e sembrava che se al posto della data assegnavo una stringa statica la memoria non aumentava. Avevo fatto questa prova, ma il mio programma è fatto in larga parte da dati dinamici, quindi magari la maggior parte dei problemi dipende da questo, e se trovo il problema sulla data magari riesco a risovlerlo in gran parte del codice.

Saluti,
Marco

[m2dtkast]

@marco_88 said in Problemi gravi di Memory Leak con QML/Javascript:

    else {
        targetDate = new Date();
        timestamp = targetDate.getTime()/1000;
        localdate = new Date(timestamp * 1000)

Suggerirei di deallocare esplicitamente gli oggetti allocati sull heap nel JS (via i vari new) dopo l uso. Tipo:

targetData = undefined
localdate = undefined

per rimuovere le referenze, considerando che gli oggetti servono "unicamente" per generare la controparte leggibile tramite
le toLocaleString questo non dovrebbe distubare

[marco_88]

@m2dtkast Avevo provato a mettere a null le variabili, ma proverò a farlo dopo l'utilizzo, ma usando undfined al posto di null e vediamo se ho dei miglioramenti.

Saluti,
Marco

[marco_88]

@m2dtkast Purtroppo mettendo tutte le variabili javascript su undefined dopo l'utilizzo continua a non funzionare. Se invece faccio hourLocal e dateLocal = "" poi non leggo più la data nell'interfaccia, quindi non riesco a capire.

Saluti,
Marco

[mrdebug]

Ciao, non per essere pessimista ma non credo che risolverai i tuoi problemi in questo modo. Secondo me il problema non sta nel tuo codice o in qml ma nel dispositivo.

[marco_88]

@mrdebug Sto facendo qualche altra prova, ma se scoprissi che dipende dal device, come potrei fare a risolverlo? Devo assolutamente risolvere questi problemi.

Saluti,
Marco

[mrdebug]

Riesci a mettere in test un programma con una scritta dinamica bastato su qwidget e vedere se la memoria va esaurendosi?
Il dispositivo è agggiornato (os, kernel etc)?
Che dispositivo è e che os / kernel ha?

[marco_88]

Con QWidget, quindi senza qml, corretto? Qualche esempio posso trovarlo e testarlo.

Per quanto riguarda il sistema operativo è aggiornato per quanto riguarda quello che c'è per questo device.

Il sistema operativo è yocto, e credo sia aggiornato: https://variwiki.com/index.php?title=Yocto_Build_Release&release=RELEASE_THUD_V1.0_VAR-SOM-MX6

Kernel è la versione 4.14.78 e il device come mostrato dal link è un variscite con chip iMX6.

In effetti testandolo più a lungo sul PC Desktop che è Ubuntu 18.04 con kernel 5.4.0-58 e il test l'ho fatto con la stessa versione di QT che gira sul device, e qui ho avuto adirittura dei piccoli decrementi, seguiti da piccoli incrementi, che è quello che mi aspetterei, e infatti a me sta bene che ogni tanto ci siano degli incrementi, se poi sono seguiti dai decrementi.

Aprendo top sul desktop quando ho aperto il programma su RES segnava 81848 e ora segna 81840, anche con dei minimi su 81797, invece aprendo top sul device quando ho aperto aveva 51548 e ora è 52188, stessa identica versione del programma, stessa versione di QT, ma ovviamente sistema diverso.

Saluti,
Marco

[mrdebug]

stai usando framebuffer?

[marco_88]

@mrdebug Ciao, si sto usando framebuffer senza parte grafica e lancio l'applicativo con EGLFS.

Saluti,
Marco

[marco_88]

@mrdebug Ciao, ho fatto una scoperta riguardo questo problema. In pratica mi sono concentrato oltre che sulla memoria utilizzata dal mio applicativo, anche dalla memoria libera totale del sistema. Infatti le volte che mi andava in crash l'applicativo QT succedeva che nel giro di 3-4 giorni si esauriva tutta la memoria (la board ha 1 GB di memoria).

Allo start ci sono circa 743 MB liberi compreso l'applicativo scritto in QT, e in effetti controllando bene l'aumento di memoria dell'applicativo mio non è così elevato da esaurire più di 700 MB in pochi giorni.

Ora ho riattivato tutte le funzioni javascript dell'applicativo e riportato allo stato originale e ho notato che la memoria è passata da 54.6 MB a 55.6 MB dopo aver cliccato su un pulsante nell'interfaccia, ma dopo di che non ci sono stati altri aumenti di memoria, è rimasta stabile su 55.6 MB per 1 ora, ma la memoria libera è scesa a dismisura. Mentre l'applicativo in un ora ha avuto solo quell'aumento di 1 MB, il sistema ha perso in totale circa 20 MB, e se in un ora la memoria da 743.6 MB è scesa a 723.6 MB puoi capire che il sistema dura davvero poco prima che chiuderà l'applicativo per mancanza di memoria.

La memoria oscillava ma sempre a ribasso, scendeva sempre di più all'infinito. Ho provato adesso ha disabilitare il servizio che fa partire l'applicativo QT e non ci sono più grandi oscillazioni e la memoria è stabile, da 773 MB a 772.8.

Questo mi porta a pensare che l'applicativo di per se non causa aumento di memoria, ma causa aumenti di memoria indirettamente. Problemi di driver nel device che fanno uso della grafica? Php che viene richiamato per le richieste? Python che viene richiamto per degli script? L'applicativo usa EGLFS per partire e Yocto è in modalità Framebuffer. Può essere lì il problema? Non ho proprio idea e sto uscendo scemo per capire le cause. Ora farò delle analisi più approfondite anche sul PC, perchè apparentemente l'applicativo non cresceva particolarmente, però non ho verificato la memoria totale libera, anche se su PC ci sono tante cose e potrebbe essere complciato fare questo tipo di analisi.

Aggiungo inoltre che la memoria che cresce sul device quando l'applicativo gira, non è oscillante, ma cresce solamente, ogni tanto ha dei piccoli decrementi, ma gli incrementi sono molti di più, e comunque tutto si stabilizza quando l'applicativo mio non gira.

Saluti,
Marco

[mrdebug]

Ho avuto lo stesso problema anni fa. L'applicativo si appoggiava a xorg. Ne è emerso che l'opengl non era ben supportato per cui era xorg a mangiarsi tutta la memoria.
Non ho potuto fare altro che utilizzare qwidgest e non qml, di modo da non dover usare accelerazioni grafiche particolari.
Il problema accade con qualsiasi programma che faccia uso di grafica in modo spinto, non solo con Qt.
Hai modo di provare ad usare wayland e vedere se il problema si risolve?
La versione di yocto non mi sembra recente, stai usando la versione ufficiale rilasciata da chi ti fa la scheda o l'avete fatta voi?
Il progetto cosa fa?

[marco_88]

@mrdebug Ciao. La versione di Yocto non è la più recente perchè per la scheda DART-MX6 di Variscite, sembra esser la versione più recente disponibile. Anche io volevo una versione più recente, però questa è la più recente che ho trovato per questa scheda. Ora i test li sto facendo sull'Evaluation Kit ufficiale di Variscite, però il progetto è una scheda fatta da un azienda, ma usano questa scheda di Variscite comunque. È un progetto abbastanza articolato, deve essere performante il più possibile e non deve avere rallentamenti, perchè è per uso medico. Legge i dati da canbus, manda gli allarmi, ci sono dei riscaldatori, sensore di ossigeno, spo2, etc.

Sull'Evaluation kit qualche test posso farlo, però per usare wayland cosa dovrei fare? Per quanto riguarda qwidget comporterebbe però debellare qml, e ho già scritto tutto il codice in qml, e sarebbe un bel casino, visto anche che per concludere questo primo step non avrei poi tanto tempo a disposizione. Però a livello grafico non è che deve fare niente di particolarmente impegnativo. La parte più impegnativa forse sono i grafici, perchè ha anche dei grafici, ma in questi test neanche ho aperto la pagina dei grafici, e fra l'altro non ci sta attaccato niente, e quindi i dati neanche li legge perchè nell'evaluation kit solo si apre la grafica, ma sostanzialmente non fa nulla perchè non è la macchina originale che invece risiede in ufficio.

Fammi sapere se ci sta un modo rapido e veloce di risolvere questo problema perchè non sai da quanto tempo è che sto combattendo con questo.

Saluti,
Marco

[mrdebug]

E' una bella rogna.
Vedo nel sito che propongono Debian e Boot2Qt. Se hai modo di provarle provale.
Poi rompi i maroni a variscite, digli che devono risolverti il problema o quantomeno darti supporto visto l'acquisto che gli avete fatto. Digli che se fai girare l'applicativo su un rasperry problemi non ne hai.

[marco_88]

@mrdebug Boot2Qt il problema è che aveva una versione di qt troppo vecchia: la 5.9, invece sono riuscito a mettere almeno la 5.11.
Debian è quella che c'era prima, e lì ci facevo girare la webapp prima di portarla su qt, ma non sono riuscito a trovare una guida per mettere qt su debian basato su questa scheda. Su raspberry pi non ho provato, dovrò metterci un altro progetto su raspberry, ci ho fatto un prototipo ma non ho analizzato l'uso della memoria.

Senza mettere mano a gran parte del codice senza togliere di mezzo QML vedi delle idee per risolvere? Tu dici di provare a compilare Yocto con X11? Wayland è un alternativa a framebuffer che fa uso di X?

Grazie

Saluti,
Marco

[marco_88]

@mrdebug Ciao, saresti così gentile da poterci sentire privatamente per cercare di venire a capo di questo problema, visto che tu hai avuto dei problemi simili, e questo problema è di estrema urgenza.

Ho fatto delle prove, praticamente lanciando un esempio di qt, non in qml, sul device, non sembra aumentare la memoria, però lanciando l'esempio qml weather che fa una chiamata api ogni tot minuti, che è anche quello qml, anche lì non sembra esser eccessivo l'uso della memoria in generale. Ho un leggero aumento di memoria sull'applicativo, che è coerente con l'aumento della memoria in generale, e non come nel caso mio che l'aumento dell'applicativo non è coerente con l'aumento in generale della memoria.

Ho anche provato a disabilitare alcune funzioni sul mio applicativo e la memoria ha un comportamento più coerente. Quello che ho notato però è che prima aprendo top appariva fra i programmi ogni tanto un python, che ora non appare più perchè ho commentato delle funzioni che indirettamente lo richiamavano.

Mi daresti una mano a cercare di risolvere questo problema visto che tu ne hai avuto a che fare? Fra le opzioni comunque è da escludere il fatto di sostituire qml con qwidget, ora non c'è proprio il tempo per farlo, e poi facendo partire un esempio qml non ho notato problemi. In background sto comunque anche compilando per la scheda variscite con wayland per fare quella prova che dicevi, ma non sono certo che questo risolverà il problema.

Saluti,
Marco

[mrdebug]

Ciao, se vuoi possiamo sentirci al tel dopo le 14, il cell lo mando in pvt