# A short tale of a read overflow

DevFeed: [A short tale of a read overflow](<https://devfeed.tech/articles/a-short-tale-of-a-read-overflow-20608.md>)

Original publisher: [Read original article](<http://antirez.com/news/117>)

Published: 2018-02-07T20:30:39Z

Content type: article

Language: en

Sources: [Antirez](<https://devfeed.tech/sources/antirez.md>)

Topics: [Redis](<https://devfeed.tech/topics/redis.md>), [bug](<https://devfeed.tech/topics/bug.md>), [Data structures](<https://devfeed.tech/topics/data-structures.md>), [Programming](<https://devfeed.tech/topics/programming.md>)

Tags: [blog](<https://devfeed.tech/tags/blog.md>), [blog-post](<https://devfeed.tech/tags/blog-post.md>), [bug](<https://devfeed.tech/tags/bug.md>), [data-structure](<https://devfeed.tech/tags/data-structure.md>), [programming](<https://devfeed.tech/tags/programming.md>), [redis](<https://devfeed.tech/tags/redis.md>)

## AI overview

A blog post examines a Redis crash associated with its radix tree implementation. The author investigates whether the failure came from the RediSearch module or from a bug in Redis, focusing on suspicious memory movement and a zero-padded memory address.

## Source excerpt

[This blog post is also experimentally available on Medium: https://medium.com/antirez/a-short-tale-of-a-read-overflow-b9210d339cff] When a long running process crashes, it is pretty uncool. More so if the process happens to take a lot of state in memory. This is why I love web programming frameworks that are able, without major performance overhead, to create a new interpreter and a new state for each page view, and deallocate every resource used at the end of the page generation. It is an inherently more reliable programming paradigm, where memory leaks, descriptor leaks, and even random crashes from time to time do not constitute a serious issue. However system software like Redis is at the other side of the spectrum, a side populated by things that should never crash. Months ago I received a crash report from my colleague Dvir Volk. He was developing his RediSearch Redis module, so it was not clear if the crash was due to a programming error inside the module, perhaps corrupting the heap, or a bug inside Redis. However it looked a lot like a real problem into the radix tree implementation: === REDIS BUG REPORT START: Cut & paste starting from here === # Redis 999.999.999 crashed by signal: 11 # Crashed running the instuction at: 0x7fceb6eb5af5 # Accessing address: 0x7fce9c400000 | Backtrace: | redis-server *:7016 [cluster](raxRemoveChild+0xd3)[0x49af53] | redis-server *:7016 [cluster](raxRemove+0x34f)[0x49b34f | redis-server *:7016 [cluster](slotToKeyUpdateKey+0x1ad)[0x4415dd] The radix tree is full of memmove() calls, and Redis crashed exactly trying to access a memory address that was oddly zero padded at the end: 0x7fce9c400000. My first thought was, I'm sure I'm doing some wrong memory movement here, and the address gets overwritten with zeroes, leading to the crash when the program attempts the deference the address. I'm pretty proud about my radix tree implementation. Not because of the implementation itself, while it's a complex data structure to implemen