memcpy spinning #315

Closed
opened 2026-01-29 20:41:53 +00:00 by claunia · 2 comments
Owner

Originally created by @splitice on GitHub (Apr 14, 2020).

Today on a production service we saw near 100% cpu usage. Some quick debugging with GDB and ltrace revealed brotli spinning in a 0 byte memcpy.

memcpy(0x5690200, "", 0)        = 0x5690200
[...]
memcpy(0x5690200, "", 0)        = 0x5690200

gdb revealed this to be Brotli:

Breakpoint 1, __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:25
25      ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S: No such file or directory.
(gdb) bt
#0  __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:25
#1  0x0000000000932c4e in WriteRingBuffer ()
#2  0x0000000000935a7e in BrotliDecoderDecompressStream ()
#3  0x000000000061cf04 in ngx_http_brunzip_filter_inflate ()

We are still troubleshooting this. However I thought I would ask if anyone has encountered something similar, or if there is any common traps that we could fall into that could cause this behavior?

Revision: c435f06675

Originally created by @splitice on GitHub (Apr 14, 2020). Today on a production service we saw near 100% cpu usage. Some quick debugging with GDB and ltrace revealed brotli spinning in a 0 byte memcpy. ``` memcpy(0x5690200, "", 0) = 0x5690200 [...] memcpy(0x5690200, "", 0) = 0x5690200 ``` gdb revealed this to be Brotli: ``` Breakpoint 1, __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:25 25 ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S: No such file or directory. (gdb) bt #0 __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:25 #1 0x0000000000932c4e in WriteRingBuffer () #2 0x0000000000935a7e in BrotliDecoderDecompressStream () #3 0x000000000061cf04 in ngx_http_brunzip_filter_inflate () ``` We are still troubleshooting this. However I thought I would ask if anyone has encountered something similar, or if there is any common traps that we could fall into that could cause this behavior? Revision: c435f066751ef83aa4194445085a70ad9d193704
Author
Owner

@eustas commented on GitHub (Apr 14, 2020):

Hello.
Zero length memcpy is obviously not good, going to fix it ASAP. But the problem seems to be caused by the wrapping code - ngx_brunzip module.
And, likely, it was fixed just recently: 93c3f71a1d

@eustas commented on GitHub (Apr 14, 2020): Hello. Zero length `memcpy` is obviously not good, going to fix it ASAP. But the problem seems to be caused by the wrapping code - ngx_brunzip module. And, likely, it was fixed just recently: https://github.com/splitice/ngx_brunzip_module/commit/93c3f71a1d0c10d6807e38db59bb262948807bc5
Author
Owner

@splitice commented on GitHub (Apr 14, 2020):

@eustas First thank you for your response. Yes I think that this is an issue in the wrapping code. I'm testing currently to be sure. It looks like it's a case of zlib assumptions not holding true with brotli. I'm hoping that's is all it is.

I figure brotli may need more space in the output buffer so while remaining length may not be 0 it may be insufficient for brotli output.

I'll close this if it is the case. However better handling though in brotli would be much appreciated by integrators I'm sure :)

@splitice commented on GitHub (Apr 14, 2020): @eustas First thank you for your response. Yes I think that this is an issue in the wrapping code. I'm testing currently to be sure. It looks like it's a case of zlib assumptions not holding true with brotli. I'm hoping that's is all it is. I figure brotli may need more space in the output buffer so while remaining length may not be 0 it may be insufficient for brotli output. I'll close this if it is the case. However better handling though in brotli would be much appreciated by integrators I'm sure :)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/brotli#315