There are is some memory leak in exec.
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