rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn

1 files changed, 121 insertions, 0 deletions

diff --git a/service_solahart_jakarta_selatan__082122541663/exec_memory_leaks.mdwn b/service_solahart_jakarta_selatan__082122541663/exec_memory_leaks.mdwn
new file mode 100644
index 00000000..1fc5a928
--- /dev/null
+++ b/service_solahart_jakarta_selatan__082122541663/exec_memory_leaks.mdwn
@@ -0,0 +1,121 @@
+[[!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