Re: [Libevent-users] event_base_dispatch returning -1 - help debugging

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

On Tue, Jun 12, 2012 at 3:08 PM, Dave Hart <davehart@xxxxxxxxx> wrote:
> On Tue, Jun 12, 2012 at 4:47 PM, Julian Bui <julianbui@xxxxxxxxx> wrote:
>> Thanks for the quick response, Nick.
>>
>>>  Step one might be to build with debugging support
>>
>> Ah, I didn't realize debugging required you to build with support for it.
>>
>> I am using windows and have built with just `nmake` in visual studio.  What
>> is the preferred method of building in windows?  When I use the visual
>> studio command line, I cannot seem to use configure.  `configure`  and
>> `configure --enable-debug-mode` show "is not recognized as an internal or
>> external command, operable program or batch file"
>
> configure scripts generally don't work on Windows.  If you search
> configure.ac for debug-mode you should find the snippet that handles
> that option.  On systems where configure works, the resulting
> selection is enacted by a #define in config.h.  If you arrange for the
> same #define to be in place for libevent and your code, you'll get the
> same debugging-capable libevent.

The autoconf script works fine on windows under mingw.  Under nmake,
the best option is probably to find the right option like Dave says,
and then add it to WIN32-Code/event2/event-config.h .

>>> A select() failure seems likelier
>>
>> I think I might possibly be misunderstanding the usage of libevent.  I
>> thought libevent abstracts away the select mechanism so I don't have to deal
>> with it.  When I was looking at example code, they never once had to deal
>> with the underlying mechanism like select().  Could you possibly comment on
>> this?  What is the general strategy/structure/architecture of a program if I
>> am to use both libevent and select()?  Is there any example code that shows
>> this interaction?
>
> You're misunderstanding Nick's response.  He's trying to find the root
> cause of the failure, which necessarily means looking inside the
> libevent "black box" to its implementation.

For what it's worth, I think the issue is not necessarily a bug in the
Libevent code here.  Like I said, it is much likelier that there is
some event still added whose socket has closed, or which was never
open, or something like that.  I think this is making the select()
call inside win32_dispatch() fail.  If I'm guessing right, the right
fix is probably to find that event and event_del() it before closing
its socket.

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