Menu
▾
▴
levent-tracker — Receives new tracker entries for the libevent project
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(49) |
Dec
(6) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(2) |
Feb
(9) |
Mar
(3) |
Apr
(6) |
May
(11) |
Jun
(6) |
Jul
(11) |
Aug
(2) |
Sep
(2) |
Oct
(3) |
Nov
|
Dec
(3) |
| 2009 |
Jan
(5) |
Feb
(2) |
Mar
(6) |
Apr
(10) |
May
(9) |
Jun
(17) |
Jul
(9) |
Aug
(2) |
Sep
(10) |
Oct
(6) |
Nov
(18) |
Dec
(12) |
| 2010 |
Jan
(10) |
Feb
(5) |
Mar
(8) |
Apr
(13) |
May
(20) |
Jun
(8) |
Jul
(16) |
Aug
(23) |
Sep
(10) |
Oct
(15) |
Nov
(13) |
Dec
(16) |
| 2011 |
Jan
(8) |
Feb
(9) |
Mar
(5) |
Apr
(4) |
May
(11) |
Jun
(4) |
Jul
(3) |
Aug
(5) |
Sep
(5) |
Oct
(9) |
Nov
(6) |
Dec
(5) |
| 2012 |
Jan
(8) |
Feb
(3) |
Mar
(2) |
Apr
(7) |
May
(4) |
Jun
(2) |
Jul
(8) |
Aug
(1) |
Sep
|
Oct
(5) |
Nov
(4) |
Dec
|
| 2013 |
Jan
(3) |
Feb
(5) |
Mar
(4) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Gangaraju M P <gan...@cr...> - 2015-04-07 11:48:45
|
Hi, I'm using libevent with libcurl to handle the downloading of resources in my Application. Occasionally the app crashes with out throwing any error as the libevent is calling exit(1) in that case. on calling the function evtimer_new() the application is crashing. Enabling the logs in libevent gave the following Info event_queue_insert: 06355D48(fd -1) already on queue 1 Operation not permitted Any help is appreciated. Regards, Gangaraju |
|
From: SourceForge.net <no...@so...> - 2013-04-05 00:55:39
|
Bugs item #3610046, was opened at 2013-04-04 17:55 Message generated for change (Tracker Item Submitted) made by kot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3610046&group_id=50884 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mikhail Teterin (kot) Assigned to: Nobody/Anonymous (nobody) Summary: Monitoring a directory - different results on different OSes Initial Comment: Hello! I'm trying to use libevent to monitor a set of directories -- and receive events, whenever a new file is created in one of them. The attached program works on BSD, but does not work on Solaris and Linux. On Solaris I'm simply flooded with events (both read and write are set), whereas on Linux the initialization fails upfront: [warn] Epoll ADD(-2147483643) on fd 3 failed. Old events were 0; read change was 33 (add); write change was 33 (add): Operation not permitted On FreeBSD I can run it as: % ./libevent-test /tmp/ /tmp/ (3) triggered by event(s) 38 After the first event is triggered as above, whenever I create or remove a file in /tmp, or simply ls the directory, there is an event created... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3610046&group_id=50884 |
|
From: SourceForge.net <no...@so...> - 2013-03-30 11:35:57
|
Bugs item #3609546, was opened at 2013-03-30 04:35 Message generated for change (Tracker Item Submitted) made by osmanov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3609546&group_id=50884 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libevent-core Group: For 2.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ruslan Osmanov (osmanov) Assigned to: Nobody/Anonymous (nobody) Summary: Garbage in address argument of the listener accept calback Initial Comment: In case when the event listener is bound to a UNIX domain socket, the callback's "address" argument contains garbage. Namely, sockaddr_un struct's sun_path member contains garbage. Sample program attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3609546&group_id=50884 |
|
From: SourceForge.net <no...@so...> - 2013-03-11 00:38:43
|
Bugs item #3607568, was opened at 2013-03-10 17:38 Message generated for change (Tracker Item Submitted) made by dkegel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3607568&group_id=50884 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dan Kegel (dkegel) Assigned to: Nobody/Anonymous (nobody) Summary: http/connection_retry test fails on Ubuntu 10.04 + 12.04 Initial Comment: "make check" fails frequently (in 1 to 4 tries) with EPOLL ... regress: http/connection_retry: FAIL test/regress_http.c:3100: assert(req) FAIL test/regress_http.c:3198: assert(abs(timeval_msec_diff((&tv_start), (&tv_end)) - 500) <= 200): 500 vs 200 [connection_retry FAILED] 1/209 TESTS FAILED. (8 skipped) Built from git, release-2.1.2-alpha-46-g87c5672 Also fails like this in release-2.1.1-alpha (In the later source, I commented out a line in test/regress_http.c: /*HTTP(ipv6_for_domain),*/ because I have no ipv6, but that shouldn't matter.) This was on both plain old i7 and dual Xeon hardware, on both 32 and 64 bit systems. release-2.0.21-stable doesn't seem to fail like this; maybe it lacks that test. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3607568&group_id=50884 |
|
From: SourceForge.net <no...@so...> - 2013-03-05 19:50:52
|
Bugs item #3606965, was opened at 2013-03-05 11:50 Message generated for change (Tracker Item Submitted) made by cptnater You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3606965&group_id=50884 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libevent-core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nate Rosenblum (cptnater) Assigned to: Nobody/Anonymous (nobody) Summary: Unexpected behavior after suspend/resume with long timer Initial Comment: When a system is suspended and resumed (e.g. when running libevent in a VM) with a long duration timer event scheduled, the event's timeout (which determines its position on the timer heap) may be in the past. This leads to unexpected behavior if the event loop is in a blocking system call (as it typically will be) and a short-duration timer event is scheduled after resuming from suspension. Because the new event will not land on top of the timer minheap, event_add will not notify the event loop thread, and so the new timer event will not fire until whatever residual duration on the pre-suspension timer event expires. Regrettably it is difficult to write a self-contained unit test that demonstrates this problem (as you need to suspend and resume the system), but it's easy enough to reproduce like so: # Register a long-duration timer event (e.g. 5 minutes) # Immediately suspend the VM # Wait > 5 minutes # Resume the VM # Schedule a short-duration timer event (e.g. 10us) # Wait ~5 minutes for both events to fire Observed w/ libevent 2.0.21 on Windows running in VMWare Fusion, but should apply everywhere. Since we already pay to get a fresh value of 'now' in event_add, it adds only a few instructions to double-check the top element's timer value to detect this condition, and if so to notify the event loop. I've submitted a pull request on github that does so. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3606965&group_id=50884 |
|
From: SourceForge.net <no...@so...> - 2013-03-02 20:48:54
|
Bugs item #3606637, was opened at 2013-03-02 12:48 Message generated for change (Tracker Item Submitted) made by osmanov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3606637&group_id=50884 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libevent-core Group: For 2.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ruslan Osmanov (osmanov) Assigned to: Nobody/Anonymous (nobody) Summary: bufferevent_write returns 0 in case of bad fd Initial Comment: $ cat test1.c #include <event2/event.h> #include <event2/bufferevent.h> #include <sys/socket.h> #include <string.h> static void fatal_error_cb(int err) { printf("fatal_error_cb\n"); } static void log_cb(int severity, const char *msg) { printf("%s\n", msg); } int main (int argc, char const* argv[]) { struct event_base *base; struct bufferevent *bev; event_set_fatal_callback(fatal_error_cb); event_set_log_callback(log_cb); event_enable_debug_mode(); base = event_base_new(); bev = bufferevent_socket_new(base, 109, BEV_OPT_CLOSE_ON_FREE); /* what gonna return bufferevent_write()? */ int res = bufferevent_write(bev, "xyz", 3); printf("bufferevent_write(): %d\n", res); event_base_dispatch(base); return 0; } $ gcc -levent_core -levent_extra test1.c -o test1 $ ./test1 Epoll ADD(4) on fd 109 failed. Old events were 0; read change was 0 (none); write change was 1 (add): Bad file descriptor bufferevent_write(): 0 Should return -1 here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3606637&group_id=50884 |
|
From: SourceForge.net <no...@so...> - 2013-02-22 19:18:25
|
Patches item #3605690, was opened at 2013-02-22 11:18 Message generated for change (Tracker Item Submitted) made by tdodd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461324&aid=3605690&group_id=50884 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: feature Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tim Dodd (tdodd) Assigned to: Nobody/Anonymous (nobody) Summary: Add an interface for cached monotonic time Initial Comment: This patch adds three new functions to event.c: 1. int event_base_gettimeofday_cached_ts(struct event_base *base, struct timespec *ts) This is a timespec-based version of event_base_gettimeofday_cached() for developers whose code is timespec-based and wish to use the cached time-of-day clock without having to convert from timevals. 2. int event_base_gettime_monotonic_cached(struct event_base *base, struct timeval *tv) This function is the same as event_base_gettimeofday_cached() except that it returns the cached monotonic time, if available. 3. int event_base_gettime_monotonic_cached_ts(struct event_base *base, struct timespec *ts) This is a timespec-based version of event_base_gettime_monotonic_cached() I've also modified configure.ac and until.h so that the timespec equivalents to commonly used timeval macros are available if needed. I added timespec=>timeval and timeval=>timespec conversion macros as well. test/regress_util.c has been modified to test changes to evutil_time.c:evutil_gettime_monotonic_(). I added a new unit-test test-cached.c to test all the cached timestamp functions, and modified the scripts and makefile templates accordingly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461324&aid=3605690&group_id=50884 |
|
From: SourceForge.net <no...@so...> - 2013-02-21 04:40:17
|
Bugs item #3605501, was opened at 2013-02-20 20:40 Message generated for change (Tracker Item Submitted) made by jimmy1911 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3605501&group_id=50884 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libevent-core Group: For 2.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Yong Gui (jimmy1911) Assigned to: Nobody/Anonymous (nobody) Summary: a crash on libevent-core Initial Comment: We use libevent on a server program to process client connections and read events. After 20+ days of running, the program crushed. This crash can been reproduced after a very long time running.There are some code involved libevent operations: /*new a base*/ base = event_base_new(); ...... /*add a event to process socket connections*/ listenevent = event_new(base, connect_fd, EV_READ|EV_PERSIST, accept_cb, (void*)this); event_add(listenevent, NULL); /*add read event for accepted socket*/ clifd = accept(connect_fd, (struct sockaddr *)&addr, &len); ...... recvevent = event_new(base, clifd, EV_READ|EV_PERSIST, UserConnEv::socket_read_cb, (void*)connection); connection->recv_id = event_add(recvevent, NULL); ....... /*set timeout for a client when it is accepted*/ tmoutevent = event_new(base, -1, 0, UserConnEv::timeout_cb, (void*)connection); evutil_timerclear(&timeOutTime); timeOutTime.tv_sec = 30; connection->timer_id = event_add(tmoutevent, &timeOutTime); ...... /*update a timeout event for a client when it sends data , does this a right way to update timeout event? */ connection->timer_id = event_add(conn->tmoutevent, &timeOutTime); ....... /*add a signal event to do something*/ struct event signal_usr; event_assign(&signal_usr, base, SIGUSR1 , EV_SIGNAL|EV_PERSIST, blacklist_refresh, blacklist); event_add(&signal_usr, NULL); Our libevent version is 2.0.19 and stack trace is like this: Program terminated with signal 11, Segmentation fault. #0 evmap_io_active (base=0xe60b60, fd=91, events=34) at evmap.c:402 402 TAILQ_FOREACH(ev, &ctx>events, ev_io_next) { Missing separate debuginfos, use: debuginfo-install apr-1.3.9-5.el6_2.x86_64 glibc-2.12-1.80.el6_3.3.x86_64 keyutils-libs-1.4-4.el6.x86_64 krb5-libs-1.9-33.el6.x86_64 libcom_err-1.41.12-12.el6.x86_64 libgcc-4.4.6-4.el6.x86_64 libselinux-2.0.94-5.3.el6.x86_64 libstdc++-4.4.6-4.el6.x86_64 libuuid-2.17.2-12.7.el6.x86_64 mysql-libs-5.1.61-4.el6.x86_64 nss-softokn-freebl-3.12.9-11.el6.x86_64 openssl-1.0.0-20.el6_2.5.x86_64 sqlite-3.6.20-1.el6.x86_64 zlib-1.2.3-27.el6.x86_64 (gdb) bt #0 evmap_io_active (base=0xe60b60, fd=91, events=34) at evmap.c:402 #1 0x00007f8c26c5d305 in epoll_dispatch (base=0xe60b60, tv=<value optimized out>) at epoll.c:439 #2 0x00007f8c26c4ba56 in event_base_loop (base=0xe60b60, flags=0) at event.c:1603 #3 0x0000000000409d1c in main (argc=3, argv=0x7fff184e5888) at src/main.cpp:575 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3605501&group_id=50884 |
|
From: SourceForge.net <no...@so...> - 2013-02-12 18:07:02
|
Bugs item #3604323, was opened at 2013-02-12 10:07 Message generated for change (Tracker Item Submitted) made by dcicppin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3604323&group_id=50884 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libevent-core Group: For 2.1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: dcicppin (dcicppin) Assigned to: Nobody/Anonymous (nobody) Summary: event_remove_timer not working from callback Initial Comment: event_remove_timer has no effect on the persistent event when called from its callback. evutil_timerclear(ev->ev_.ev_io.ev_timeout); does the job, but it's ugly. Maybe event_remove_timer should also prevent timer re-scheduling? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3604323&group_id=50884 |
|
From: SourceForge.net <no...@so...> - 2013-02-08 00:18:32
|
Bugs item #3603774, was opened at 2013-02-07 16:18 Message generated for change (Tracker Item Submitted) made by cazfi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3603774&group_id=50884 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: For 2.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: cazfi (cazfi) Assigned to: Nobody/Anonymous (nobody) Summary: Obsolete AM_CONFIG_HEADER used Initial Comment: Automake-1.13 removed long obsolete AM_CONFIG_HEADER completely ( http://lists.gnu.org/archive/html/automake/2012-12/msg00038.html ) and errors out upon seeing it. Attached patch replaces it with proper AC_CONFIG_HEADERS. ---- I'm mass submitting automake-1.13 fixes. Please see what you can do so I don't need to do the same when automake-1.14 comes out: http://cazfi.livejournal.com/195108.html -- Note that fixing this one problem alone does not make libevent to work with automake-1.13 - there's also use of $(top_srcdir) in TESTS issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3603774&group_id=50884 |
|
From: SourceForge.net <no...@so...> - 2013-02-05 19:50:49
|
Bugs item #3603449, was opened at 2013-02-05 11:50 Message generated for change (Tracker Item Submitted) made by bsponline You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3603449&group_id=50884 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libevent-core Group: For 2.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ka-Hing Cheung (bsponline) Assigned to: Nobody/Anonymous (nobody) Summary: locking error in bufferevent_socket_get_dns_error Initial Comment: the diff should be self explanatory ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3603449&group_id=50884 |
|
From: SourceForge.net <no...@so...> - 2013-01-30 04:47:58
|
Patches item #3602619, was opened at 2013-01-29 20:47 Message generated for change (Tracker Item Submitted) made by nicheath You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461324&aid=3602619&group_id=50884 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General Group: bugfix Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nic Heath (nicheath) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for Minix Host compiling Initial Comment: Minor changes to allow libevent to compile on Minix3. Changes: Added compile flags for host minix Added autoconf options to test for setrlimit and so_linger Changed WIN32 defines around so_linger and setrlimit to use the more specific new defines. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461324&aid=3602619&group_id=50884 |
|
From: SourceForge.net <no...@so...> - 2013-01-22 15:22:02
|
Bugs item #3601770, was opened at 2013-01-22 07:22 Message generated for change (Tracker Item Submitted) made by gyepi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3601770&group_id=50884 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libevent-http Group: For 2.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Gyepi Sam (gyepi) Assigned to: Nobody/Anonymous (nobody) Summary: buffer size error in sample/http-server.c Initial Comment: In sample/http-server.c, the line: n = evbuffer_remove(buf, cbuf, sizeof(buf)-1); should be: n = evbuffer_remove(buf, cbuf, sizeof(cbuf)); Since sizeof(buf) is 4, which is less than sizeof(cbuf), this is not an issue of security so much as inefficiency since the buffer is copied out in chunks of 3 bytes instead of the hoped for, 128 bytes. Of course, on a production system, cbuf would be much larger. Regards -Gyepi ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3601770&group_id=50884 |
|
From: SourceForge.net <no...@so...> - 2013-01-19 02:39:50
|
Bugs item #3601439, was opened at 2013-01-18 18:39 Message generated for change (Tracker Item Submitted) made by jchanak You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3601439&group_id=50884 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Chanak (jchanak) Assigned to: Nobody/Anonymous (nobody) Summary: OSX single threaded SSL client SIGPIPE. Initial Comment: The included file, when compiled and run against a non-listening server (connection reset) causes a near instant crash on OSX. The same file, under linux, operates normally (Connection gets reset, but there is no crash) The same file, on BOTH OS'es, operates fine if the server actually responds. (SSL handshake takes place, etc) The following is the result seen on OSX, when the connection is reset: (Note the SSL Version and Libevent version are included in the output) (gdb) run 10.80.1.100 Starting program: /Users/jchanak/src/internal/fohh/test3 10.80.1.100 Reading symbols for shared libraries ++++++............................. done SSL version: OpenSSL 1.0.1c 10 May 2012 Libevent version: 2.0.21-stable Starting dispatch loop Program received signal SIGPIPE, Broken pipe. 0x00007fff93d5f4aa in write () (gdb) bt #0 0x00007fff93d5f4aa in write () #1 0x00000001000d381c in sock_write () #2 0x00000001000d1b9e in BIO_write () #3 0x00000001000183cb in ssl3_write_pending () #4 0x0000000100017e59 in ssl3_write_bytes () #5 0x00000001000198c9 in ssl3_do_write () #6 0x000000010000f2de in ssl3_connect () #7 0x0000000100268ab7 in do_handshake (bev_ssl=0x4) at bufferevent_openssl.c:1003 #8 0x0000000100268e32 in be_openssl_handshakeeventcb (fd=4, ptr=0x10031a090) at bufferevent_openssl.c:1056 #9 0x0000000100215107 in event_base_loop (base=0x100319d60, flags=1606416752) at event.c:1350 #10 0x0000000100001a2c in main (argc=2, argv=0x7fff5fbffa88) at test3.c:158 (gdb) The following is seen on the wire: Justa-Laptop:~ jchanak$ sudo tcpdump -n host 10.80.1.100 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes 17:41:27.200731 IP 10.32.146.130.51777 > 10.80.1.100.443: Flags [S], seq 349217842, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 922020855 ecr 0,sackOK,eol], length 0 17:41:27.202252 IP 10.80.1.100.443 > 10.32.146.130.51777: Flags [R.], seq 0, ack 349217843, win 0, length 0 ^C 2 packets captured The code that I am running is included as an attachment. It is about as simple as I could make it and have it clearly fail. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3601439&group_id=50884 |
|
From: SourceForge.net <no...@so...> - 2012-11-24 02:23:20
|
Bugs item #3589499, was opened at 2012-11-23 18:23 Message generated for change (Tracker Item Submitted) made by swsnyder24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3589499&group_id=50884 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libevent-core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Steve Snyder (swsnyder24) Assigned to: Nobody/Anonymous (nobody) Summary: GCC complains of strict-aliasing breakage Initial Comment: At the standard -O2 optimization GCC v4.4.6 complains of broken strict-aliasing (see below) when building libevent v2.0.21 on a CentOS5 / i686 system. The warnings can be silenced by compiling with switch -fno-strict-aliasing, but at the cost of disabling this optimization for the entire libevent code base. That seems pretty extreme just for a couple instances of complaint. Best case would be to fix the code being complained about. Second-best case would be to apply the -fno-strict-aliasing switch to the compilation of the only 2 source files being complained about. This is the source of the complaints: common declaration: struct sockaddr_storage ss; evdns.c: if (evutil_parse_sockaddr_port(addr, (struct sockaddr*)&ss, &socklen)<0) regress_testutils.c: if (getsockname(fd, (struct sockaddr*)&ss, &socklen) != 0) Basically, GCC doesn't like passing a pointer to 1 struct as a pointer of a different struct. ----------------------- libtool: compile: gcc44 -DHAVE_CONFIG_H -I. -I./compat -I./include -I./include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=native -mno-avx -fomit-frame-pointer -fPIC -MT evdns.lo -MD -MP -MF .deps/evdns.Tpo -c evdns.c -o evdns.o evdns.c: In function 'evdns_base_parse_hosts_line': evdns.c:2567: warning: dereferencing pointer 'ss.461' does break strict-aliasing rules evdns.c:2565: warning: dereferencing pointer 'ss.461' does break strict-aliasing rules evdns.c:4037: note: initialized from here evdns.c:2566: warning: dereferencing pointer 'sa.301' does break strict-aliasing rules evdns.c:2566: note: initialized from here evdns.c:2568: warning: dereferencing pointer 'sa.302' does break strict-aliasing rules evdns.c:2568: note: initialized from here evdns.c: In function 'evdns_base_nameserver_ip_add': evdns.c:2557: warning: dereferencing pointer 'sa' does break strict-aliasing rules evdns.c:2555: warning: dereferencing pointer 'sa' does break strict-aliasing rules evdns.c:2567: warning: dereferencing pointer 'sa' does break strict-aliasing rules evdns.c:2565: warning: dereferencing pointer 'sa' does break strict-aliasing rules evdns.c:2587: note: initialized from here evdns.c:2566: warning: dereferencing pointer 'sa.301' does break strict-aliasing rules evdns.c:2566: note: initialized from here evdns.c:2568: warning: dereferencing pointer 'sa.302' does break strict-aliasing rules evdns.c:2568: note: initialized from here evdns.c:2556: warning: dereferencing pointer 'sa.299' does break strict-aliasing rules evdns.c:2556: note: initialized from here evdns.c:2558: warning: dereferencing pointer 'sa.300' does break strict-aliasing rules evdns.c:2558: note: initialized from here gcc44 -DHAVE_CONFIG_H -I. -I.. -I.. -I../compat -I../include -I../include -DTINYTEST_LOCAL -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=native -mno-avx -fomit-frame-pointer -fPIC -MT regress-regress_testutils.o -MD -MP -MF .deps/regress-regress_testutils.Tpo -c -o regress-regress_testutils.o `test -f 'regress_testutils.c' || echo './'`regress_testutils.c regress_testutils.c: In function 'regress_get_socket_port': regress_testutils.c:86: warning: dereferencing pointer 'ss.22' does break strict-aliasing rules regress_testutils.c:86: note: initialized from here regress_testutils.c:88: warning: dereferencing pointer 'ss.23' does break strict-aliasing rules regress_testutils.c:88: note: initialized from here gcc44 -DHAVE_CONFIG_H -I. -I.. -I.. -I../compat -I../include -I../include -DTINYTEST_LOCAL -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=native -mno-avx -fomit-frame-pointer -fPIC -MT regress-regress_listener.o -MD -MP -MF .deps/regress-regress_listener.Tpo -c -o regress-regress_listener.o `test -f 'regress_listener.c' || echo './'`regress_listener.c regress_listener.c: In function 'regress_pick_a_port': regress_listener.c:112: warning: dereferencing pointer 'sin1' does break strict-aliasing rules regress_listener.c:110: warning: dereferencing pointer 'sin1' does break strict-aliasing rules regress_listener.c:108: note: initialized from here regress_listener.c:112: warning: dereferencing pointer 'sin2' does break strict-aliasing rules regress_listener.c:111: warning: dereferencing pointer 'sin2' does break strict-aliasing rules regress_listener.c:109: note: initialized from here ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3589499&group_id=50884 |
|
From: SourceForge.net <no...@so...> - 2012-11-12 07:34:34
|
Bugs item #3586305, was opened at 2012-11-11 23:34 Message generated for change (Tracker Item Submitted) made by ktrushin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3586305&group_id=50884 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libevent-dns Group: For 2.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Konstantin (ktrushin) Assigned to: Nobody/Anonymous (nobody) Summary: evdns_base_load_hosts doesn't removes outdated addresses Initial Comment: I use hostfile to store some host address and use evdns_base_load_hosts to provide information about this host to libevent. If I change host address in the file and try to notify libevent about new address by calling evdns_base_load_hosts for the second time then evdns_getaddrinfo wrongly returns both addresses: old and new. But it should return only new one, shouldn't it? Reproduction (see attached source code): In the attached program I firstly write address 10.0.0.1 for host 'my_host' to 'my_hostfile' and everything is ok. Then I replace address to 10.0.0.2 and load hostfile again. After host file reloading evdns_getaddrinfo returns both addresses: 10.0.0.1 and 10.0.0.2, but should return only 10.0.0.2. Output: my_host -> 10.0.0.1 [request for my_host returned immediately] my_host -> 10.0.0.1 -> 10.0.0.2 [request for my_host returned immediately] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3586305&group_id=50884 |
|
From: SourceForge.net <no...@so...> - 2012-11-05 08:30:27
|
Bugs item #3583983, was opened at 2012-11-05 00:30 Message generated for change (Tracker Item Submitted) made by beckhamxiao You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3583983&group_id=50884 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libevent-core Group: For 2.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Xiao QingXing (beckhamxiao) Assigned to: Nobody/Anonymous (nobody) Summary: write callback not called at first when use IOCP Initial Comment: 2.0.20 stable Steps: 1.Create a event_base with IOCP: evthread_use_windows_threads(); event_config_set_flag(ev_config, EVENT_BASE_FLAG_STARTUP_IOCP); 2.then call evconnlistener_new_bind(), the listener callback looks like this: { struct bufferevent *bev = bufferevent_socket_new(base, fd, BEV_OPT_CLOSE_ON_FREE); bufferevent_setcb(bev, conn_readcb, conn_writecb, conn_eventcb, NULL); bufferevent_enable(bev, EV_WRITE | EV_READ); } 3. Connect from a client, nothing will happen, but if you create event_base without IOCP flag, conn_writecb will be called immediatly. I know the callback mechanism when with IOCP or without IOCP are different, but this hidden difference is an unhappy experience especially when you want to use IOCP to replace select for code that works well. After all, when connection established, a connection should be ready for write. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3583983&group_id=50884 |
|
From: SourceForge.net <no...@so...> - 2012-11-02 05:21:08
|
Patches item #3582627, was opened at 2012-11-01 22:21 Message generated for change (Tracker Item Submitted) made by yangacer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461324&aid=3582627&group_id=50884 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: Yang Acer (yangacer) Assigned to: Nobody/Anonymous (nobody) Summary: Cleanup function for evbuffer_file_segment Initial Comment: For easily observing when an evbuffer_file_segment is actually freed, I modify the internal data structure to store cleanup function and its argument. I also add a new method, evbuffer_file_segment_add_cleanup_cb(...), for adding the cleanup function. BTW, my testing is written in C++ so I do not include it in this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461324&aid=3582627&group_id=50884 |
|
From: SourceForge.net <no...@so...> - 2012-10-23 20:40:10
|
Bugs item #3579557, was opened at 2012-10-23 13:40 Message generated for change (Tracker Item Submitted) made by rosskinder You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3579557&group_id=50884 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libevent-dns Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: ross (rosskinder) Assigned to: Nobody/Anonymous (nobody) Summary: config_nameserver_from_reg_key incorrect API usage Initial Comment: In config_nameserver_from_reg_key we have: if (RegQueryValueEx(key, subkey, 0, &type, NULL, &bufsz) != ERROR_MORE_DATA) return -1; From MSDN (http://msdn.microsoft.com/en-us/library/windows/desktop/ms724911(v=vs.85).aspx): If lpData is NULL, and lpcbData is non-NULL, the function returns ERROR_SUCCESS and stores the size of the data, in bytes, in the variable pointed to by lpcbData. This enables an application to determine the best way to allocate a buffer for the value's data. I think it should be checking for ERROR_SUCCESS or at least for either value. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3579557&group_id=50884 |
|
From: SourceForge.net <no...@so...> - 2012-10-15 06:43:59
|
Bugs item #3577274, was opened at 2012-10-14 23:43 Message generated for change (Tracker Item Submitted) made by balanceren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3577274&group_id=50884 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libevent-http Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: balanceren (balanceren) Assigned to: Nobody/Anonymous (nobody) Summary: evhttp_error_cb when reading body EOF Initial Comment: For some web server, the connecting close when read eof static void evhttp_error_cb(struct bufferevent *bufev, short what, void *arg) ...... case EVCON_READING_BODY: if (!req->chunked && req->ntoread < 0 && what == (BEV_EVENT_READING|BEV_EVENT_EOF)) { /* EOF on read can be benign */ evcon->flags |= EVHTTP_CON_CLOSEEOF; //add flag when call evhttp_connection_done ..... need_close = (evcon->flags & EVHTTP_CON_CLOSEEOF) || evhttp_is_connection_close(req->flags, req->input_headers)|| evhttp_is_connection_close(req->flags, req->output_headers); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3577274&group_id=50884 |
|
From: SourceForge.net <no...@so...> - 2012-10-15 06:39:01
|
Bugs item #3577272, was opened at 2012-10-14 23:39 Message generated for change (Tracker Item Submitted) made by balanceren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3577272&group_id=50884 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libevent-core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: balanceren (balanceren) Assigned to: Nobody/Anonymous (nobody) Summary: timeout_process Initial Comment: timeout_process ...... while ((ev = min_heap_top(&base->timeheap))) { if (evutil_timercmp(&ev->ev_timeout, &now, >)) break; ev->ev_flags |= EVLIST_TIMEOUT; //add ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3577272&group_id=50884 |
|
From: SourceForge.net <no...@so...> - 2012-10-15 06:36:43
|
Bugs item #3577271, was opened at 2012-10-14 23:36 Message generated for change (Tracker Item Submitted) made by balanceren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3577271&group_id=50884 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libevent-core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: balanceren (balanceren) Assigned to: Nobody/Anonymous (nobody) Summary: bufferevent_writecb Initial Comment: bufferevent_writecb(evutil_socket_t fd, short event, void *arg) { ........ if (event == EV_TIMEOUT) { bufev_p->connecting = 0; when event be timeout,should set the connecting 0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3577271&group_id=50884 |
|
From: SourceForge.net <no...@so...> - 2012-10-15 06:33:07
|
Bugs item #3577269, was opened at 2012-10-14 23:33 Message generated for change (Tracker Item Submitted) made by balanceren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3577269&group_id=50884 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libevent-core Group: For 2.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: balanceren (balanceren) Assigned to: Nobody/Anonymous (nobody) Summary: min_heap_erase erase on heap size =0 Initial Comment: min_heap_erase，erase on heap size =0 change int min_heap_erase(min_heap_t* s, struct event* e) { if (-1 != e->ev_timeout_pos.min_heap_idx && min_heap_size(s)>0) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3577269&group_id=50884 |
|
From: SourceForge.net <no...@so...> - 2012-08-28 16:03:20
|
Bugs item #3562481, was opened at 2012-08-28 09:03 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3562481&group_id=50884 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libevent-core Group: For 2.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: tastky () Assigned to: Nobody/Anonymous (nobody) Summary: 2.0.20: SIGSEGV in event_pending Initial Comment: 2.0.20 will crash the whole tmux server on pressing certain keys like Esc. 2.0.19 was fine. Backtrace: Program received signal SIGSEGV, Segmentation fault. 0x00007feeccf5cfb7 in event_pending (ev=0x1be53f8, event=1, tv=0x0) at event.c:1849 1849 EVBASE_ACQUIRE_LOCK(ev->ev_base, th_base_lock); (gdb) bt #0 0x00007feeccf5cfb7 in event_pending (ev=0x1be53f8, event=1, tv=0x0) at event.c:1849 #1 0x000000000043e92f in tty_keys_next (tty=0x1be5338) at tty-keys.c:546 #2 0x00000000004401e1 in tty_read_callback (bufev=0x1bf1d90, data=0x1be5338) at tty.c:177 #3 0x00007feeccf68872 in _bufferevent_run_readcb (bufev=bufev@entry=0x1bf1d90) at bufferevent.c:232 #4 0x00007feeccf69a26 in bufferevent_readcb (fd=6, event=<optimized out>, arg=0x1bf1d90) at bufferevent_sock.c:183 #5 0x00007feeccf602c5 in event_persist_closure (ev=0x1bf1da0, base=0x1bba720) at event.c:1297 #6 event_process_active_single_queue (activeq=0x1bba6e0, base=0x1bba720) at event.c:1341 #7 event_process_active (base=<optimized out>) at event.c:1416 #8 event_base_loop (base=0x1bba720, flags=1) at event.c:1617 #9 0x00007feeccf605b9 in event_loop (flags=<optimized out>) at event.c:1529 #10 0x0000000000433860 in server_loop () at server.c:212 #11 0x0000000000433844 in server_start (lockfd=6, lockfile=0x1bbb050 "") at server.c:203 #12 0x0000000000404cbd in client_connect (path=0x68b700 <socket_path> "/tmp/tmux-1000/default", start_server=1) at client.c:124 #13 0x0000000000404f64 in client_main (argc=4, argv=0x7fff1286a830, flags=1) at client.c:220 #14 0x000000000043e0d2 in main (argc=4, argv=0x7fff1286a830) at tmux.c:404 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3562481&group_id=50884 |
|
From: SourceForge.net <no...@so...> - 2012-07-21 04:41:48
|
Bugs item #3546585, was opened at 2012-07-20 21:41 Message generated for change (Tracker Item Submitted) made by run_mei You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3546585&group_id=50884 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libevent-core Group: For 2.1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: run_mei (run_mei) Assigned to: Nobody/Anonymous (nobody) Summary: compile warning in evutil.c with newest code Initial Comment: error message as follows: libevent2\evutil.c(2233): warning C4013: “_getpid”未定义；假设外部返回 int fix code #include <process.h> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=461322&aid=3546585&group_id=50884 |