存在内存泄露的问题 #67

vurt · 2016-10-21T07:49:34Z

使用ngx_http_dyups动态创建的upstream后内存会一直增长直到服务器失去响应，最后定位到应该是ngx_http_dyups模块存在内存泄露，google之发现以前也有人遇到过类型的问题，参考这里

yfgu · 2016-10-28T08:42:36Z

请问这个问题解决了么？我们想动态更新upstream，如果有这个问题的话，就要像其他办法了。

yzprofile · 2016-10-29T13:57:34Z

最近一直没有时间来详细测试，请给出一下你这边的编译参数以及配置文件。谢谢

yfgu · 2016-10-31T07:09:01Z

我们在测试环境测试一下，观察一下内存情况。
这个是vurt提出的，不知道他是怎么测试的

iandyh · 2017-01-13T05:39:06Z

@yfgu 你们后来的观察是怎样的？谢谢。

powerdesigner · 2018-03-03T02:25:16Z

@vurt 我也遇到类似问题，你后来怎么解决的？

vurt · 2018-03-05T15:10:12Z

@powerdesigner 换了kong

powerdesigner · 2018-03-06T09:40:07Z

@yfgu @iandyh 该问题你们的解决方案是什么呢？由于压测疏忽，基于该组件的项目已经上线，更换成本太高了，苦命
@yzprofile 恳请大神有空时看看能否修复该问题。

iandyh · 2018-03-06T15:13:31Z

@powderdesigner 我们没遇到这个情况，在 prod 跑了大半年了。不过我们是没有 https 的。

chobits · 2018-03-07T04:35:37Z

能否提供一下内存泄露的一些debug数据。邮件里agentzh已经提供了1个方法来帮助分析nginx中内存占用了。

另外我们这边，有个探测ngx中pool内存占用的工具ngx_debug_pool

for tengine: 从2.2.2开始内置模块
for nginx: here

如果是dyups的pool中内存占用过高，使用该工具会出现：ngx_dyups_init_upstream这个项目会一直增大。

提供如上一些信息来帮助开发者来定位会加速问题解决。

另外如果能够提供完整的reproduce方法，让开发者在自己环境中复现会更容易定位。

chobits · 2018-03-07T04:36:02Z

referer to: alibaba/tengine#1016

powerdesigner · 2018-03-07T04:59:51Z

