Discussion:
upcoming 2.1.4-alpha Libevent release
(too old to reply)
Nick Mathewson
2014-03-17 17:31:13 UTC
Permalink
Raw Message
Hi, all!

There's been a lot of activity on Libevent recently, so I'm hoping to
put out a Libevent 2.1.4-alpha in the next day or two. It will not
have every bugfix that I've been told about, or every feature that I'm
hoping to include in 2.1.x, but it's been long enough without an alpha
that it's probably wise to put a

If you want to try it out before the release, have a look at

http://www.wangafu.net/~nickm/volatile/libevent-2.1.4-alpha-candidate.tar.gz

Please let me know about any total showstopper bugs here. (Like,
major regressions against 2.1.3-alpha)

THIS IS NOT THE ACTUAL RELEASE. Do not upload this to package
repositories, etc.

I've attached a signed sha256sum.
--
Nick
Jeffrey Walton
2014-03-17 18:22:53 UTC
Permalink
Raw Message
Post by Nick Mathewson
Hi, all!
There's been a lot of activity on Libevent recently, so I'm hoping to
put out a Libevent 2.1.4-alpha in the next day or two. It will not
have every bugfix that I've been told about, or every feature that I'm
hoping to include in 2.1.x, but it's been long enough without an alpha
that it's probably wise to put a
If you want to try it out before the release, have a look at
http://www.wangafu.net/~nickm/volatile/libevent-2.1.4-alpha-candidate.tar.gz
Please let me know about any total showstopper bugs here. (Like,
major regressions against 2.1.3-alpha)
Dumb question here....

How can I see the compile command being used below? I want to run the
test suite under Clang's sanitizers, but I can't tell if the proper
flags are being used.

Jeff

$ make
GEN test/rpcgen-attempted
GEN include/event2/event-config.h
make all-am
make[1]: Entering directory `.../libevent-2.1.4-alpha-candidate'
CC buffer.lo
CC bufferevent.lo
CC bufferevent_filter.lo
...
***********************************************************************
To unsubscribe, send an e-mail to ***@freehaven.net with
unsubscribe libevent-users in the body.
Jeffrey Walton
2014-03-17 18:27:50 UTC
Permalink
Raw Message
Post by Jeffrey Walton
Post by Nick Mathewson
...
If you want to try it out before the release, have a look at
http://www.wangafu.net/~nickm/volatile/libevent-2.1.4-alpha-candidate.tar.gz
Please let me know about any total showstopper bugs here. (Like,
major regressions against 2.1.3-alpha)
Dumb question here....
How can I see the compile command being used below? I want to run the
test suite under Clang's sanitizers, but I can't tell if the proper
flags are being used.
$ make
$ make V=1
Thanks. Is that kbuild?

Jeff
***********************************************************************
To unsubscribe, send an e-mail to ***@freehaven.net with
unsubscribe libevent-users in the body.
Vincent Bernat
2014-03-17 23:48:23 UTC
Permalink
Raw Message
Post by Jeffrey Walton
Post by Jeffrey Walton
How can I see the compile command being used below? I want to run the
test suite under Clang's sanitizers, but I can't tell if the proper
flags are being used.
$ make
$ make V=1
Thanks. Is that kbuild?
That's a feature of new automake: "AM_SILENT_RULES".
--
printk("What? oldfid != cii->c_fid. Call 911.\n");
2.4.3 linux/fs/coda/cnode.c
***********************************************************************
To unsubscribe, send an e-mail to ***@freehaven.net with
unsubscribe libevent-users in the body.
Frank Lahm
2014-03-17 18:23:54 UTC
Permalink
Raw Message
Post by Jeffrey Walton
Post by Nick Mathewson
Hi, all!
There's been a lot of activity on Libevent recently, so I'm hoping to
put out a Libevent 2.1.4-alpha in the next day or two. It will not
have every bugfix that I've been told about, or every feature that I'm
hoping to include in 2.1.x, but it's been long enough without an alpha
that it's probably wise to put a
If you want to try it out before the release, have a look at
http://www.wangafu.net/~nickm/volatile/libevent-2.1.4-alpha-candidate.tar.gz
Please let me know about any total showstopper bugs here. (Like,
major regressions against 2.1.3-alpha)
Dumb question here....
How can I see the compile command being used below? I want to run the
test suite under Clang's sanitizers, but I can't tell if the proper
flags are being used.
Jeff
$ make
$ make V=1

-f***********************************************************************
To unsubscribe, send an e-mail to ***@freehaven.net with
unsubscribe libevent-users in the body.
Jeffrey Walton
2014-03-17 18:36:31 UTC
Permalink
Raw Message
Post by Nick Mathewson
Hi, all!
There's been a lot of activity on Libevent recently, so I'm hoping to
put out a Libevent 2.1.4-alpha in the next day or two. It will not
have every bugfix that I've been told about, or every feature that I'm
hoping to include in 2.1.x, but it's been long enough without an alpha
that it's probably wise to put a
If you want to try it out before the release, have a look at
http://www.wangafu.net/~nickm/volatile/libevent-2.1.4-alpha-candidate.tar.gz
Please let me know about any total showstopper bugs here. (Like,
major regressions against 2.1.3-alpha)
It looks like there's some undefined behavior present.

Attached is the result of manually running test/test.sh.

Jeff

***** Excerpt *****

regress: evutil.c:1930:26: runtime error: left shift of 255 by 24
places cannot be represented in type 'int'
test/regress_util.c:182:25: runtime error: left shift of 255 by 24
places cannot be represented in type 'int'
test/regress_util.c:729:5: runtime error: signed integer overflow:
9223372036854775807 + 1 cannot be represented in type 'int64_t' (aka
'long')
test/regress_util.c:739:5: runtime error: signed integer overflow:
2147483647 + 1 cannot be represented in type 'int32_t' (aka 'int')
test/regress_util.c:766:7: runtime error: signed integer overflow:
9223372036854775807 + 1 cannot be represented in type 'ssize_t' (aka
'long')
http.c:4289:22: runtime error: signed integer overflow: 999999999 * 10
cannot be represented in type 'int'
event_tagging.c:213:28: runtime error: left shift of 95 by 28 places
cannot be represented in type 'int'
event_tagging.c:213:28: runtime error: left shift of 13 by 28 places
cannot be represented in type 'int'
Nick Mathewson
2014-03-17 21:27:51 UTC
Permalink
Raw Message
Post by Jeffrey Walton
Post by Nick Mathewson
Hi, all!
There's been a lot of activity on Libevent recently, so I'm hoping to
put out a Libevent 2.1.4-alpha in the next day or two. It will not
have every bugfix that I've been told about, or every feature that I'm
hoping to include in 2.1.x, but it's been long enough without an alpha
that it's probably wise to put a
If you want to try it out before the release, have a look at
http://www.wangafu.net/~nickm/volatile/libevent-2.1.4-alpha-candidate.tar.gz
Please let me know about any total showstopper bugs here. (Like,
major regressions against 2.1.3-alpha)
It looks like there's some undefined behavior present.
Attached is the result of manually running test/test.sh.
Jeff
***** Excerpt *****
regress: evutil.c:1930:26: runtime error: left shift of 255 by 24
places cannot be represented in type 'int'
test/regress_util.c:182:25: runtime error: left shift of 255 by 24
places cannot be represented in type 'int'
9223372036854775807 + 1 cannot be represented in type 'int64_t' (aka
'long')
2147483647 + 1 cannot be represented in type 'int32_t' (aka 'int')
9223372036854775807 + 1 cannot be represented in type 'ssize_t' (aka
'long')
http.c:4289:22: runtime error: signed integer overflow: 999999999 * 10
cannot be represented in type 'int'
event_tagging.c:213:28: runtime error: left shift of 95 by 28 places
cannot be represented in type 'int'
event_tagging.c:213:28: runtime error: left shift of 13 by 28 places
cannot be represented in type 'int'
Looks like we've got some issues here. In most cases, the solution is
probably to use the appropriate unsigned types. Are you using the
clang analyzer, or some other tools?

Are any of these regressions since 2.1.3-alpha? I'd like to run
without warnings everywhere interesting, but like I said, for
2.1.4-alpha at this point, it's major showstopper bugs only. If they
aren't regressions, they probably haven't been hurting anyone's code
in the past, and we can fix 'em in 2.1.5.

yrs,
--
Nick
***********************************************************************
To unsubscribe, send an e-mail to ***@freehaven.net with
unsubscribe libevent-users in the body.
Jeffrey Walton
2014-03-18 00:07:34 UTC
Permalink
Raw Message
Post by Nick Mathewson
Post by Jeffrey Walton
...
regress: evutil.c:1930:26: runtime error: left shift of 255 by 24
places cannot be represented in type 'int'
test/regress_util.c:182:25: runtime error: left shift of 255 by 24
places cannot be represented in type 'int'
9223372036854775807 + 1 cannot be represented in type 'int64_t' (aka
'long')
2147483647 + 1 cannot be represented in type 'int32_t' (aka 'int')
9223372036854775807 + 1 cannot be represented in type 'ssize_t' (aka
'long')
http.c:4289:22: runtime error: signed integer overflow: 999999999 * 10
cannot be represented in type 'int'
event_tagging.c:213:28: runtime error: left shift of 95 by 28 places
cannot be represented in type 'int'
event_tagging.c:213:28: runtime error: left shift of 13 by 28 places
cannot be represented in type 'int'
Looks like we've got some issues here. In most cases, the solution is
probably to use the appropriate unsigned types. Are you using the
clang analyzer, or some other tools?
Yes, Clang 3.4.

A document on downloading, building, installing and utilizing Clang
3.4 can be found at http://docs.python.org/devguide/clang.html. Its
recipe based, so it should be a s simple as copy/paste.

The same applies to libevent. (I tested Python and libevent when it
was being written).

Libevent's output is not printed to the screen, even with `make check
V=1`. You'll have to find it in a log file or run test/test.sh
manually.

Jeff
***********************************************************************
To unsubscribe, send an e-mail to ***@freehaven.net with
unsubscribe libevent-users in the body.
Jeffrey Walton
2014-03-18 00:22:12 UTC
Permalink
Raw Message
Post by Nick Mathewson
Post by Jeffrey Walton
Post by Nick Mathewson
Hi, all!
There's been a lot of activity on Libevent recently, so I'm hoping to
put out a Libevent 2.1.4-alpha in the next day or two. It will not
have every bugfix that I've been told about, or every feature that I'm
hoping to include in 2.1.x, but it's been long enough without an alpha
that it's probably wise to put a
If you want to try it out before the release, have a look at
http://www.wangafu.net/~nickm/volatile/libevent-2.1.4-alpha-candidate.tar.gz
Please let me know about any total showstopper bugs here. (Like,
major regressions against 2.1.3-alpha)
It looks like there's some undefined behavior present.
Attached is the result of manually running test/test.sh.
Jeff
***** Excerpt *****
regress: evutil.c:1930:26: runtime error: left shift of 255 by 24
places cannot be represented in type 'int'
test/regress_util.c:182:25: runtime error: left shift of 255 by 24
places cannot be represented in type 'int'
9223372036854775807 + 1 cannot be represented in type 'int64_t' (aka
'long')
2147483647 + 1 cannot be represented in type 'int32_t' (aka 'int')
9223372036854775807 + 1 cannot be represented in type 'ssize_t' (aka
'long')
http.c:4289:22: runtime error: signed integer overflow: 999999999 * 10
cannot be represented in type 'int'
event_tagging.c:213:28: runtime error: left shift of 95 by 28 places
cannot be represented in type 'int'
event_tagging.c:213:28: runtime error: left shift of 13 by 28 places
cannot be represented in type 'int'
Looks like we've got some issues here. In most cases, the solution is
probably to use the appropriate unsigned types. Are you using the
clang analyzer, or some other tools?
Are any of these regressions since 2.1.3-alpha? I'd like to run
without warnings everywhere interesting, but like I said, for
2.1.4-alpha at this point, it's major showstopper bugs only. If they
aren't regressions, they probably haven't been hurting anyone's code
in the past, and we can fix 'em in 2.1.5.
The compiler to use would be Intel's ICC. ICC's optimizer is
*ruthless* about removing code with undefined behavior.

I've worked with programs and libraries that executed as expected and
passed all self tests under Clang, Comeau, GCC and MSVC; but suffered
a single self test failure under ICC. If any of the ibevents are going
to suffer UB code removal, then its going to happen under ICC.

What I'm trying to say: you can't count on "it works" under GCC or
Clang, so it must be OK. Plus, the code might work well now bu break
in the future as the compiler guys improve analysis. Or, it might
break in the future when used under Link Time Optimization (LTO).

Jeff
***********************************************************************
To unsubscribe, send an e-mail to ***@freehaven.net with
unsubscribe libevent-users in the body.

Jeffrey Walton
2014-03-17 18:46:37 UTC
Permalink
Raw Message
Post by Nick Mathewson
Hi, all!
There's been a lot of activity on Libevent recently, so I'm hoping to
put out a Libevent 2.1.4-alpha in the next day or two. It will not
have every bugfix that I've been told about, or every feature that I'm
hoping to include in 2.1.x, but it's been long enough without an alpha
that it's probably wise to put a
If you want to try it out before the release, have a look at
http://www.wangafu.net/~nickm/volatile/libevent-2.1.4-alpha-candidate.tar.gz
Please let me know about any total showstopper bugs here. (Like,
major regressions against 2.1.3-alpha)
It looks like there's some memory errors present.

Attached is the result of manually running test/test.sh.

Jeff

***** Excerpt *****

=================================================================
==8816==ERROR: AddressSanitizer: heap-use-after-free on address
0x60c000035ed3 at pc 0x7f2221d81a4d bp 0x7fff68c1bd30 sp
0x7fff68c1bd28
READ of size 1 at 0x60c000035ed3 thread T0
#0 0x7f2221d81a4c in event_process_active_single_queue
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/event.c:1594
#1 0x7f2221d4b772 in event_process_active
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/event.c:1666
#2 0x7f2221d42f5e in event_base_loop
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/event.c:1889
#3 0x7f2221d417ba in event_base_dispatch
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/event.c:1700
#4 0x6494d1 in test_fin_within_cb
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/test/regress_finalize.c:271
#5 0x751250 in testcase_run_bare_
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/test/tinytest.c:105
#6 0x750487 in testcase_run_forked_
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/test/tinytest.c:189
#7 0x74fa36 in testcase_run_one
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/test/tinytest.c:247
#8 0x75420b in tinytest_main
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/test/tinytest.c:434
#9 0x6dbaf1 in main
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/test/regress_main.c:455
#10 0x7f222019eeac in __libc_start_main
/home/aurel32/eglibc/eglibc-2.13/csu/libc-start.c:244
#11 0x49133c in _start
(/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/test/.libs/lt-regress+0x49133c)

0x60c000035ed3 is located 19 bytes inside of 128-byte region
[0x60c000035ec0,0x60c000035f40)
freed by thread T0 here:
#0 0x47b0e9 in __interceptor_free
/home/jwalton/Desktop/clang-3.4/llvm-3.4/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:64
#1 0x7f2221d23dab in event_mm_free_
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/event.c:3441
#2 0x7f2221d554ce in event_free
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/event.c:2110
#3 0x64b94b in event_finalize_callback_2
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/test/regress_finalize.c:241
#4 0x7f2221d817a8 in event_process_active_single_queue
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/event.c:1592
#5 0x7f2221d4b772 in event_process_active
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/event.c:1666
#6 0x7f2221d42f5e in event_base_loop
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/event.c:1889
#7 0x7f2221d417ba in event_base_dispatch
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/event.c:1700
#8 0x6494d1 in test_fin_within_cb
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/test/regress_finalize.c:271
#9 0x751250 in testcase_run_bare_
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/test/tinytest.c:105
#10 0x750487 in testcase_run_forked_
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/test/tinytest.c:189
#11 0x74fa36 in testcase_run_one
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/test/tinytest.c:247
#12 0x75420b in tinytest_main
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/test/tinytest.c:434
#13 0x6dbaf1 in main
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/test/regress_main.c:455
#14 0x7f222019eeac in __libc_start_main
/home/aurel32/eglibc/eglibc-2.13/csu/libc-start.c:244

previously allocated by thread T0 here:
#0 0x47b269 in malloc
/home/jwalton/Desktop/clang-3.4/llvm-3.4/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:74
#1 0x7f2221d2391e in event_mm_malloc_
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/event.c:3366
#2 0x7f2221d54d48 in event_new
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/event.c:2089
#3 0x6492b5 in test_fin_within_cb
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/test/regress_finalize.c:262
#4 0x751250 in testcase_run_bare_
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/test/tinytest.c:105
#5 0x750487 in testcase_run_forked_
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/test/tinytest.c:189
#6 0x74fa36 in testcase_run_one
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/test/tinytest.c:247
#7 0x75420b in tinytest_main
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/test/tinytest.c:434
#8 0x6dbaf1 in main
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/test/regress_main.c:455
#9 0x7f222019eeac in __libc_start_main
/home/aurel32/eglibc/eglibc-2.13/csu/libc-start.c:244

SUMMARY: AddressSanitizer: heap-use-after-free
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/event.c:1594
event_process_active_single_queue
Shadow bytes around the buggy address:
0x0c187fffeb80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c187fffeb90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c187fffeba0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c187fffebb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c187fffebc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c187fffebd0: fa fa fa fa fa fa fa fa fd fd[fd]fd fd fd fd fd
0x0c187fffebe0: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa
0x0c187fffebf0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c187fffec00: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
0x0c187fffec10: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa
0x0c187fffec20: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Heap right redzone: fb
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
ASan internal: fe
==8816==ABORTING


=================================================================
==8746==ERROR: AddressSanitizer: global-buffer-overflow on address
0x000000798829 at pc 0x7f2221c91b00 bp 0x7fff68c1b410 sp
0x7fff68c1b408
READ of size 42 at 0x000000798829 thread T0
#0 0x7f2221c91aff in evbuffer_add
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/buffer.c:1775
#1 0x58813d in test_evbuffer_add_reference
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/test/regress_buffer.c:1663
#2 0x751250 in testcase_run_bare_
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/test/tinytest.c:105
#3 0x74fad1 in testcase_run_one
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/test/tinytest.c:252
#4 0x75420b in tinytest_main
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/test/tinytest.c:434
#5 0x6dbaf1 in main
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/test/regress_main.c:455
#6 0x7f222019eeac in __libc_start_main
/home/aurel32/eglibc/eglibc-2.13/csu/libc-start.c:244
#7 0x49133c in _start
(/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/test/.libs/lt-regress+0x49133c)

0x000000798829 is located 55 bytes to the left of global variable
'.str258' from 'test/regress_buffer.c' (0x798860) of size 30
'.str258' is ascii string 'ref_done_cb_called_count == 3'
0x000000798829 is located 6 bytes to the right of global variable
'.str257' from 'test/regress_buffer.c' (0x798800) of size 35
'.str257' is ascii string '. Nothing comes and then a lot'll.'
SUMMARY: AddressSanitizer: global-buffer-overflow
/home/jwalton/Desktop/libevent-2.1.4-alpha-candidate/buffer.c:1775
evbuffer_add
Shadow bytes around the buggy address:
0x0000800eb0b0: 00 04 f9 f9 f9 f9 f9 f9 00 00 00 06 f9 f9 f9 f9
0x0000800eb0c0: 03 f9 f9 f9 f9 f9 f9 f9 00 00 01 f9 f9 f9 f9 f9
0x0000800eb0d0: 00 00 00 00 00 01 f9 f9 f9 f9 f9 f9 00 00 00 06
0x0000800eb0e0: f9 f9 f9 f9 00 00 00 00 00 06 f9 f9 f9 f9 f9 f9
0x0000800eb0f0: 00 00 00 01 f9 f9 f9 f9 00 07 f9 f9 f9 f9 f9 f9
=>0x0000800eb100: 00 00 00 00 03[f9]f9 f9 f9 f9 f9 f9 00 00 00 06
0x0000800eb110: f9 f9 f9 f9 00 00 00 00 00 07 f9 f9 f9 f9 f9 f9
0x0000800eb120: 00 00 01 f9 f9 f9 f9 f9 00 00 01 f9 f9 f9 f9 f9
0x0000800eb130: 00 00 00 00 06 f9 f9 f9 f9 f9 f9 f9 06 f9 f9 f9
0x0000800eb140: f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 00 00 00 00
0x0000800eb150: 00 00 00 00 01 f9 f9 f9 f9 f9 f9 f9 02 f9 f9 f9
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Heap right redzone: fb
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
ASan internal: fe
==8746==ABORTING
Jeffrey Walton
2014-03-17 19:45:49 UTC
Permalink
Raw Message
Hi Nick,

You might be able to quicken this test a bit, if interested:

if (sscanf(src, "%d.%d.%d.%d%c", &a,&b,&c,&d,&more) != 4)
return 0;
if (a < 0 || a > 255) return 0;
if (b < 0 || b > 255) return 0;
if (c < 0 || c > 255) return 0;
if (d < 0 || d > 255) return 0;

int x = a | b | c | d;
if(x >> 8) return 0;

That's 4 OR's, 1 shift an 1 compare versus 8 compares.

To remove the undefined behavior, cast a,b,c,d to unsigned before the
shift. The unsigned will allow the high bit to be set without a sign
change. Then, cast back to signed before calling htonl.

Gotta love C rules and undefined behavior ;)

Jeff
Post by Nick Mathewson
Hi, all!
There's been a lot of activity on Libevent recently, so I'm hoping to
put out a Libevent 2.1.4-alpha in the next day or two. It will not
have every bugfix that I've been told about, or every feature that I'm
hoping to include in 2.1.x, but it's been long enough without an alpha
that it's probably wise to put a
If you want to try it out before the release, have a look at
http://www.wangafu.net/~nickm/volatile/libevent-2.1.4-alpha-candidate.tar.gz
Please let me know about any total showstopper bugs here. (Like,
major regressions against 2.1.3-alpha)
THIS IS NOT THE ACTUAL RELEASE. Do not upload this to package
repositories, etc.
I've attached a signed sha256sum.
--
Nick
***********************************************************************
To unsubscribe, send an e-mail to ***@freehaven.net with
unsubscribe libevent-users in the body.
james
2014-03-17 20:27:02 UTC
Permalink
Raw Message
Post by Jeffrey Walton
That's 4 OR's, 1 shift an 1 compare versus 8 compares.
What on earth is the point of replacing a verbose-but-obvious code
sequence with a crafty one, to save a trivial time and space, when
immediately prior we just did an sscanf? Have you tried timing sscanf?

***********************************************************************
To unsubscribe, send an e-mail to ***@freehaven.net with
unsubscribe libevent-users in the body.
Jeffrey Walton
2014-03-17 20:36:05 UTC
Permalink
Raw Message
Post by Jeffrey Walton
That's 4 OR's, 1 shift an 1 compare versus 8 compares.
What on earth is the point of replacing a verbose-but-obvious code sequence
with a crafty one, to save a trivial time and space, when immediately prior
we just did an sscanf? Have you tried timing sscanf?
No, but I can't make sscanf any faster.

Jeff
***********************************************************************
To unsubscribe, send an e-mail to ***@freehaven.net with
unsubscribe libevent-users in the body.
Ralph Castain
2014-03-17 20:39:36 UTC
Permalink
Raw Message
Is this code snippet in a critical path?? If not, I'd be in favor of retaining the obvious code than try to grind thru this optimization
Post by Jeffrey Walton
Post by Jeffrey Walton
That's 4 OR's, 1 shift an 1 compare versus 8 compares.
What on earth is the point of replacing a verbose-but-obvious code sequence
with a crafty one, to save a trivial time and space, when immediately prior
we just did an sscanf? Have you tried timing sscanf?
No, but I can't make sscanf any faster.
Jeff
***********************************************************************
unsubscribe libevent-users in the body.
***********************************************************************
To unsubscribe, send an e-mail to ***@freehaven.net with
unsubscribe libevent-users in the body.
Jeffrey Walton
2014-03-17 20:44:14 UTC
Permalink
Raw Message
Post by Ralph Castain
Is this code snippet in a critical path?? If not, I'd be in favor of retaining the obvious code than try to grind thru this optimization
My lord... You'd think I was talking religion when I only made a
comment about an observation.

I officially redact the comment.

Jeff
Post by Ralph Castain
Post by Jeffrey Walton
Post by Jeffrey Walton
That's 4 OR's, 1 shift an 1 compare versus 8 compares.
What on earth is the point of replacing a verbose-but-obvious code sequence
with a crafty one, to save a trivial time and space, when immediately prior
we just did an sscanf? Have you tried timing sscanf?
No, but I can't make sscanf any faster.
***********************************************************************
To unsubscribe, send an e-mail to ***@freehaven.net with
unsubscribe libevent-users in the body.
Ralph Castain
2014-03-17 20:54:21 UTC
Permalink
Raw Message
Post by Jeffrey Walton
Post by Ralph Castain
Is this code snippet in a critical path?? If not, I'd be in favor of retaining the obvious code than try to grind thru this optimization
My lord... You'd think I was talking religion when I only made a
comment about an observation.
I officially redact the comment.
Geez, Jeff - nobody is shooting at you. We're just asking questions about your proposal to try and understand it better :-/

I don't even know where this snippet sits...which is why I asked my question.
Post by Jeffrey Walton
Jeff
Post by Ralph Castain
Post by Jeffrey Walton
Post by Jeffrey Walton
That's 4 OR's, 1 shift an 1 compare versus 8 compares.
What on earth is the point of replacing a verbose-but-obvious code sequence
with a crafty one, to save a trivial time and space, when immediately prior
we just did an sscanf? Have you tried timing sscanf?
No, but I can't make sscanf any faster.
***********************************************************************
unsubscribe libevent-users in the body.
***********************************************************************
To unsubscribe, send an e-mail to ***@freehaven.net with
unsubscribe libevent-users in the body.
james
2014-03-17 21:07:35 UTC
Permalink
Raw Message
Post by Ralph Castain
Geez, Jeff - nobody is shooting at you. We're just asking questions about your proposal to try and understand it better :-/
Speak for yourself.

I *was* shooting at him, for the worst 'pointless premature
optimisation' I've seen in a long time.


***********************************************************************
To unsubscribe, send an e-mail to ***@freehaven.net with
unsubscribe libevent-users in the body.
Nick Mathewson
2014-03-17 21:23:28 UTC
Permalink
Raw Message
Post by james
Post by Ralph Castain
Geez, Jeff - nobody is shooting at you. We're just asking questions about
your proposal to try and understand it better :-/
Speak for yourself.
I *was* shooting at him, for the worst 'pointless premature optimisation'
I've seen in a long time.
Let's keep this a friendly mailing list, friends. Remember, it's only
software, and I'm sure everybody here has proposed an optimization
outside the critical path at least once in their lives.

peace,
--
Nick
***********************************************************************
To unsubscribe, send an e-mail to ***@freehaven.net with
unsubscribe libevent-users in the body.
Jeffrey Walton
2014-03-17 23:50:28 UTC
Permalink
Raw Message
Post by james
Post by Ralph Castain
Geez, Jeff - nobody is shooting at you. We're just asking questions about
your proposal to try and understand it better :-/
Speak for yourself.
I *was* shooting at him, for the worst 'pointless premature optimisation'
I've seen in a long time.
A few points here...

That was supposed to go to Nick privately, but it was accidentally
sent to the list.

It was a quick comment on a quick observation. It did not go to the
dev list for any kind of consideration.

All code is critical. If its not critical, then its extraneous and it
should be removed.

Jeff
***********************************************************************
To unsubscribe, send an e-mail to ***@freehaven.net with
unsubscribe libevent-users in the body.
Loading...