[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #16943 [Tor]: Implement prop250 (Random Number Generation During Tor Voting)
#16943: Implement prop250 (Random Number Generation During Tor Voting)
-------------------------+------------------------------------
Reporter: asn | Owner: dgoulet
Type: enhancement | Status: needs_review
Priority: High | Milestone: Tor: 0.2.8.x-final
Component: Tor | Version:
Severity: Normal | Resolution:
Keywords: tor-hs | Actual Points:
Parent ID: #8244 | Points: large
Sponsor: SponsorR |
-------------------------+------------------------------------
Comment (by dgoulet):
Replying to [comment:38 teor]:
> (This is my third comment.)
>
> I also get an assertion failure:
> {{{
> shared-random/utils: [forking]
> FAIL /Users/twilsonb/tor/tor-sr/src/test/test_shared_random.c:957:
assert(commit_is_authoritative(&commit, fp) == 0): 1 vs 0
> [utils FAILED]
> }}}
>
> But only when compiling under certain clang options (OS X):
> * `-fstack-protector -fstrict-aliasing -DPARANOIA -fsanitize=undefined-
trap -fsanitize-undefined-trap-on-error -fno-sanitize-recover`
> * No optimisation (`-O0`)
> * 64 bit
I wonder if one of those options somehow removes the `memset(0)` just
above the assert which would explain why 1 is returned instead of 0 else I
can't see why this would return 1!
>
> I see undefined behaviour under 32 bit, possibly in tor_gmtime (which
isn't mentioned below, but is in the tor backtrace):
> {{{
> 2 libsystem_c.dylib 0x9d7f5c34 abort + 156
> 3 test 0x0057e5bf crash_handler + 383
> 4 libsystem_platform.dylib 0x990fb01b _sigtramp + 43
> 5 ??? 0xffffffff 0 + 4294967295
> 6 test 0x0057e440 0x1000 + 5755968
> 7 test 0x007d20eb parse_iso_time_ + 1739
(util.c:1713)
> 8 test 0x007d2134 parse_iso_time + 52
(util.c:1723)
> 9 test 0x00702157 config_assign_value +
7239 (confparse.c:346)
> 10 test 0x006fbba7 config_assign_line +
4663 (confparse.c:529)
> 11 test 0x006fa435 config_assign + 2133
(confparse.c:828)
> 12 test 0x009be851
disk_state_load_from_disk_impl + 417 (shared_random_state.c:651)
> 13 test 0x0073b9f5
test_state_load_from_disk + 1525 (test_shared_random.c:617)
> }}}
I'm not sure what to do about this one. I wonder if this actually also
happens with our current state file since this is plain ISO TIME parsing.
Nothing different between this state file and the one we have in terms of
parsing timestamp...
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/16943#comment:40>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs