Memory Leak in der CV?

[netsrac]

Moin moin,

Habe die CV auf einem Nexus 7 laufen und sowohl der Dolphin Browser, als auch der Firefox beenden sich nach ca. 2 Tagen ohne einen Tastendruck / Touch.

Scheinbar gibt es dort ein Memory Leak im Hintergrund, was zum Absturz führt.

Habe das ganze mal auf einem Desktop probiert und in einem Firefox nur die CV geöffnet. Nach 2 Tagen (ohne Interaktion) hatte der FF stattliche 2.6 GB an Speicher genutzt - beim einem frischen Start liegt er bei ca. 900 MB.

Also irgendwas scheint da im Hintergrund nicht ganz rund zu laufen.

Ist das ein allgemeines Problem der Browser, ein jQuery Problem oder irgendwas, was die CV selbst verbricht.

Wäre schade, wenn man die CV nicht im Dauereinsatz laufen lassen könnte, da ich meine Tablets gerne an die Wand nageln würde und mit nix anderem als der Visu bestücken will - man soll am besten eigentlich gar nicht merken, dass da was Anderes außer der Visu drauf läuft (Kiosk Mode).

Irgendeine Idee, wie man sowas debuggen kann?!

Gruß, netsrac

[iwan]

Ich habe sowas ähnliches auf meinen Samsung Galaxy Tab mit Chrome auch festgestellt.

Ab und zu erscheint in Browser, dass ein Fehleraufgetreten ist udn die Seite neu geladen werden müsse.
Wenn ich dann den aktualisisren button drucke ist alles wieder io.

Konkretere Infos habe ich leider nicht.

Grüsse
Iwan

[Chris M.]

So etwas darf natürlich nicht sein und wir sollten dem unbedingt nachgehen.

Wie man das debuggen kann? Ich weiß es ehrlich gesagt nicht.
Als ich zu CV-Anfangszeiten (also vor ein paar Browser-Generationen) mal nach Möglichkeiten gesucht habe, hatte ich keine gefunden.

Das Problem hier ist, dass JavaScript kein sauberes Memory Management hat und auf den Garbage Collector vertraut. Zudem gibt es dank Closures auch noch schön viele Fallen, in die man tappen kann.

Eine grobe Indikation könnte aber schon mal eine leere Config-Seite geben (also ohne Bus-Kommunkiation), wie die SVN-Start-Config. Wie verhält die sich? Und von dort dann eben weiter...

PS: Der Chrome hat inzwischen ein "Heap Snapshot", evtl. kommt man damit weiter...

[makki]

Kann ich so aktuell nicht nachvollziehen (hatte das Problem aber schonmal)..
Nexus 4,7 und Chromium+FF am U12.04 rennen mindestens tagelang durch.

Am Desktop sind die Gründe meist Addons (Flash, Java, PDF), am Android könnte man höchstens mal den ADB anstecken, viel weiss ich darüber aber auch noch nicht

Makki

[netsrac]

Da ich mein Nexus 7 sowieso gerooted habe, habe ich mich mal eingelogged...beim Starten gestern um 16 Uhr hatte der Dolphin Browser ca. 800 MB belegt - heute - etwa 18h dannach - belegt er bereits 1200 MB.

In der Zwischenzeit wurde keine einziger Button gedrückt...

Bin mal gespannt, wie es später oder morgen aussieht.

Gruß, Netsrac

[greentux]

Und wie siehts ohne die CV aus?

[Chris M.]

Evtl. kommst Du dann mit https://developers.google.com/chrome...docs/debugging weiter - mein Android (2.3) ist zu alt dafür...

[netsrac]

Und wie siehts ohne die CV aus?

Das ist natürlich eine berechtigte Frage....wobei sowohl Firefox als auch Dolphin (die einzigen beiden Browser, die Fullscreen erlauben) das Problem haben.

Klar, können auch beide schlecht programmiert sein...

Okay...ich beobachte weiter und berichte....

Da mein Device ja gerooted ist (brauche ich, um die dumme Android Statusleite weg zu bekommen), kann ich mir ja im Zweifelsfall etwas überlegen, was den Browser im Falle eines Crashes neu startet :-)

[netsrac]

