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

[Julian Bui <julianbui@xxxxxxxxx>]

Oh, one more thing.  I would really like to verify that there is indeed an event still pending - because I can at least restart the dispatch loop if there is an event pending.  But I have not been able to correctly use event_pending for some reason.  My code is below and it always prints "event is not pending" regardless of whether or not the dispatch loop is running.  The code sets up a persistent event that will handle every incoming connection to my server.  I would expect that at some point it would print out that the event is pending...because like I said, this code DOES work most of the time, and if it's not pending I have no idea why the handlers would even still be triggered.

struct event* my_event = event_new(s_event_base, server_socket, EV_READ | EV_PERSIST, &TileSocketServer::onAccept, (void*) client);

      if(my_event != NULL)

      {

         int add_err = event_add(my_event, NULL);

         if(add_err != 0)

            cout << "add_err:" << add_err << endl;

         int is_evt_pending = event_pending(my_event, EV_READ | EV_PERSIST, NULL);

         if(is_evt_pending == 1)

         {

            cout << "event is still pending" << endl;

         }

         else

         {

            cout << "event is still pending" << endl;

         }

On Tue, Jun 12, 2012 at 9:47 AM, 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"

> 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?

Please let me know.

Thanks for all your help

-Julian

On Fri, Jun 8, 2012 at 1:10 PM, Nick Mathewson <nickm@xxxxxxxxxxxxx> wrote:

On Thu, Jun 7, 2012 at 4:59 PM, Julian Bui <julianbui@xxxxxxxxx> wrote:
> Hi everyone,
>
> I am having trouble with my libevent 2.0.18 server.  The dispatch loop keeps
> returning -1 and I cannot determine the cause.
>
> I have not tried searching the mailing list as there does not seem to be a
> search option (http://archives.seul.org/libevent/users/)

Step one might be to build with debugging support and try that log
trick again, with debugging logs enabled; that might shed some light
on what's going on.

It sounds (Based on your mention of WSAGetLastError()) like you're
using windows here.  The only ways that I can see for win32select's
win32_dispatch functino to return -1 are if select() returns -1, or
realloc returns -1.

A select() failure seems likelier.  You could set a debugging
tracepoint at the part of win32_dispatch that says:
  if (res <= 0) {
     return res;
  }
and see if it ever returns with res = -1, and if so what the value of
WSAGetLastError is.  Or you could insert a printf there if you don't
want to mess with the debugger.

Do any of the error codes in the documentation for select() seem
plausible to you?  The likeliest one as far as I can tell is that
there is a nonexistent (or no-longer-existent) socket still in the
list of sockets that select() is looking at.
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.