@chobits 以下是debug_pool信息
free shared buff/cache available
587 9435 673 3992 12325
0 0
free shared buff/cache available
593 9429 673 3992 12319
0 0
free shared buff/cache available
595 9428 673 3992 12317
0 0
free shared buff/cache available
597 9425 673 3992 12315
0 0
free shared buff/cache available
599 9424 673 3992 12313
0 0
free shared buff/cache available
601 9422 673 3992 12312
0 0
free shared buff/cache available
602 9420 673 3992 12310
0 0
free shared buff/cache available
605 9417 673 3992 12307
0 0
free shared buff/cache available
605 9417 673 3992 12307
0 0
free shared buff/cache available
606 9416 673 3992 12306
0 0
free shared buff/cache available
607 9415 673 3992 12305
0 0
~]# curl 127.0.0.1:9088/debug_pool
230 cnum: 44 lnum: 244 ngx_dyups_init_upstream
62 cnum: 0 lnum: 0 ngx_http_dyups_read_msg_locked
4120 cnum: 3 lnum: 9814 ngx_http_create_request
2 cnum: 1 lnum: 12 ngx_init_cycle
1 cnum: 0 lnum: 4 ngx_http_lua_create_fake_connection
8238 cnum: 2 lnum: 12357 ngx_http_upstream_connect
1 cnum: 0 lnum: 0 main
1 cnum: 0 lnum: 0 ngx_http_lua_init_worker
172 cnum: 3 lnum: 4616 ngx_event_accept
12827 cnum: 53 lnum: 27047 [SUMMARY]
~]# curl 127.0.0.1:9088/debug_pool
230 cnum: 44 lnum: 244 ngx_dyups_init_upstream
62 cnum: 0 lnum: 0 ngx_http_dyups_read_msg_locked
4300 cnum: 7 lnum: 10273 ngx_http_create_request
2 cnum: 1 lnum: 12 ngx_init_cycle
1 cnum: 0 lnum: 4 ngx_http_lua_create_fake_connection
8596 cnum: 6 lnum: 12894 ngx_http_upstream_connect
1 cnum: 0 lnum: 0 main
1 cnum: 0 lnum: 0 ngx_http_lua_init_worker
181 cnum: 8 lnum: 4815 ngx_event_accept
13374 cnum: 66 lnum: 28242 [SUMMARY]
~]# curl 127.0.0.1:9088/debug_pool
252 cnum: 44 lnum: 266 ngx_dyups_init_upstream
63 cnum: 0 lnum: 0 ngx_http_dyups_read_msg_locked
1034 cnum: 2 lnum: 2498 ngx_http_create_request
2 cnum: 1 lnum: 12 ngx_init_cycle
1 cnum: 0 lnum: 4 ngx_http_lua_create_fake_connection
2066 cnum: 1 lnum: 3099 ngx_http_upstream_connect
1 cnum: 0 lnum: 0 main
1 cnum: 0 lnum: 0 ngx_http_lua_init_worker
51 cnum: 2 lnum: 1173 ngx_event_accept
3471 cnum: 50 lnum: 7052 [SUMMARY]
~]# curl 127.0.0.1:9088/debug_pool
230 cnum: 44 lnum: 244 ngx_dyups_init_upstream
62 cnum: 0 lnum: 0 ngx_http_dyups_read_msg_locked
4844 cnum: 7 lnum: 11613 ngx_http_create_request
2 cnum: 1 lnum: 12 ngx_init_cycle
1 cnum: 0 lnum: 4 ngx_http_lua_create_fake_connection
9681 cnum: 6 lnum: 14520 ngx_http_upstream_connect
1 cnum: 0 lnum: 0 main
1 cnum: 0 lnum: 0 ngx_http_lua_init_worker
198 cnum: 7 lnum: 5412 ngx_event_accept
15020 cnum: 65 lnum: 31805 [SUMMARY]
~]# curl 127.0.0.1:9088/debug_pool
230 cnum: 44 lnum: 244 ngx_dyups_init_upstream
62 cnum: 0 lnum: 0 ngx_http_dyups_read_msg_locked
5356 cnum: 2 lnum: 12884 ngx_http_create_request
2 cnum: 1 lnum: 12 ngx_init_cycle
1 cnum: 0 lnum: 4 ngx_http_lua_create_fake_connection
10704 cnum: 1 lnum: 16056 ngx_http_upstream_connect
1 cnum: 0 lnum: 0 main
1 cnum: 0 lnum: 0 ngx_http_lua_init_worker
217 cnum: 3 lnum: 5982 ngx_event_accept
16574 cnum: 51 lnum: 35182 [SUMMARY]
~]# curl 127.0.0.1:9088/debug_pool
259 cnum: 44 lnum: 273 ngx_dyups_init_upstream
63 cnum: 0 lnum: 0 ngx_http_dyups_read_msg_locked
3640 cnum: 5 lnum: 8737 ngx_http_create_request
2 cnum: 1 lnum: 12 ngx_init_cycle
1 cnum: 0 lnum: 4 ngx_http_lua_create_fake_connection
7198 cnum: 4 lnum: 10792 ngx_http_upstream_connect
1 cnum: 0 lnum: 0 main
1 cnum: 0 lnum: 0 ngx_http_lua_init_worker
180 cnum: 6 lnum: 4195 ngx_event_accept
11345 cnum: 60 lnum: 24013 [SUMMARY]
~]# curl 127.0.0.1:9088/debug_pool
230 cnum: 44 lnum: 244 ngx_dyups_init_upstream
62 cnum: 0 lnum: 0 ngx_http_dyups_read_msg_locked
5464 cnum: 2 lnum: 13156 ngx_http_create_request
2 cnum: 1 lnum: 12 ngx_init_cycle
1 cnum: 0 lnum: 4 ngx_http_lua_create_fake_connection
10918 cnum: 1 lnum: 16377 ngx_http_upstream_connect
1 cnum: 0 lnum: 0 main
1 cnum: 0 lnum: 0 ngx_http_lua_init_worker
222 cnum: 3 lnum: 6103 ngx_event_accept
16901 cnum: 51 lnum: 35896 [SUMMARY]
~]# curl 127.0.0.1:9088/debug_pool
252 cnum: 44 lnum: 266 ngx_dyups_init_upstream
63 cnum: 0 lnum: 0 ngx_http_dyups_read_msg_locked
1220 cnum: 3 lnum: 2927 ngx_http_create_request
2 cnum: 1 lnum: 12 ngx_init_cycle
1 cnum: 0 lnum: 4 ngx_http_lua_create_fake_connection
2436 cnum: 2 lnum: 3654 ngx_http_upstream_connect
1 cnum: 0 lnum: 0 main
1 cnum: 0 lnum: 0 ngx_http_lua_init_worker
61 cnum: 3 lnum: 1387 ngx_event_accept
4037 cnum: 53 lnum: 8250 [SUMMARY]
~]# curl 127.0.0.1:9088/debug_pool
259 cnum: 44 lnum: 273 ngx_dyups_init_upstream
63 cnum: 0 lnum: 0 ngx_http_dyups_read_msg_locked
3877 cnum: 7 lnum: 9318 ngx_http_create_request
2 cnum: 1 lnum: 12 ngx_init_cycle
1 cnum: 0 lnum: 4 ngx_http_lua_create_fake_connection
7668 cnum: 6 lnum: 11499 ngx_http_upstream_connect
1 cnum: 0 lnum: 0 main
1 cnum: 0 lnum: 0 ngx_http_lua_init_worker
191 cnum: 8 lnum: 4462 ngx_event_accept
12063 cnum: 66 lnum: 25568 [SUMMARY]
~]# curl 127.0.0.1:9088/debug_pool
264 cnum: 44 lnum: 280 ngx_dyups_init_upstream
63 cnum: 0 lnum: 0 ngx_http_dyups_read_msg_locked
224 cnum: 1 lnum: 584 ngx_http_create_request
2 cnum: 1 lnum: 12 ngx_init_cycle
1 cnum: 0 lnum: 4 ngx_http_lua_create_fake_connection
446 cnum: 0 lnum: 669 ngx_http_upstream_connect
1 cnum: 0 lnum: 0 main
1 cnum: 0 lnum: 0 ngx_http_lua_init_worker
14 cnum: 1 lnum: 263 ngx_event_accept
1016 cnum: 47 lnum: 1812 [SUMMARY]
~]# curl 127.0.0.1:9088/debug_pool
230 cnum: 44 lnum: 244 ngx_dyups_init_upstream
62 cnum: 0 lnum: 0 ngx_http_dyups_read_msg_locked
5581 cnum: 5 lnum: 13421 ngx_http_create_request
2 cnum: 1 lnum: 12 ngx_init_cycle
1 cnum: 0 lnum: 4 ngx_http_lua_create_fake_connection
11150 cnum: 4 lnum: 16725 ngx_http_upstream_connect
1 cnum: 0 lnum: 0 main
1 cnum: 0 lnum: 0 ngx_http_lua_init_worker
229 cnum: 6 lnum: 6236 ngx_event_accept
17257 cnum: 60 lnum: 36642 [SUMMARY]
~]# curl 127.0.0.1:9088/debug_pool
230 cnum: 44 lnum: 244 ngx_dyups_init_upstream
62 cnum: 0 lnum: 0 ngx_http_dyups_read_msg_locked
5621 cnum: 2 lnum: 13518 ngx_http_create_request
2 cnum: 1 lnum: 12 ngx_init_cycle
1 cnum: 0 lnum: 4 ngx_http_lua_create_fake_connection
11228 cnum: 1 lnum: 16842 ngx_http_upstream_connect
1 cnum: 0 lnum: 0 main
1 cnum: 0 lnum: 0 ngx_http_lua_init_worker
231 cnum: 4 lnum: 6283 ngx_event_accept
17377 cnum: 52 lnum: 36903 [SUMMARY]
free shared buff/cache available
869 9153 673 3993 12043
0 0

