Alexey Simak | 13 May 16:32 2015
Picon

Bug in win32_dispatch?

Hi,

We are using libevent in the next scenario:

1) Create nonblocking socket.
2) Call "connect()" on it.
3) Create an event for socket and wait in event_base_dispatch() for socket 
events.
4) Check for EV_TIMEOUT, EV_READ or EV_WRITE passed to callback.

There is a problem on win32:

When we are connecting to a destination that is not listening on the socket, 
we receive
EV_WRITE event, which is not correct from my point of view.

The problem is in win32_dispatch from win32select.c:

    res = select(fd_count,
             (struct fd_set*)win32op->readset_out,
             (struct fd_set*)win32op->writeset_out,
             (struct fd_set*)win32op->exset_out, tv);

    EVBASE_ACQUIRE_LOCK(base, th_base_lock);

    event_debug(("%s: select returned %d", __func__, res));

    if (res <= 0) {
        return res;
    }
(Continue reading)

Mark Ellzey | 12 May 20:22 2015
Picon

The state of cmake & libevent


As you may or may have not noticed, libevent-2.1 introduced cmake build
support. You may have also noticed that it isn't 100% compat with the
output of autotools

CMake is a step in the right direction, and I'm personally a huge fan,
but unfortunately the current state of the CMake system in libevent is 
complex, and obviously unfinished.

Over the next few weeks (on and off) I will be rewriting the CMake system to match
100% with autotools, and makes a bit more sense.

So in the mean time, it would probably be for the best if developers
avoid building with cmake, you know, for our future sanity!

Cheers!

Mark
***********************************************************************
To unsubscribe, send an e-mail to majordomo <at> freehaven.net with
unsubscribe libevent-users    in the body.

Nick Mathewson | 6 May 14:59 2015
Picon

Adding Mark Ellzey as a Libevent maintainer

Hi, all!

As you've noticed, I've been pretty slow with Libevent development
lately, due to the pace of my day job at Tor.  So I'm asking Mark
Ellzey, longtime contributor and libevhtp guy, to step in as another
maintainer.  I've given him commit and admin access to the various
repositories; let's see how it goes.  Welcome, Mark!

I'm not stepping down, and I hope that having another maintainer
actually makes it so I can spend *more* time on Libevent, by having
somebody to help me focus.

Top priority for a while is probably going to be getting 2.1 out the door.

"Soon I Hope."

peace,
--

-- 
Nick Mathewson
***********************************************************************
To unsubscribe, send an e-mail to majordomo <at> freehaven.net with
unsubscribe libevent-users    in the body.

Macrux | 23 Apr 16:32 2015
Picon

libevent 1.4.x compile error on windows 7/8

Hi there,

I'm trying to build libevent 1.4.x  stable release on windows, using these steps:

  • From there, extract the libevent source to the location of your choice. Make note of this location, as you will need it later.
  • Open the Visual Studio Command Prompt (or execute the appropriate VCVARSALL.bat for your required environment in a terminal).
  • Navigate to the location where you extracted the libevent source, then execute the following commands: nmake /F Makefile.nmake
But I'm running on this error:
Note: I'm using MS Visual Studio 10 on Windows 7x64

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
C:\libevent-1.4.14b-stable>nmake /F Makefile.nmake

Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
Copyright (C) Microsoft Corporation.  All rights reserved.

        cl /Iinclude /Icompat /IWIN32-Code /DWIN32 /DHAVE_CONFIG_H /I. /Ox /W3 /wd4996 /nologo /c WIN32-Code\win32.c
win32.c
WIN32-Code\win32.c(150) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
        cl /Iinclude /Icompat /IWIN32-Code /DWIN32 /DHAVE_CONFIG_H /I. /Ox /W3 /wd4996 /nologo /c event.c buffer.c evbuffer.c log.c evutil.c strlcpy.c signal.c
