+[[!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