Hmm...keine Ahnung, wie ich mit dem debugger ein Memory Leak feststellen kann :-(

Da der Browser aber gerade wieder - vor meinen Augen - abgestürzt ist, hier ein paar Infos aus dmesg:

[1052174.985315] Out of memory: Kill process 18746 (ek.TunnyBrowser) score 611 or sacrifice child
[1052174.985459] Killed process 18746 (ek.TunnyBrowser) total-vm:1277952kB, anon-rss:594636kB, file-rss:13840kB
[1052174.997117] kworker/u:1 invoked oom-killer: gfp_mask=0xd0, order=2, oom_adj=0, oom_score_adj=0
[1052174.997266] [<c0014de0>] (unwind_backtrace+0x0/0x138) from [<c00ce888>] (dump_header.isra.7+0x74/0x190)
[1052174.997393] [<c00ce888>] (dump_header.isra.7+0x74/0x190) from [<c00cf0b8>] (out_of_memory+0x288/0x350)
[1052174.997518] [<c00cf0b8>] (out_of_memory+0x288/0x350) from [<c00d242c>] (__alloc_pages_nodemask+0x6a8/0x6d0)
[1052174.997642] [<c00d242c>] (__alloc_pages_nodemask+0x6a8/0x6d0) from [<c00d2468>] (__get_free_pages+0x14/0x38)
[1052174.997771] [<c00d2468>] (__get_free_pages+0x14/0x38) from [<c001a124>] (pgd_alloc+0x14/0x174)
[1052174.997852] [<c001a124>] (pgd_alloc+0x14/0x174) from [<c065a9f4>] (__cpu_up+0x60/0x214)
[1052174.997978] [<c065a9f4>] (__cpu_up+0x60/0x214) from [<c065b89c>] (_cpu_up+0xa8/0x134)
[1052174.998101] [<c065b89c>] (_cpu_up+0xa8/0x134) from [<c065ba1c>] (cpu_up+0xf4/0x1a4)
[1052174.998222] [<c065ba1c>] (cpu_up+0xf4/0x1a4) from [<c003d6c0>] (tegra_auto_hotplug_work_func+0x110/0x2d4)
[1052174.998300] [<c003d6c0>] (tegra_auto_hotplug_work_func+0x110/0x2d4) from [<c007ca08>] (process_one_work+0x12c/0x494)
[1052174.998424] [<c007ca08>] (process_one_work+0x12c/0x494) from [<c007cee0>] (worker_thread+0x170/0x3cc)
[1052174.998549] [<c007cee0>] (worker_thread+0x170/0x3cc) from [<c0080fd4>] (kthread+0x80/0x88)
[1052174.998678] [<c0080fd4>] (kthread+0x80/0x88) from [<c000f468>] (kernel_thread_exit+0x0/0x8)
[1052174.998794] Mem-info:
[1052174.998853] Normal per-cpu:
[1052174.998916] CPU    0: hi:  186, btch:  31 usd:  71
[1052174.999029] HighMem per-cpu:
[1052174.999091] CPU    0: hi:   90, btch:  15 usd:  22
[1052174.999160] active_anon:183124 inactive_anon:1021 isolated_anon:0
[1052174.999164]  active_file:5100 inactive_file:6500 isolated_file:0
[1052174.999167]  unevictable:94 dirty:0 writeback:0 unstable:0
[1052174.999171]  free:21981 slab_reclaimable:1805 slab_unreclaimable:4169
[1052174.999175]  mapped:6544 shmem:3094 pagetables:1700 bounce:50
[1052174.999635] Normal free:87008kB min:3528kB low:4408kB high:5292kB active_anon:580024kB inactive_anon:2272kB active_file:92kB inactive_file:368kB unevictable:376kB isolated(anon):0kB isolated(file):0kB present:779520kB mlocked:0kB dirty:0kB writeback:0kB mapped:8492kB shmem:9716kB slab_reclaimable:7220kB slab_unreclaimable:16676kB kernel_stack:4008kB pagetables:6800kB unstable:0kB bounce:200kB writeback_tmp:0kB pages_scanned:729 all_unreclaimable? yes
[1052174.999917] lowmem_reserve[]: 0 1862 1862

Daraus geht zumindestens hervor, dass es ein Memory-Problem ist...

[Chris M.]

Wobei man natürlich von einem System-Backtrace nicht rausfinden kann wo im JavaScript ein Problem stecken sollten.

Den einzigen Ansatz den ich hier erst mal sehe ist per ADB den Browser remote debuggen und dort auf den Speicherverbrauch gehen, bzw. versuchen zu extrahieren, was nach ein paar Stunden mehr im Speicher ist als nach dem Start (+ etwas Zeit zum stabilisieren)

[netsrac]

Wobei man natürlich von einem System-Backtrace nicht rausfinden kann wo im JavaScript ein Problem stecken sollten.

Logisch...es war für mich lediglich ein "Proof-of-facts", dass es sich um ein Memory-Problem handelt...

Alles weitere muss ich mal in einer ruhigen Minute versuchen...