event.c
buffer.c
buffer.c(203) : warning C4267: 'return' : conversion from 'size_t' to 'int', possible loss of data
buffer.c(320) : warning C4244: '=' : conversion from '__int64' to 'unsigned int', possible loss of data
buffer.c(321) : warning C4244: '=' : conversion from '__int64' to 'unsigned int', possible loss of data
buffer.c(460) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
buffer.c(502) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data
evbuffer.c
evbuffer.c(111) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
log.c
evutil.c
evutil.c(98) : warning C4244: '=' : conversion from 'SOCKET' to 'int', possibleloss of data
evutil.c(111) : warning C4244: '=' : conversion from 'SOCKET' to 'int', possible loss of data
evutil.c(125) : warning C4244: '=' : conversion from 'SOCKET' to 'int', possible loss of data
strlcpy.c
signal.c
Generating Code...
        lib /nologo event.obj buffer.obj evbuffer.obj  log.obj evutil.obj  strlc py.obj signal.obj win32.obj /out:libevent_core.lib
        cl /Iinclude /Icompat /IWIN32-Code /DWIN32 /DHAVE_CONFIG_H /I. /Ox /W3 /wd4996 /nologo /c event_tagging.c http.c evdns.c evrpc.c
event_tagging.c
event_tagging.c(149) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data
event_tagging.c(204) : warning C4267: 'function' : conversion from 'size_t' to ' unsigned int', possible loss of data
event_tagging.c(211) : warning C4267: 'function' : conversion from 'size_t' to ' unsigned int', possible loss of data
event_tagging.c(223) : warning C4267: 'function' : conversion from 'size_t' to ' unsigned int', possible loss of data
event_tagging.c(231) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data
http.c
http.c(102) : warning C4005: 'NI_NUMERICHOST' : macro redefinition
        C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\ws2def.h(953) : see previous definition of 'NI_NUMERICHOST'
http.c(103) : warning C4005: 'NI_NUMERICSERV' : macro redefinition
        C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\ws2def.h(955) : see previous definition of 'NI_NUMERICSERV'
http.c(145) : error C2011: 'addrinfo' : 'struct' type redefinition
        C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\ws2def.h(841) : see declaration of 'addrinfo'
http.c(278) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data
http.c(283) : warning C4267: '+=' : conversion from 'size_t' to 'int', possible loss of data
http.c(554) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
http.c(800) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
http.c(899) : warning C4018: '>=' : signed/unsigned mismatch
http.c(934) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
http.c(2284) : warning C4244: '=' : conversion from 'SOCKET' to 'int', possible loss of data
http.c(2739) : warning C4244: '=' : conversion from 'SOCKET' to 'int', possible loss of data
http.c(2762) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data
http.c(2852) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data
evdns.c
evdns.c(1000) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
evdns.c(1223) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data
evdns.c(1402) : warning C4244: 'initializing' : conversion from '__int64' to 'const unsigned int', possible loss of data
evdns.c(1409) : warning C4244: '+=' : conversion from '__int64' to 'off_t', possible loss of data
evdns.c(1413) : warning C4244: 'initializing' : conversion from '__int64' to 'const unsigned int', possible loss of data
evdns.c(1420) : warning C4244: '+=' : conversion from '__int64' to 'off_t', possible loss of data
evdns.c(1657) : warning C4267: 'function' : conversion from 'size_t' to 'const int', possible loss of data
evdns.c(1676) : warning C4267: 'function' : conversion from 'size_t' to 'const int', possible loss of data
evdns.c(1688) : warning C4267: 'function' : conversion from 'size_t' to 'const int', possible loss of data
evdns.c(1736) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data
evdns.c(2133) : warning C4244: '=' : conversion from 'SOCKET' to 'int', possible loss of data
evdns.c(2239) : warning C4267: 'initializing' : conversion from 'size_t' to 'const int', possible loss of data
evdns.c(2435) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
evdns.c(2494) : warning C4267: 'initializing' : conversion from 'size_t' to 'const int', possible loss of data
evrpc.c
evrpc.c(196) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
Generating Code...
NMAKE : fatal error U1077: 'C:\msvisualstudio\VC\BIN\amd64\cl.EXE' : return code '0x2'
Stop.

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------



Right now I'm stucked since I need to build the libevent to be used in other project build. I will really appreciate any help you could give me.

Thanks in advance,

Néstor.


Pradosh Mohapatra | 19 Apr 07:24 2015
Picon

libevent 2.0.22-stable - infinite loop

Hi guys,

My code is getting into an infinite loop while using the http client APIs with retries, when the server is unreachable.

The http client block is simple:

  http_conn_ = evhttp_connection_base_new(evq_, NULL, server_, http_port_);

  evhttp_connection_set_timeout(http_conn_, 3);
  evhttp_connection_set_retries(http_conn_, 3);

  evhttp_make_request(http_conn_, req, type, api);

