summaryrefslogtreecommitdiff
path: root/open_issues/exec_memory_leaks.mdwn
diff options
context:
space:
mode:
authorhttps://me.yahoo.com/a/g3Ccalpj0NhN566pHbUl6i9QF0QEkrhlfPM-#b1c14 <diana@web>2015-02-16 20:08:03 +0100
committerGNU Hurd web pages engine <web-hurd@gnu.org>2015-02-16 20:08:03 +0100
commit95878586ec7611791f4001a4ee17abf943fae3c1 (patch)
tree847cf658ab3c3208a296202194b16a6550b243cf /open_issues/exec_memory_leaks.mdwn
parent8063426bf7848411b0ef3626d57be8cb4826715e (diff)
rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn
Diffstat (limited to 'open_issues/exec_memory_leaks.mdwn')
-rw-r--r--open_issues/exec_memory_leaks.mdwn121
1 files changed, 0 insertions, 121 deletions
diff --git a/open_issues/exec_memory_leaks.mdwn b/open_issues/exec_memory_leaks.mdwn
deleted file mode 100644
index 1fc5a92..0000000
--- 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
-
- <braunr> the exec servers seems to leak a lot
- <braunr> server*
- <braunr> exec now uses 109M on darnassus
- <braunr> it really leaks a lot
- <pinotree> only 109mb? few months ago, exec on exodar was taking more than
- 200mb after few days of uptime with builds done
- <braunr> i wonder how much it takes on the buildds
-
-
-## IRC, freenode, #hurd, 2012-08-17
-
- <braunr> the exec leak is tricky
- <braunr> bddebian: btw, look at the TODO file in the hurd source code
- <braunr> bddebian: there is a not from thomas bushnell about that
- <braunr> "*** Handle dead name notifications on execserver ports. !
- <braunr> not sure it's still a todo item, but it might be worth checking
- <bddebian> 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?
- <bddebian> Would be ideal if it could just use deadboot() from exec.
- <braunr> bddebian: possible
- <braunr> bddebian: hum execboot, i'm not so sure
- <bddebian> Execboot is the exec task, no?
- <braunr> i don't know what execboot is
- <bddebian> It's from libdiskfs
- <braunr> but "diskfs_execboot_class" looks like a class of ports used at
- startup only
- <braunr> ah
- <braunr> then it's something run in the diskfs users ?
- <bddebian> yes
- <braunr> the leak is in exec
- <braunr> if clients misbehave, it shouldn't affect that server
- <bddebian> That's a different issue, this was about the TODO thing
- <braunr> ah
- <braunr> i don't know
- <bddebian> Me either :)
- <bddebian> For the leak I'm still focusing on do-bunzip2 but I am baffled
- at my results..
- <braunr> ?
- <bddebian> 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
- <braunr> and i think i found it
- <braunr> yes :>
- <braunr> testing a bit more and committing the fix later tonight
- <braunr> pinotree: i've been building glibc for 40 mins and exec is still
- consuming around 1m memory
- <pinotree> wow nice
- <pinotree> i've been noticing exec leaking quite some time ago, then forgot
- to pay more attention to that
- <braunr> it's been more annoying since darnassus provides web access to
- cgis
- <braunr> automated tools make requests every seconds
- <braunr> the leak occurred when starting a shell script or using system()
- <braunr> youpi: not sure you saw it, i fixed the exec leak
-
-
-## IRC, freenode, #hurd, 2013-10-10
-
- <gg0> braunr: http://postimg.org/image/jd764wfpp/
- <braunr> exec 797M
- <braunr> this should be fixed with the release of the next hurd packages