Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Assertion failed: `(md->work_bufs[BUFFER_SPAN].size == 0)` - Thread safety related? #570
First off, thanks for an amazing gem!
I did come across a glitch... I think.
I was testing the rendering system under high stress.
I ran the system in multi threaded mode (running on 16 threads).
While testing, I disabled my own cache management to stress test the rendering engine (rather then the caching system which was storing the rendered string).
I repeatedly asked for the same file to be rendered. 12 threads were doing the asking, 16 threads were doing the rendering, it was all running through Iodine's async IO using HTTP requests, about 200 concurrent requests at a time.
Every time I ran the test, my server would crash with the error:
I'm not complaining about the server crashing, I think it's the right thing to do when experiencing data corruption, but I am worried about the underline cause and the risk of production time failures.
I'm assuming this is multi-threading related, since I didn't get the error in single thread mode.
The following is just my guess (my 2¢) and I hope this helps track down the issue:
At first look, the C code doesn't seem to exit the Global VM Lock, so I thought I might be wrong, however, after a quick read through the code (that's a lot of code and very nicely written, wow), I think the issue is with the markdown struct storing stateful rendering data.
I believe that
I'm thankful for your time and hope for a fix or a workaround.
The Redcarpet library is not thread-safe as described in vmg/redcarpet#570. Since we instantiate the Redcarpet renderer in a class variable, multiple Sidekiq threads can access the work buffer and corrupt the state. We work around this issue by memoizing the renderer on a thread basis. Closes #36637