Comments

Since 2.6, I've noticed an increase in these crashes in my environments. I'm able to replicate it across several installations monitoring the same traffic. Unfortunately, I'm unable to provide a pcap of the issue.

The only allocation in this function seems to be that last line doing a std::vector::reserve(size_t). It is given a uint32-converted-to-int value as argument, opening the door to possible integer overflow action on conversion to size_t (as one may expect given the large number in the tcmalloc message), but there's also clearly a check for negative values followed by an additional bounds check that the length is within the bounds of the underlying data buffer. So if I'm reading everything right, the parser should already catch such problems before performing such a large allocation.

I did happen to notice this possibly similar/related report: gperftools/gperftools#497. Not that it's necessarily the same thing, just that there's precedent for possible bugs in tcmalloc causing such an issue and so maybe worth testing if things are more stable without tcmalloc.

This comment has been minimized.

edited

Have you tried using jemalloc to see if the problem exists there? I've been meaning to make a change for quite some time that switches to jemalloc by default. tcmalloc seems to have bitrotted in the past few years. It would be nice to know if the problem is in the PE analyzer or the allocator as Jon suggested.

This comment has been minimized.

I rebuilt my development environment to use jemalloc and waited. We saw the same exact crash under jemalloc that we saw with tcmalloc. Unfortunately, jemalloc doesn't provide the nice stack that tcmalloc does, so I don't have much debug info to provide.