From 95878586ec7611791f4001a4ee17abf943fae3c1 Mon Sep 17 00:00:00 2001 From: "https://me.yahoo.com/a/g3Ccalpj0NhN566pHbUl6i9QF0QEkrhlfPM-#b1c14" Date: Mon, 16 Feb 2015 20:08:03 +0100 Subject: rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn --- open_issues/exec_memory_leaks.mdwn | 121 ------------------------------------- 1 file changed, 121 deletions(-) delete mode 100644 open_issues/exec_memory_leaks.mdwn (limited to 'open_issues/exec_memory_leaks.mdwn') diff --git a/open_issues/exec_memory_leaks.mdwn b/open_issues/exec_memory_leaks.mdwn deleted file mode 100644 index 1fc5a928..00000000 --- a/open_issues/exec_memory_leaks.mdwn +++ /dev/null @@ -1,121 +0,0 @@ -[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled [[GNU Free Documentation -License|/fdl]]."]]"""]] - -[[!tag open_issue_hurd]] - -There are is some memory leak in [[`exec`|hurd/translator/exec]]. - -[[!toc]] - - -# IRC, freenode, #hurd, 2012-08-11 - - the exec servers seems to leak a lot - server* - exec now uses 109M on darnassus - it really leaks a lot - only 109mb? few months ago, exec on exodar was taking more than - 200mb after few days of uptime with builds done - i wonder how much it takes on the buildds - - -## IRC, freenode, #hurd, 2012-08-17 - - the exec leak is tricky - bddebian: btw, look at the TODO file in the hurd source code - bddebian: there is a not from thomas bushnell about that - "*** Handle dead name notifications on execserver ports. ! - not sure it's still a todo item, but it might be worth checking - braunr: diskfs_execboot_class = ports_create_class (0, 0); - This is what would need to change right? It should call some cleanup - routine in the first argument? - Would be ideal if it could just use deadboot() from exec. - bddebian: possible - bddebian: hum execboot, i'm not so sure - Execboot is the exec task, no? - i don't know what execboot is - It's from libdiskfs - but "diskfs_execboot_class" looks like a class of ports used at - startup only - ah - then it's something run in the diskfs users ? - yes - the leak is in exec - if clients misbehave, it shouldn't affect that server - That's a different issue, this was about the TODO thing - ah - i don't know - Me either :) - For the leak I'm still focusing on do-bunzip2 but I am baffled - at my results.. - ? - Where my counters are zero if I always increment on different - vars but wild freaking numbers if I increment on malloc and decrement on - free - - -# 2012-11-25 - -After twelve hours worth of `fork/exec` ([[GCC]]'s `check-c` part of the -testsuite), we got: - - PID UID PPID PGrp Sess TH Vmem RSS %CPU User System Args - 4 0 3 1 1 10 392M 262M 0.0 2:18.29 2hrs /hurd/exec - -The *RSS* seems a tad high. Also the system part of CPU time consumption is -quite noticeable. In comparison: - - 0 0 1 1 1 19 131M 1.14M 0.0 3:30.25 9:17.79 /hurd/proc - 3 0 1 1 1 224 405M 12.6M 0.2 42:20.25 67min ext2fs --readonly --multiboot-command-line=root=device:hd0s6 --host-priv-port=1 --device-master-port=2 --exec-server-task=3 -T typed device:hd0s6 - 276 0 3 1 1 344 442M 28.2M 0.6 48:09.36 91min /hurd/ext2fs /dev/hd2s5 - - -# 2012-12-20 - -After running the libtool testsuite for some time: - - PID TH# UID PPID PGrp Sess TH Vmem RSS %CPU User System Args - 4 0 3 1 1 11 334M 203M 60.8 3:19.73 4hrs /hurd/exec - 0 0.0 0:20.33 27:02.47 - 1 0.0 0:31.10 32:21.13 - 2 0.0 0:25.68 27:42.33 - 3 0.0 0:00.00 0:00.00 - 4 5.1 0:34.93 34:07.59 - 5 0.0 0:19.56 28:44.15 - 6 3.4 0:18.73 28:17.89 - 7 0.0 0:20.47 34:42.51 - 8 39.5 0:15.60 28:48.57 - 9 0.0 0:04.49 10:24.12 - 10 12.8 0:08.84 19:34.45 - - -# IRC, freenode, #hurd, 2013-10-08 - - * braunr hunting the exec leak - and i think i found it - yes :> - testing a bit more and committing the fix later tonight - pinotree: i've been building glibc for 40 mins and exec is still - consuming around 1m memory - wow nice - i've been noticing exec leaking quite some time ago, then forgot - to pay more attention to that - it's been more annoying since darnassus provides web access to - cgis - automated tools make requests every seconds - the leak occurred when starting a shell script or using system() - youpi: not sure you saw it, i fixed the exec leak - - -## IRC, freenode, #hurd, 2013-10-10 - - braunr: http://postimg.org/image/jd764wfpp/ - exec 797M - this should be fixed with the release of the next hurd packages -- cgit v1.2.3