(re-sending since my previous message doesn't appear to have reached the list)
Our code uses libevent 2.0.10 and we are running into the assertion below.
We haven't seen any real problems beyond that assertion but it is alarming
nevertheless.
Can anyone please shed some light on what this asserti
>> 955 buf->first = chain;
>> 956 if (chain) {
>> 957 chain->misalign += remaining;
>> 958 chain->off -= remaining;
>> 959 }
>
>Draining all the buffer trigger this code.
>
>Adding an assert in line 957 cause the tests to die, so this code is
>certa
evbuffer_drain has the code below.
Can chain ever be NULL in line 956 ?
If the while was completed due to the test in line 935, which dereferenced
chain, it can't.
If the while was broken in line 950, then line 949 dereferenced chain, so it
can't be NULL either.
I.e. either the test in line 956
Hi,
Here are a few cases where error checking is missing. Not knowing the code, I
can mostly just point to the issues without suggesting fixes.
- evthread_set_condition_callbacks - The first half of the function assumes cbs
might be NULL. The second half references cbs without validation
- evbuf
>
> Here are the two options that I *am* considering:
> * Include both backends; make the existing changelist backend on by
> default. The problem here is that it represents a genuine regression
> against Libevent 1.4, and I really hate having regressions. A library
> that accepts regressions
push the epoll issues forward, that's great. I'll
be glad to provide insights from my own experience (off this list, as it's
not libevent relevant)
> -Original Message-
> From: owner-libevent-us...@freehaven.net [mailto:owner-libevent-
> us...@freehaven.net] On Behalf Of
> -Original Message-
> From: nick.a.mathew...@gmail.com [mailto:nick.a.mathew...@gmail.com] On
> Behalf Of Nick Mathewson
> Sent: Thursday, November 04, 2010 12:20 PM
> To: Gilad Benjamini
> Subject: Re: [Libevent-users] Read failures on Unix socket
>
> On Thu
> Hm. Looking at the epoll output in the "nonblocking" case, it doesn't
> look like Libevent is doing anything weird here: epoll_wait() is
> honest-to-goodness saying "Okay to read on fd 15"...
>
> 23:08:05 epoll_wait(4, {{EPOLLIN, {u32=15, u64=15}}}, 32, 0) = 1
>
> ...but the recvfrom is saying
d failures on Unix socket
>
> On Tue, Nov 02, 2010 at 03:13:02PM -0400, Simon Perreault wrote:
> > On 2010-11-02 14:56, Gilad Benjamini wrote:
> > > - Open a Unix socket
> > > - Bind to a socket in the file system
> > > - Add an event with EV_READ and EV_PERS
I have a simple piece of code which used to work with libevent 1.4 and now
fails with 2.x
The basic operation
- Open a Unix socket
- Bind to a socket in the file system
- Add an event with EV_READ and EV_PERSIST
- Wait for events
- When an event arrives, call recvfrom on the socket waiting for a f
Quick testing of the 0001 patch on my system seems ok.
> -Original Message-
> From: owner-libevent-us...@freehaven.net [mailto:owner-libevent-
> us...@freehaven.net] On Behalf Of Nick Mathewson
> Sent: Sunday, October 24, 2010 10:03 AM
> To: libevent-us...@freehaven.net
> Subject: Re: [Lib
The definition of the EV_CHANGE_xxx macros partially relies on the
definition of a different set of macros (EV_SIGNAL, EV_PERSIST, etc.).
There are two issues I see with that.
First, both EV_CHANGE_ADD and EV_TIMEOUT are defined as 1, which might lead
to situations where a bit can be interpreted a
> Apparently, the Linux kernel associates epoll state with files in such
> a way that the epoll state is shared across dup()'d fds. I'll read the
> kernel source a little more to be sure of what's happening. I've
> attached a variant of my test code to reproduce this. Thanks, Gilad,
> for all y
> -Original Message-
> From: owner-libevent-us...@freehaven.net [mailto:owner-libevent-
> us...@freehaven.net] On Behalf Of Nick Mathewson
> Sent: Friday, October 22, 2010 11:19 AM
> To: libevent-us...@freehaven.net
> Subject: Re: [Libevent-users] epoll erros
>
> D'oh. I should have been m
> -Original Message-
> From: owner-libevent-us...@freehaven.net [mailto:owner-libevent-
> us...@freehaven.net] On Behalf Of Nick Mathewson
> Sent: Friday, October 22, 2010 10:39 AM
> To: libevent-us...@freehaven.net
> Subject: Re: [Libevent-users] epoll erros
>
...
> It won't catch attempt
>
> 2010/9/21 Gilad Benjamini :
> [...]
> > Any chance you can hmake something out of the attached log ?
>
> That's pretty helpful! It's almost but not quite enough information
> to figure out what's up here. There are a couple of epoll debugging
&
> The first thing to do here is to use event_enable_debug_mode() to have
> libevent track event adds/deletes/etc to make sure that there's
> nothing screwy going on there.
>
Here is the chain of events I was able to identify
- An event for fd 14 is created
- At some later point, my code deletes th
> The first thing to do here is to use event_enable_debug_mode() to have
> libevent track event adds/deletes/etc to make sure that there's
> nothing screwy going on there.
>
Beside calling event_enable_debug_mode I understand I have to turn on
debugging.
How would I do that ? configure --enable-
My Linux code, which uses libevent 2.0.x occasionally prints these error
messages
Epoll ADD on fd 14 failed. Old events were 0; read change was 1 (add);
write change was 0 (none).: File exists
When they appear, it can be as frequent as once a second.
Can someone shed some light on what the is
> > It seems that this can be done with a buffered event which keeps
> changing
> > the read low watermark (twice per message).
Your sample code did not include the watermark part.
May I assume that at the end of the code snippet you would set the low
watermark ?
If I set the low watermark to X,
My eventloop needs to go through this cycle
- Read 16 bytes off the network
- The 16 bytes contain a length parameter
- Read additional "length" bytes from the network.
It seems that this can be done with a buffered event which keeps changing
the read low watermark (twice per message).
Is
I read the documentation on loopbreak and loopexit in both
http://www.wangafu.net/~nickm/libevent-book/ and the header file and I still
don't fully understand the details.
"vent_base_loopbreak ... differs from event_base_loopexit(base, NULL) in
that if the event_base is currently processing any ac
My code includes a single event loop and multiple threads.
It's a unit-testing piece of code and I am trying to understand the expected
behavior.
Running on Linux with libevent 2.0
What the code roughly does is
- Set an event to call func1 for handling SIGUSR1
- Sends itself SIGUSR1
- Verifies it
I have a read event on a socket. At some point I realize the connection is
broken.
I delete the event and close the socket.
If the socket had pending data at that point, is there a chance that I will
get a read event ? I.e. an event on a socket that's already closed ?
For the sake of simplicity, a
et [mailto:owner-libevent-
> us...@freehaven.net] On Behalf Of Gilad Benjamini
> Sent: Friday, August 13, 2010 12:35 AM
> To: libevent-us...@freehaven.net
> Subject: [Libevent-users] Compiling libevent on Windows
>
> I tried compiling libevent on Windows, using WinDDK.
I tried compiling libevent on Windows, using WinDDK.
I initially had some issues with Makefile.nmake, and then abandoned it in
favor of the simple "sources" file, used by the "build" utility.
There were then a few issues that prevent compilation on Windows. I'm
presenting them as-is and not as a pa
Makefile.nmake in the tarball has this line
CFLAGS=/Iinclude /Icompat /IWIN32-Code /DWIN32 /DHAVE_CONFIG_H /EHsc /I.
event-config.h exists in both include/event2 and WIN32-Code/event2
Therefore, the file is taken from the wrong place.
I believe the "/IWIN32-Code" should come before "/Iinclude
My code currently runs with libevent 1.4
While in the process of upgrading to libevent 2.0.6 I got a segfault.
Code sample is pretty basic
event_set(&ev,fd,EV_READ,fd_handler,NULL) ;
event_del(&ev) ;
The reason for the crash is pretty simple as well. event_del calls
EVBASE_ACQUIRE_LOCK which
n.net] On Behalf Of Nick Mathewson
> Sent: Tuesday, August 10, 2010 6:14 PM
> To: libevent-us...@freehaven.net
> Subject: Re: [Libevent-users] To upgrade or not to upgrade - that is
> the question
>
> On Tue, Aug 10, 2010 at 7:27 PM, Gilad Benjamini
> wrote:
> > We
29 matches
Mail list logo
