summaryrefslogtreecommitdiff
path: root/service_solahart_jakarta_selatan__082122541663/exec_memory_leaks.mdwn
blob: aeae8df0653b5b1bb2c56195f4cf27e261117db8 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
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` ([[service_solahart_jakarta_selatan__082122541663/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