The signature of the loop has been reported before (e.g.
http://archives.seul.org/libevent/users/Mar-2012/msg00000.html), i.e. in this block:

  while ((ev = min_heap_top(&base->timeheap))) {
    if (evutil_timercmp(&ev->ev_timeout, &now, >))
      break;

    /* delete this event from the I/O queues */
    event_del_internal(ev);

    event_debug(("timeout_process: call %p",
                 ev->ev_callback));
    event_active_nolock(ev, EV_TIMEOUT, 1);
  }

with the 'ev' being the retry_ev with evhttp_connection_retry() callback.

Looking at http.c, the following snippet looked a bit suspicious:

static void
evhttp_connection_cb_cleanup(struct evhttp_connection *evcon)
{
  struct evcon_requestq requests;

  if (evcon->retry_max < 0 || evcon->retry_cnt < evcon->retry_max) {
    evtimer_assign(&evcon->retry_ev, evcon->base, evhttp_connection_retry, evcon);
    /* XXXX handle failure from evhttp_add_event */
    evhttp_add_event(&evcon->retry_ev,
                     MIN(3600, 2 << evcon->retry_cnt),
                     HTTP_CONNECT_TIMEOUT);
    evcon->retry_cnt++;
    return;
  }
  <snip>
}

Before calling evtimer_assign() etc., shouldn't this be checking if retry_ev is added/active/pending?

Doing the same experiment without setting retries works fine, of course.

Any guidance on how to debug this?

Thanks,
- Pradosh
***********************************************************************
To unsubscribe, send an e-mail to majordomo <at> freehaven.net with
unsubscribe libevent-users    in the body.

Maciej Szeptuch | 31 Mar 14:06 2015

evbuffer_write with empty buffer

Hi,

I have a question about evbuffer_write.
I couldn't find it anywhere, but am I required to check if buffer is
not empty before calling evbuffer_write or it returning -1 (and not
setting errno!) in this situation is a bug?

Thanks,
Maciej Szeptuch
***********************************************************************
To unsubscribe, send an e-mail to majordomo <at> freehaven.net with
unsubscribe libevent-users    in the body.

Mark Ruys | 24 Mar 10:35 2015

How to break out libevent's dispatch loop

Posted also at http://stackoverflow.com/questions/29219314/how-to-break-out-libevents-dispatch-loop

I've implemented a tiny webserver in a separate thread using the nice libevent library. The webserver runs event_base_dispatch() to process all events. What I need is a way to break out this dispatch loop from the main thread. 

It boils down to the following C++ code:

  #include <stdlib.h>
#include <signal.h>
#include <thread>
#include <evhttp.h>

struct event_base *eb;
std::thread t;

static volatile sig_atomic_t bailout = false;

void my_signal_handler(int) {
bailout = true;
}

void onRequest(evhttp_request *req, void *) {
struct evbuffer *OutBuf = evhttp_request_get_output_buffer(req);
evbuffer_add_printf(OutBuf, "<html><body>Testing 1-2-3</body></html>");
evhttp_send_reply(req, HTTP_OK, "OK", OutBuf);
}

void dispatch() {
eb = event_base_new();
struct evhttp *http = evhttp_new(eb);
evhttp_set_gencb(http, &onRequest, NULL);
evhttp_bind_socket_with_handle(http, "0.0.0.0", 5555);
event_base_dispatch(eb);
}

int main() {

struct sigaction sigIntHandler;
sigIntHandler.sa_handler = my_signal_handler;
sigemptyset(&sigIntHandler.sa_mask);
sigIntHandler.sa_flags = 0;
sigaction(SIGINT, &sigIntHandler, NULL);

t = std::thread { &dispatch };

while ( ! bailout ) {
std::this_thread::sleep_for(std::chrono::seconds(1));
}

event_base_loopexit(eb, NULL);

t.join();
}

The behavior is that if you run the program, request a page, abort the program by Ctrl-C, the event_base_dispatch() keeps running *until* you fetch another web page. Only then the loop aborts and the program terminates. What I need is that the dispatch loop is exited immediately, not after the next page request. Is this possible?

Thanks,

Mark

Anatol Pomozov | 20 Mar 22:36 2015
Picon

http client code memory leak

Hi,

I am implementing a HTTP server application that utilizes HTTP client in its generic handler. i.e. on receiving a request it makes several requests to other servers and after it gets responses back it finalizes original request. Here is pseudo code of the generic callback:

global_base;
generic_callback() {
  url = get_user_data(req);
  for (server : remote_servers) {
     evcon = evhttp_connection_base_new(global_base, ..);
     req = evhttp_request_new(client_request_done, req, url);
     evhttp_make_request(evcon, req);
  }
}

The code works fine. I've decided to check it for memory leaks using valgrind and discovered that a lot of memory is lost in evhttp_connection_base_new(). I believe my code should cleanup the connections I've created.

I checked libevent examples and googled but I did not find how to make this cleanup properly. All examples show HTTP client with single connection created in main() function that is cleaned after event_base_dispatch() is over. But in my case I dynamically create connection and I need to clean it when it is unused. I was trying to run the evhttp_connection_free() function in client_request_done callback (the one passed to evhttp_request_new), but evhttp_request_get_connection(req) returns NULL. It means the connection object is not accessible in the callback function. Hmm... How do I expect to free the connection then?

I see version 2.1 has function evhttp_connection_free_on_completion() but it still does not help to prevent leaks in evhttp_connection_base_new().

Here is the code that I was trying to profile:
  https://github.com/anatol/pacoloco/blob/master/hub.c#L213

And here is the valgrind report ran against current HEAD (a77a82a03f85):
  https://gist.github.com/anatol/7a44648af62627da46a4

How to prevent this memory leak in the http client code?
Linus Aranha | 10 Mar 19:21 2015
Picon

Libevent-2.1.5-beta - Couple issues


Hi libevent developers,

I was not sure if we have to raise bugs for the beta version - libevent-2.1.5 so here is an email to begin. We would really appreciate a fix for issue 1 soon.

Thanks,
Linus Aranha

Issue 1)
Cleanup ordering issue in evdns_base_free_and_unlock - gives rise to invalid reads/writes

I found an issue in the code for libevent-2.1.5-beta in the cleanup function -  evdns_base_free_and_unlock.

Below is the valgrind report. It looks we end up accessing the nameserver (evdns.c:662) pointer part of the requests structure after it is cleaned up at evdns.c:4011.

The issue is not present in 2.0.21-stable.

Maybe we could just re-order the cleanup so the nameservers are cleaned up in the end? That should prevent the invalid reads and writes.

==722== Invalid read of size 4
==722==    at 0x4C4CB80: request_finished (evdns.c:662)
==722==    by 0x4C56228: evdns_base_free_and_unlock (evdns.c:4022)
==722==    by 0x4C56483: evdns_base_free (evdns.c:4062)
==722==    by 0x404A0B: dummy_function1 (file.c:xxx)
==722==    by 0x405F61: dummy_function2 (file.c:xxx)
==722==    by 0x40BDD5: dummy_function3 (file.c:xxx)
==722==    by 0x40EED2: dummy_function4 (file.c:xxx)
==722==    by 0x4C38D72: event_persist_closure (event.c:1531)
==722==    by 0x4C3905B: event_process_active_single_queue (event.c:1590)
==722==    by 0x4C39684: event_process_active (event.c:1689)
==722==    by 0x4C39DE0: event_base_loop (event.c:1912)
==722==    by 0x4C3970C: event_base_dispatch (event.c:1723)
==722==    by 0x404C46: main (file.c:xxx)
==722==  Address 0x5dfa710 is 448 bytes inside a block of size 456 free'd
==722==    at 0x4A0739B: free (vg_replace_malloc.c:473)
==722==    by 0x405AB7: dummy_free (file.c:xx)
==722==    by 0x4C3EE8F: event_mm_free_ (event.c:3462)
==722==    by 0x4C5610F: evdns_nameserver_free (evdns.c:3995)
==722==    by 0x4C56149: evdns_base_free_and_unlock (evdns.c:4011)
==722==    by 0x4C56483: evdns_base_free (evdns.c:4062)
==722==    by 0x404A0B: dummy_function1 (file.c:xxx)
==722==    by 0x405F61: dummy_function2 (file.c:xxx)
==722==    by 0x40BDD5: dummy_function3 (file.c:xxx)
==722==    by 0x40EED2: dummy_function4 (file.c:xxx)
==722==    by 0x4C38D72: event_persist_closure (event.c:1531)
==722==    by 0x4C3905B: event_process_active_single_queue (event.c:1590)
==722==    by 0x4C39684: event_process_active (event.c:1689)
==722==    by 0x4C39DE0: event_base_loop (event.c:1912)
==722==    by 0x4C3970C: event_base_dispatch (event.c:1723)
==722==    by 0x404C46: main (file.c:xxx)

