tengine 结合动态域名解析模块，在我们项目中测试发现了几个问题 // some problems in dyups

fcg9iug3 于 4个月前发布在其他

关注(0)|答案(6)|浏览(58)

ngx_stream_upstream_check_module 在我们项目中测试发现存在的问题:
内存泄漏,fail时须判断peer_shm[index].sockaddr != NULL并调用ngx_slab_free_locked(shpool, peer_shm[index].sockaddr)释放地址占用的共享内存空间
可能会复用正在删除的节点，delete值需要考虑为PEER_DELETING的情况
多余的判断，因为使用的是 || ，index >= check_ctx->peers_shm->max_number没意义，正常流时，反而会增加一次判断
应该返回共享内存数组下标(peer[i].index)，而不是进程本地数组下标(i)，这里会导致返回错误的节点甚至会引起崩溃(在我的项目中)。多进程时，每个进程本地数组节点顺序并不能保证一致，只有共享内存数组节点是一致的
访问共享内存时数据时没有加锁保护 1
访问共享内存时数据时没有加锁保护 2
共享内存锁(shpool->mutex)和节点锁存在使用混乱 1
共享内存锁(shpool->mutex)和节点锁存在使用混乱 2

由于我们的项目需要支持动态增删节点且需要支持stream模块，故开发了新的模块供大家参考

6条答案

这似乎是源码上讨论的问题，
内存泄漏,fail时需调用ngx_slab_free_locked(shpool, peer_shm[index].sockaddr)

这个逻辑是

所以这里不确定你遇到什么问题。这个逻辑如果不解锁反而异常

这里严谨的需要全部加锁。但是因为估计当初逻辑是再通用硬件上操作，默认原子操作cmp和inc。这里标记TODO估计也有考虑这个。

这似乎是源码上讨论的问题，
内存泄漏,fail时需调用ngx_slab_free_locked(shpool, peer_shm[index].sockaddr)

这个逻辑是

所以这里不确定你遇到什么问题。这个逻辑如果不解锁反而异常

https://github.com/alibaba/tengine/blob/master/modules/ngx_http_upstream_check_module/ngx_http_upstream_check_module.c#L1239
这里如果goto fail, 最好判断

if (peer_shm[index].sockaddr != NULL) {
       ngx_slab_free_locked(shpool, peer_shm[index].sockaddr);
 }

这里严谨的需要全部加锁。但是因为估计当初逻辑是再通用硬件上操作，默认原子操作cmp和inc。这里标记TODO估计也有考虑这个。

是的，但是这里ref、owner 类型并不是ngx_atomic_t类型的，代码上多处有访问共享内存不加锁的情况

这里严谨的需要全部加锁。但是因为估计当初逻辑是再通用硬件上操作，默认原子操作cmp和inc。这里标记TODO估计也有考虑这个。

是的，但是这里ref、owner 类型并不是ngx_atomic_t类型的，代码上多处有访问共享内存不加锁的情况

是的。这里需要一个fix。这里todo应该改掉fix

todo位置，或者加锁不严谨由此引入：9210e49b0