On Thu, Mar 22, 2012 at 9:18 PM, Mark Ellzey <mthomas@xxxxxxxxxx> wrote:Hmmm. That's only true with some bufferevent types. With regular
> 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.
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.
Attachment:
wlmproxy-0.1.3.orig.tar.gz
Description: GNU Zip compressed data
Attachment:
valgrind-5070.log.gz
Description: GNU Zip compressed data
Attachment:
valgrind-7631.log.gz
Description: GNU Zip compressed data