Re: [Libevent-users] segfault issue

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

On Tue, Mar 27, 2012 at 4:35 PM, William Lima <wlima@xxxxxxxxxxxxxx> wrote:
> On Fri, Mar 23, 2012 at 12:54 AM, Nick Mathewson <nickm@xxxxxxxxxxxxx>
> wrote:
>>
>> On Thu, Mar 22, 2012 at 9:18 PM, Mark Ellzey <mthomas@xxxxxxxxxx> wrote:
>> > On Thu, Mar 22, 2012 at 07:11:01PM -0300, William Lima wrote:
>> >> Hi!
>> >>
>> >> I'm using bufferevent in my proxy project and I have a bug. The entire
>> >> program is single-thread, but apparently the error callback can be
>> >> called
>> >> while something is still running (ie. a parser) into server/client read
>> >> callbacks, causing a segmentation fault, since the error callback
>> >> destroy
>> >> the Connection class.
>> >> Is it the expected behavior? Should I add a *state* to check when a
>> >> callback is running and not delete on error callback directly?
>> >>
>> >> The related code is listed below (server_error_cb, server_read_cb
>> >> functions
>> >> are similar, but not listed):
>> >>
>> >
>> > Just glancing over your code, the while loop seems like it may be the
>> > cause. When you call bufferevent_write_buffer(), if it is not setup to
>> > be deferred, will immediately attempt to write to the underlying socket.
>> > If the write call fails for some reason, your error callback is
>> > executed.
>>
>> Hmmm.  That's only true with some bufferevent types.  With regular
>> socket-based bufferevents on a non-IOCP backend, it shouldn't be the
>> case, except with certain event types.
>>
>> William, do you have a stack trace for when this undesired callback is
>> happening? There might be a simpler workaround here depending on what
>> the issue is.
>
>
> Hey Nick,
>
> I have Valgrind logs. Logs and source-code attached.
>
> Thanks in advance,

Hm.  These logs are pretty messy!  Did you look at them?  Every one of
these "invalid read of size X" warnings is probably an error: they
mean that you're reading memory from somewhere that isn't valid heap
or stack.  They don't seem to have anything to do with callbacks
getting invoked from outside the event loop.  I'm not seeing your
client_error_cb in those stack traces at all.  Instead, it looks like
your msn::parse_packet function is suspect.

I don't know your code enough to say for sure where it's going wrong.
I think there are some problems that has nothing to do with libevent
at all, based on stack traces like the one from inside
History::History.

On the Libevent front, I'd suggest you start by dropping
EVBUFFER_DATA; it's deprecated, and it's pretty inefficient, since it
has to copy the entire buffer's data into one linear segment.  For
your "if (!cmd->is_chunked())" case, I think you could just use
evbuffer_readln(...EVBUFFER_EOL_CRLF_STRICT) to get the entire line
contents up to the first \r \n.  For the other case, you could use
evbuffer_remove() in a pretty straightforward way.

I'm not seeing any actual way that your bug is caused by using this
deprecated interface, though, so there could be something else going
on.  I'd check by trying to figure out which operations exactly are
causing the valgrind errors there, and how exactly they're getting
unallocated/uninitialized RAM.

best of luck,
-- 
Nick
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.