Issue 2)
Found memory leak

Valgrind stacktrace is below.

==722== 792 bytes in 3 blocks are definitely lost in loss record 34 of 65
==722==    at 0x4A05F80: malloc (vg_replace_malloc.c:296)
==722==    by 0x4059EA: dummy_malloc (dummy.c:xx)
==722==    by 0x4C3ED1B: event_mm_calloc_ (event.c:3403)
==722==    by 0x4C578C8: evdns_getaddrinfo (evdns.c:4649)
==722==    by 0x4047A7: dummy1 (dummy.c:xxx)
==722==    by 0x404933: dummy2 (dummy.c:xxx)
==722==    by 0x41F412: dummy3 (dummy.c:xxx)
==722==    by 0x41EEE1: dummy4 (dummy.c:xxx)
==722==    by 0x404CF8: dummy5 (dummy.c:xxx)
==722==    by 0x4C390FE: event_process_active_single_queue (event.c:1597)
==722==    by 0x4C39684: event_process_active (event.c:1689)
==722==    by 0x4C39DE0: event_base_loop (event.c:1912)
==722==    by 0x4C3970C: event_base_dispatch (event.c:1723)
==722==    by 0x404C46: main (dummy.c:xxx)
==722==


Bill Vaughan | 25 Feb 15:25 2015
Picon

assert in event_del_internal()

Hi all,

We have been seeing a fairly hard to reproduce problem with crashes inside of libevent in our overnight scale tests.  We run 15,000 clients in an  ESX environment and have been getting one or two crashes per night. We are running libevent 2.0.21 on this test system. We have moved to 2.0.22 on our development branch.

The application is relatively large and complex and it is quite possible we have a memory trampler, but valgrind tests so far are clean and code inspection hasn't found anything.

We recently ran the overnight test with libevent debugging enabled (event_enable_debug_mode(), evthread_enable_lock_debuging()) and had the following assert in the libevent debug hash table:


[err] event_del_internal: noting a del on a non-setup event 0xb56248a0 (events: 0x0, fd: -1, flags: 0x80)
=== Command detached from window (Mon Feb 23 23:13:14 2015) ===
=== Command terminated with signal 6 (core file generated) (Mon Feb 23 23:13:14 2015) ===
 

Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
Core was generated by `./vtc_app -Script-Client29-333'.
Program terminated with signal 6, Aborted.
#0  0xb775e424 in __kernel_vsyscall ()
(gdb) where
#0  0xb775e424 in __kernel_vsyscall ()
#1  0xb747a1df in raise () from /lib/i386-linux-gnu/libc.so.6
#2  0xb747d825 in abort () from /lib/i386-linux-gnu/libc.so.6
#3  0x0814bc31 in event_exit (errcode=-559030611) at log.c:79
#4  0x0814bd53 in event_errx (eval=-559030611,
    fmt=0x82105b0 "%s: noting a del on a non-setup event %p (events: 0x%x, fd: %d, flags: 0x%x)") at log.c:136
#5  0x0813dc07 in event_del_internal (ev=<optimized out>) at event.c:2265
#6  event_process_active_single_queue (activeq=<optimized out>, base=<optimized out>) at event.c:1324
#7  event_process_active (base=<optimized out>) at event.c:1420
#8  event_base_loop (base=0xb6a09d58, flags=2) at event.c:1621
#9  0x08073960 in VtcCommMgr::ThreadLoop (this=0xacdcc008) at vtc_app/vtc_comm_mgr.cpp:844
#10 0xb772cd4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#11 0xb753ad3e in clone () from /lib/i386-linux-gnu/libc.so.6


So looks like an event fired that was not in the hash table, which should only happen if the event was freed, from what I can tell. This points to a clear application bug, however, there is a bit more to the store.

Examining the libevent hash table that tracks the events, we found this:

== 667 0xb5e248f0 ==
     {node = {hte_next = 0x0}, ptr = 0x0, added = 0}
global_debug_map.hth_table[666].node.hte_next
== 668 0xb5600858 ==
     {node = {hte_next = 0x0}, ptr = 0xb5600808, added = 1}
global_debug_map.hth_table[667].node.hte_next
== 669 0xb5624950 ==
     {node = {hte_next = 0x0}, ptr = 0xb5624900, added = 1}
global_debug_map.hth_table[668].node.hte_next
== 676 0x97a5390 ==
     {node = {hte_next = 0x0}, ptr = 0x97a50a8, added = 0}
global_debug_map.hth_table[669].node.hte_next
 

Bucket 667 has an entry, but the pointer to the event is 0.  The hash entry should be deleted (mm_free()) when the event is freed, and have a valid event pointer otherwise, so the event likely was not freed. All of the other entries in the hash look good. The event that is currently being processed in the backtrace, 0xb56248a0, maps to bucket 667 based on the hash algorithm:  ((0xb56248a0 >> 6) % 769) == 667, which is our bucket. This appears to be some sort of corruption if I am understanding the hash table logic correctly.

The event base was good and our application only calls event_free() and not any of the other APIs that could free an event from the hash (event_reinit() and a couple others).

I see in the 2.0.22 release notes that a race was fixed in event_active().  Do you think that could cause this? Our next step is to move to 2.0.22 on our test system to see if the problem still happens. However, this branch of code is very close to a release, so we are very cautious about changing things without a clear cause and effect.

We have had several engineers reviewing the application code and so far have not seen any invalid libevent usages, and as I said, valgrind is clean. Clearly we are doing something wrong in the application or have found some sort of edge case within the library. And libevent 2.0.21 has been very stable as I have used it on this project and others.

The application is complicated enough that I can't easily provide code snippets that are meaningful, and since we are not sure how to reproduce the problem, I don't have any test code that can reproduce it.

All of the clients are running under Ubuntu 12.04.

Has anyone else seen anything like this?

Thanks,
-Bill



Christian Stieber | 19 Feb 10:04 2015
Picon

Do paired buffer events work?

I've been trying to use them for a while now, without much success.

I seem to be able to put data into "my" side of the pair, and it appears
on the "remote" side -- but no callbacks are called on the remote end.

    Log("WebSocket %p received %u bytes",this,(unsigned
int)TheMessage->payload_len);
    if
(bufferevent_write(MyBufferEvent,TheMessage->payload,(size_t)TheMessage->payload_len)!=0)
    {
        /* throw ... */
    }
    else
    {
        bufferevent_flush(MyBufferEvent,EV_WRITE|EV_READ,BEV_NORMAL);

        Log("MyBufferEvent has output size
%d",(int)evbuffer_get_length(bufferevent_get_output(MyBufferEvent)));
        Log("RemoteBufferEvent %p has input size %d",(struct
bufferevent*)RemoteBufferEvent,(int)evbuffer_get_length(bufferevent_get_input(RemoteBufferEvent)));

        Log("RemoteBufferEvent has reading enabled:
%s",(bufferevent_get_enabled(RemoteBufferEvent) & EV_READ) ? "yes"
: "no");

This actually gives me the expected output, such as

[2015-02-19 08:08:54] WebSocket 0x7f8f080008c0 received 4 bytes
[2015-02-19 08:08:54] MyBufferEvent has output size 0
[2015-02-19 08:08:54] RemoteBufferEvent 0x7f8f08001370 has input size 4
[2015-02-19 08:08:54] RemoteBufferEvent has reading enabled: yes

but that's it -- the callback on the remote end simply isn't called.

I can send more data to the websocket thing and it's just added to the
output buffer of the "remote" end of the pair like it should, except that
it's never used since the callbacks are never invoked.

The same applies when I run flush with a BEV_FINISHED to signal an "EOF"
-- it's not happening on the remote end.

I'm just going to try calling those callbacks myself, probably with some
testing to detect when those callbacks start working so I know to update
the code then; not currently expecting too many problems with that. The
question is whether I'm still doing something wrong, somewhere, or whether
those callbacks are only meant for "real" sockets?

I was using "2.1.4-alpha" up until a couple of hours ago; updated to
"2.1.5-beta" and ran the thing again, but it didn't seem to change
anything

***********************************************************************
To unsubscribe, send an e-mail to majordomo <at> freehaven.net with
unsubscribe libevent-users    in the body.


Gmane