powerdesigner · 2018-03-07T05:02:04Z

@chobits 稍微一压测内存就急遽下降，这是2分钟内debug_pool和内存情况。该服务器只跑了tengine，没有其他大型应用。

chobits · 2018-03-07T13:17:16Z

hi @powerdesigner

你的压测方法提供下。

(BTW: 我压了下，当我停止后会恢复)

chobits · 2018-03-07T13:26:15Z

hi @powerdesigner

从你的压测过程中debug_pool的信息看，是这个信息上涨

ngx_http_create_request(请求内存池r->pool，cnum表示当前存在的池子数量，也是处理中的请求数)
ngx_http_upstream_connect(后端连接内存是c->pool)
ngx_event_accept（连接内存池c->pool）

这3个内存池都是浮动，理论上你把压测关闭后，这3个选项都应应该较低到很低才对。

而dyups使用的内存池内存占用一直没有变化：

size: 150720 num: 230 cnum: 44 lnum: 244 ngx_dyups_init_upstream

另外还有1个信息关注下，保持一定压测平度一直不停，看看内存是否会不停消耗，还是只会消耗到一定程度（如果使用libc默认的内存分配器ptmalloc，有可能会缓存一部分内存不释放给os，这样即使你停止压测系统可用内存也不会下降）

powerdesigner · 2018-03-07T14:50:33Z

