-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
evbuffer_add_file broken when evbuffer_get_length(outbuf) > 0 and offset > 0 #306
Comments
Working as expected using master
Though it may be a timing thing maybe? Maybe |
Oh, additionally I statically linked libevent.
Compiled with |
Oh, wow, thanks for looking at this so quickly. And...I was mixed up. It doesn't actually happen with current master. Sorry for the waste of time. :( Are bugfixes still being made to the 2.0 branch, or should I just considered it fixed by 2.1? I added a version printf:
With 2.0.21-stable:
gdb shows it takes this path involving evbuffer_drain (which just doesn't make sense here):
|
We still do 2.0 patches, will look this afternoon
|
Yep, definitely some wrong logic here: {
outbuf->n_add_for_cb += length;
evbuffer_chain_insert(outbuf, chain);
/* we need to subtract whatever we don't need */
evbuffer_drain(outbuf, offset);
} If I recall, there may have been a note in the documentation about this, but yeah. This basically means Libevent is assuming your file was first thing added to a newly created bufferevent.
|
when evbuffer_add_file is called and mmap is used, if the offset argument is >0, a mistake happens: add_file removes "offset" byts from the front of the evbuffer. So that means any data that was previously on the buffer is trimmed off by "offset" bytes. Whoops. A onelinter fix: don't use evbuffer_drain for the offset, instead, just modify the misalign variable on the newly created chain.
See <libevent/libevent#306> for details.
afca576 Attemps to fix the issue, but I don't think it fully fixes the issue. |
I can confirm that afca576 fixes the issue. My comprehension of the bug was that buffer was drained as if evbuffer_add_file was the first thing appended to it. But my gist showed that offset was broken even when evbuffer_add_file was first. I must be missing something… |
Looking at this again, and in your case you are using P.S. during looking at this, it should mmap with |
And even more, right now if offset > |
Also I'm suggesting you to switch to 2.1.8, it should be compatible with 2.0. |
Thanks for the insight. I'll switch to 2.1.8 but right now I'm not using add_file anymore :) |
Bunch of fixes for evbuffer_add_file(). * evbuffer_add_file-2.0-fixes: Cover evbuffer_add_file() with offset evbuffer_add_file: do not use evbuffer_remove(), instead calc offset for mmap() evbuffer_add_file: munmap() correct size on mmap() failure evbuffer_add_file: fix endless loop when file does not have such amount of data Fixes: #306
Hi everyone! I just pushed a few fixes for evbuffer_add_file(), and now it should for this case too. It will be great if somebody will have time to test them! |
Documentation and common sense suggest that
evbuffer_add_file(outbuf, fd, offset, length)
should strictly append tooutbuf
, as otherevbuffer_add_*
methods do, and that the offset should be the offset within the file.However, at least when using
mmap
,evbuffer_add_file
actually skips a prefix of the buffer instead. The difference is significant when the buffer is already non-empty.I'm attaching a program to reproduce this behavior.
This occurs both on libevent 2.0.21-stable and the latest master head (d56efd9, roughly 2.1.5-beta).
evbuffer_add_file_bug.c.txt
The text was updated successfully, but these errors were encountered: