Problemi gravi di Memory Leak con QML/Javascript
-
Salve, buongiorno.
Dalle prove fatte sembra che anche se lo eseguo nel mio PC ho dei minimi aumenti di memoria, che diventano sempre più grandi a seconda delle funzioni che attivo per fare debug.
In particolare ho notato che prendendo solo la parte dell'else ma fuori dalla request funziona fino a che non assegno la data alla variabile hourLocal e dateLocal, che sono due variabili assegnate come property string nel main.qml principale, che poi assegno al text dela data e l'ora sulla parte grafica.
Nel codice ho dimenticato di inserire questa parte, ma nei 2 text ci sono appunto un text: hourLocal e text: dateLocal.
Grazie
Saluti
-
Vorrei dire che se lasci il programma in esecuzione per ore sul tuo pc non avrai significativi aumenti di memoria occupata mentre nel dispositivo embedded sì.
In passato mi è successa una cosa similare.
Il problema era dipeso dal fatto che il dispotitivo non supportava bene opengl etc. -
Salve;
se al posto della data letta assegni una stringa statica, il comportamento del consumo cambia? -
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 -
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?
-
@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 -
@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 = undefinedper rimuovere le referenze, considerando che gli oggetti servono "unicamente" per generare la controparte leggibile tramite
le toLocaleString questo non dovrebbe distubare -
@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 -
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.
-
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? -
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 -
stai usando framebuffer?
-
@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 -
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? -
@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 -
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. -
@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
12/26