@chobits 这么晚了还协助分析，非常感谢。我们曾保持压力不停，CentOS14G内存最后耗尽到只剩170M到150M之间，然后只在这两者范围内波动，没再继续下降。而生产环境中请求是一直存在的，无法寄希望于没请求后系统自动恢复。以下是我抓取的最新内存信息，压测在上午11点44左右就停止了。
total used free shared buff/cache available
Mem: 14016 891 9047 689 4077 12008
Swap: 0 0 0

top - 14:41:11 up 23 days, 13:26, 1 user, load average: 0.22, 0.06, 0.11
Tasks: 164 total, 1 running, 163 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.3 us, 0.2 sy, 0.0 ni, 99.5 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 14352452 total, 9262344 free, 914264 used, 4175844 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 12295284 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
7759 nginx 20 0 297260 176868 5428 S 0.0 1.2 0:14.13 nginx
7761 nginx 20 0 246752 126704 5544 S 0.0 0.9 0:10.54 nginx
408 root 20 0 163820 99196 98832 S 0.0 0.7 4:58.31 systemd-journal
20861 influxdb 20 0 765820 74000 7920 S 0.7 0.5 0:41.43 influxd
7760 nginx 20 0 187404 66948 5484 S 0.0 0.5 0:05.92 nginx
7758 nginx 20 0 180560 60456 5468 S 0.0 0.4 0:05.36 nginx
892 root 20 0 602860 53788 51012 S 0.0 0.4 2:17.88 rsyslogd
7757 nginx 20 0 161136 40728 5400 S 0.0 0.3 0:03.84 nginx
7520 telegraf 20 0 727872 27500 9764 S 1.0 0.2 90:47.08 telegraf
21161 haproxy 20 0 69624 23116 700 S 1.7 0.2 179:03.68 haproxy
7756 nginx 20 0 142348 21896 5404 S 0.0 0.2 0:02.84 nginx
893 root 20 0 553712 18456 5676 S 0.0 0.1 3:02.96 tuned
1036 root 20 0 398724 17620 5328 S 1.0 0.1 140:11.24 python
7755 nginx 20 0 137224 16860 5392 S 0.0 0.1 0:02.14 nginx
7754 nginx 20 0 136272 16244 5400 S 0.0 0.1 0:02.09 nginx
896 root 20 0 222120 13324 4256 S 0.0 0.1 0:00.28 python
592 polkitd 20 0 633972 13024 4964 S 0.0 0.1 0:06.08 polkitd
843 root 20 0 113368 12780 296 S 0.0 0.1 0:00.00 dhclient
591 root 20 0 437492 7600 5920 S 0.0 0.1 0:04.56 NetworkManager
pid:7759
size: 150720 num: 230 cnum: 44 lnum: 244 ngx_dyups_init_upstream
size: 0 num: 62 cnum: 0 lnum: 0 ngx_http_dyups_read_msg_locked
size: 8192 num: 10856 cnum: 1 lnum: 20527 ngx_http_create_request
size: 303784 num: 2 cnum: 1 lnum: 12 ngx_init_cycle
size: 0 num: 1 cnum: 0 lnum: 4 ngx_http_lua_create_fake_connection
size: 0 num: 16966 cnum: 0 lnum: 25447 ngx_http_upstream_connect
size: 0 num: 1 cnum: 0 lnum: 0 main
size: 0 num: 1 cnum: 0 lnum: 0 ngx_http_lua_init_worker
size: 1536 num: 1255 cnum: 1 lnum: 14670 ngx_event_accept
size: 453KB num: 29374 cnum: 47 lnum: 60904 [SUMMARY]

