@
zwzmzd 这样没问题。但就像我 14 楼提到的,直接在 vec.reserve(MAX_BUFSIZ)也可以修复问题,静态开一个 vector 相当于调 reserve ,仍然是在堆上分配内存吧。而且 new char[] 在堆上也没问题,应该不是堆/栈的原因。
顺便纠正之前的几个错误,一个是 64 位 ub 下是 121 字节临界(之前忘减 14 字节 eth 头了),不过反正这个数的绝对值意义不大,也无所谓。
另一个可能的错误是,之前认为是内存分配的原因,但我自己写了个 allocator ,每次都在全局上 new 内存,问题仍然出现,而且临界大小不变。
我写的 allocator patch :
https://gist.github.com/isofew/2ffa93faf6ebe3899de55b87115e1551@
colatin @
kkhaike @
boydfd @
linux40 uint8_t arr[MAX_BUFSIZ] 静态开输出如下:
alloc 29 byte(s) at 30174048
&vec[0]: 30174048, arr: 140734511709248
dealloc 29 byte(s) at 30174048
alloc 128 byte(s) at 30174208
&vec[0]: 30174208, arr: 140734511709248
dealloc 128 byte(s) at 30174208
new uint8_t[size] 动态开输出如下:
alloc 29 byte(s) at 21465952
&vec[0]: 21465952, arr: 21466000
dealloc 29 byte(s) at 21465952
alloc 128 byte(s) at 21466160
&vec[0]: 21466160, arr: 21466304
dealloc 128 byte(s) at 21466160
不管哪种开法,都是&vec[0]小包不行大包可以, arr 全都可以。