pid:7761
size: 150720 num: 259 cnum: 44 lnum: 273 ngx_dyups_init_upstream
size: 0 num: 63 cnum: 0 lnum: 0 ngx_http_dyups_read_msg_locked
size: 8192 num: 7829 cnum: 1 lnum: 14463 ngx_http_create_request
size: 303784 num: 2 cnum: 1 lnum: 12 ngx_init_cycle
size: 0 num: 1 cnum: 0 lnum: 4 ngx_http_lua_create_fake_connection
size: 0 num: 11938 cnum: 0 lnum: 17904 ngx_http_upstream_connect
size: 0 num: 1 cnum: 0 lnum: 0 main
size: 0 num: 1 cnum: 0 lnum: 0 ngx_http_lua_init_worker
size: 1536 num: 2351 cnum: 1 lnum: 11474 ngx_event_accept
size: 453KB num: 22445 cnum: 47 lnum: 44130 [SUMMARY]

pid:7756
size: 150720 num: 244 cnum: 44 lnum: 258 ngx_dyups_init_upstream
size: 0 num: 62 cnum: 0 lnum: 0 ngx_http_dyups_read_msg_locked
size: 8192 num: 1721 cnum: 1 lnum: 1715 ngx_http_create_request
size: 303784 num: 2 cnum: 1 lnum: 12 ngx_init_cycle
size: 0 num: 1 cnum: 0 lnum: 4 ngx_http_lua_create_fake_connection
size: 0 num: 1420 cnum: 0 lnum: 2130 ngx_http_upstream_connect
size: 0 num: 1 cnum: 0 lnum: 0 main
size: 0 num: 1 cnum: 0 lnum: 0 ngx_http_lua_init_worker
size: 1536 num: 288 cnum: 1 lnum: 2958 ngx_event_accept
size: 453KB num: 3740 cnum: 47 lnum: 7077 [SUMMARY]

pid:7760
size: 150720 num: 253 cnum: 44 lnum: 267 ngx_dyups_init_upstream
size: 0 num: 63 cnum: 0 lnum: 0 ngx_http_dyups_read_msg_locked
size: 8192 num: 3980 cnum: 1 lnum: 6987 ngx_http_create_request
size: 303784 num: 2 cnum: 1 lnum: 12 ngx_init_cycle
size: 0 num: 1 cnum: 0 lnum: 4 ngx_http_lua_create_fake_connection
size: 0 num: 5916 cnum: 0 lnum: 8874 ngx_http_upstream_connect
size: 0 num: 1 cnum: 0 lnum: 0 main
size: 0 num: 1 cnum: 0 lnum: 0 ngx_http_lua_init_worker
size: 1536 num: 1167 cnum: 1 lnum: 5972 ngx_event_accept
size: 453KB num: 11384 cnum: 47 lnum: 22116 [SUMMARY]

powerdesigner · 2018-03-07T15:10:46Z

@chobits 还有一点不明，同样代码和dyups，在http场景下并未内存泄漏

chobits · 2018-03-07T15:14:55Z

@powerdesigner 从你最新的信息里top里看软件内存占用并不高，ngx大致单worker160MB

整体top显示还有9G多 free ：KiB Mem : 14352452 total, 9262344 free,

chobits · 2018-03-07T15:23:00Z

你的压测方式得提供下，详细到第三方可以模拟出来

配置是怎样的
压测步骤是怎样的
- 请求压力如何构成
- 过程中是否变动upstream (这条非常关键: 这是dyups模块唯一可能内存变动点)

同样代码和dyups，在http场景下并未内存泄漏

dyups本身并不感知https/http

powerdesigner · 2018-03-07T15:54:31Z

整体还剩9G多是因为压测发现内存与生产环境一样骤降，就停止了。请求压力是通过JMeter模拟的，压测过程中并未变动Upstream。

powerdesigner · 2018-03-08T02:05:17Z

刚做了一次新的验证，将所有dyups相关代码都屏蔽掉，动态Upstream改为固定的Upstream，压测未发现明显内存泄漏。

suntao3215 · 2018-07-03T01:19:35Z

@powerdesigner 请问这个问题您解决了吗？我们在用这个模块时看到了这个issue，目前用的http没有出现内存泄漏，但后续可能会改为https。

zhaiyan1234 · 2019-04-16T09:22:03Z

目前改问题比较好复现，复现条件：
（1）使用dyups设置upstream；
（2）upstream server设置为短连接（Connection: close）;
（3）配置为proxy_ssl_session_reuse on; （该配置默认为on）；
当设置为这3个条件后，不停的请求情况下会出现内存泄露，需要具体看upstream session reuse部分代码

zhaiyan1234 · 2019-04-17T03:07:25Z

目前把dyups自身实现的session给下掉了，不再save session，目前看来内存泄露问题不再存在了，希望官方给一个理想的修复方案，毕竟session reuse还是有好处的
PS: 目前实现dyups根本没实现session reuse

RocFang · 2019-09-28T03:19:48Z

我这几天也在解决这个问题，确实是有内存泄漏，解决完之后发现这个存在很久的issue了，我的排查结论跟 @zhaiyan1234 一样。

你的压测方式得提供下，详细到第三方可以模拟出来

配置是怎样的

压测步骤是怎样的

请求压力如何构成

过程中是否变动upstream (这条非常关键: 这是dyups模块唯一可能内存变动点)

同样代码和dyups，在http场景下并未内存泄漏

dyups本身并不感知https/http

@chobits 虽然你说dyups本身不感知https，但是泄漏点就出在本模块的set_session和save_session这两个函数指针上，这两个正是与https相关的。复现很简单，如 @zhaiyan1234 在上面说的一样。

nginx默认是开启了proxy_ssl_session_reuse开关的，这个会导致set_session和save_session发生作用，而dyups这种在request上的peer我认为是没必要reuse_session的，会导致请求结束后没有free_ssl。

最简单的在线上环境避免该问题的方法是将proxy_ssl_session_reuse配置成off，但最根本的解决办法还是要修改一下本模块的set_session和save_session。

我个人目前的解决办法是将这两个函数的body都置为空。参考：RocFang@4a1731b

下面附上确定是这个地方导致内存泄漏的排查过程相关材料：

采集内存泄漏火焰图可看到大量ngx_ssl_handshake的内存没有释放。

初步怀疑是openssl版本问题，但升级若干个openssl版本，均存在内存泄漏。
进而继续定位到本模块，只要将set_session和save_session的body置为空，或者关闭proxy_ssl_session_reuse配置，内存泄漏的现象马上消失。正常的火焰图这里就不必截出来了。

事实上，在nginx的历史代码中，也曾经存在过类似问题，参看：
http://hg.nginx.org/nginx/rev/ff127ba3b091?revcount=240

我也查了一下本模块这两个函数的提交：5b6bac5#diff-542d0606cf0e5efad29466029ed91845
从commit message里来看只是为了解决https时的core dump，但不知道这两个函数有经过实际的功能和压力测试吗？

综上，我认为要么应该直接像我一样简单的将这两个函数置为空，要么重新设计一下这两个函数。

RocFang · 2019-10-24T02:28:19Z

@yzprofile @chobits ping..

timebug · 2020-08-13T13:17:41Z

@RocFang @yzprofile

I redesigned set_session and save_session function, the new solution will solve memory leak issue and keep ssl session reuse work. #143

RocFang · 2020-08-14T03:31:10Z

@timebug wow, good job!

powerdesigner · 2020-08-27T15:46:12Z

感谢几位高手的努力，我后来自己用lua脚本实现了简单的动态Upstream，虽然不再使用该组件，但还是感受到了众人拾柴火焰高的力量

powerdesigner mentioned this issue Mar 3, 2018

dyups: https session重用的内存泄漏 // dyups: memory leak of ssl session reuse alibaba/tengine#1016

Closed

RocFang mentioned this issue Jul 28, 2020

fix memory leak when proxy_pass to dynamic backends with https #141

Open

timebug mentioned this issue Aug 13, 2020

[fix]: memory leak in mod_dyups when ssl session reuse is enabled. #143

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

存在内存泄露的问题 #67

存在内存泄露的问题 #67

vurt commented Oct 21, 2016

yfgu commented Oct 28, 2016

yzprofile commented Oct 29, 2016

yfgu commented Oct 31, 2016

iandyh commented Jan 13, 2017

powerdesigner commented Mar 3, 2018

vurt commented Mar 5, 2018

powerdesigner commented Mar 6, 2018

iandyh commented Mar 6, 2018

chobits commented Mar 7, 2018 •

edited

Loading

chobits commented Mar 7, 2018

powerdesigner commented Mar 7, 2018

powerdesigner commented Mar 7, 2018

chobits commented Mar 7, 2018

chobits commented Mar 7, 2018 •

edited

Loading

powerdesigner commented Mar 7, 2018

powerdesigner commented Mar 7, 2018

chobits commented Mar 7, 2018 •

edited

Loading

chobits commented Mar 7, 2018 •

edited

Loading

powerdesigner commented Mar 7, 2018

powerdesigner commented Mar 8, 2018

suntao3215 commented Jul 3, 2018

zhaiyan1234 commented Apr 16, 2019

zhaiyan1234 commented Apr 17, 2019

RocFang commented Sep 28, 2019 •

edited

Loading

RocFang commented Oct 24, 2019

timebug commented Aug 13, 2020

RocFang commented Aug 14, 2020

powerdesigner commented Aug 27, 2020

存在内存泄露的问题 #67

存在内存泄露的问题 #67

Comments

vurt commented Oct 21, 2016

yfgu commented Oct 28, 2016

yzprofile commented Oct 29, 2016

yfgu commented Oct 31, 2016

iandyh commented Jan 13, 2017

powerdesigner commented Mar 3, 2018

vurt commented Mar 5, 2018

powerdesigner commented Mar 6, 2018

iandyh commented Mar 6, 2018

chobits commented Mar 7, 2018 • edited Loading

chobits commented Mar 7, 2018

powerdesigner commented Mar 7, 2018

powerdesigner commented Mar 7, 2018

chobits commented Mar 7, 2018

chobits commented Mar 7, 2018 • edited Loading

powerdesigner commented Mar 7, 2018

powerdesigner commented Mar 7, 2018

chobits commented Mar 7, 2018 • edited Loading

chobits commented Mar 7, 2018 • edited Loading

powerdesigner commented Mar 7, 2018

powerdesigner commented Mar 8, 2018

suntao3215 commented Jul 3, 2018

zhaiyan1234 commented Apr 16, 2019

zhaiyan1234 commented Apr 17, 2019

RocFang commented Sep 28, 2019 • edited Loading

RocFang commented Oct 24, 2019

timebug commented Aug 13, 2020

RocFang commented Aug 14, 2020

powerdesigner commented Aug 27, 2020

chobits commented Mar 7, 2018 •

edited

Loading

chobits commented Mar 7, 2018 •

edited

Loading

chobits commented Mar 7, 2018 •

edited

Loading

chobits commented Mar 7, 2018 •

edited

Loading

RocFang commented Sep 28, 2019 •

edited

Loading