tor-commits March 2016

tor-commits@lists.torproject.org

16 participants
1259 discussions

[tor/release-0.2.8] Remove redundant only in manpage
by nickm＠torproject.org 28 Mar '16

28 Mar '16

commit 7d6e7fdd0343c32a09c926e7094d43f6653baa4f Author: Sebastian Hahn <sebastian(a)torproject.org> Date: Sun Mar 27 22:22:29 2016 +0200 Remove redundant only in manpage --- doc/tor.1.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/tor.1.txt b/doc/tor.1.txt index 6808a80..ac21806 100644 --- a/doc/tor.1.txt +++ b/doc/tor.1.txt @@ -30,7 +30,7 @@ Users bounce their TCP streams -- web traffic, ftp, ssh, etc. -- around the network, and recipients, observers, and even the relays themselves have difficulty tracking the source of the stream. -By default, **tor** will only act as a client only. To help the network +By default, **tor** will act as a client only. To help the network by providing bandwidth as a relay, change the **ORPort** configuration option -- see below. Please also consult the documentation on the Tor Project's website.

1 0

[tor/release-0.2.8] Remove a couple of redundant lines from the makefile
by nickm＠torproject.org 28 Mar '16

28 Mar '16

commit c8eb39d67f4ea5f913998ea4aae2d3ba3f3c8258 Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Mar 28 16:11:25 2016 -0400 Remove a couple of redundant lines from the makefile Fixes the last case of 17744. --- changes/bug17744_redux | 5 +++++ configure.ac | 2 -- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/changes/bug17744_redux b/changes/bug17744_redux new file mode 100644 index 0000000..d61e17f --- /dev/null +++ b/changes/bug17744_redux @@ -0,0 +1,5 @@ + o Minor bugfixes (build): + - Remove a pair of redundant AM_CONDITIONAL declarations from + configure.ac. Fixes one final case of bug 17744; bugfix on + 0.2.8.2-alpha. + diff --git a/configure.ac b/configure.ac index ad71f7f..e4816fd 100644 --- a/configure.ac +++ b/configure.ac @@ -58,8 +58,6 @@ fi AM_CONDITIONAL(UNITTESTS_ENABLED, test "x$enable_unittests" != "xno") AM_CONDITIONAL(COVERAGE_ENABLED, test "x$enable_coverage" = "xyes") -AM_CONDITIONAL(UNITTESTS_ENABLED, test x$enable_unittests != xno) -AM_CONDITIONAL(COVERAGE_ENABLED, test x$enable_coverage = xyes) AM_CONDITIONAL(DISABLE_ASSERTS_IN_UNIT_TESTS, test "x$enable_asserts_in_tests" = "xno") if test "$enable_static_tor" = "yes"; then

1 0

[tor/release-0.2.8] Merge remote-tracking branch 'sebastian/onlyonly' into maint-0.2.8
by nickm＠torproject.org 28 Mar '16

28 Mar '16

commit 79e534859b02c97418d9d46f524371defd2417d3 Merge: c8eb39d 7d6e7fd Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Mar 28 16:13:02 2016 -0400 Merge remote-tracking branch 'sebastian/onlyonly' into maint-0.2.8 doc/tor.1.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

1 0

[tor/maint-0.2.8] Remove redundant only in manpage
by nickm＠torproject.org 28 Mar '16

28 Mar '16

1 0

[tor/maint-0.2.8] Fix memory leak in TestingEnableCellStatsEvent
by nickm＠torproject.org 28 Mar '16

28 Mar '16

commit addd18172167e549b28efc8cf1132e1b8f9d3972 Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Mar 28 10:37:22 2016 -0400 Fix memory leak in TestingEnableCellStatsEvent Only when we were actually flushing the cell stats to a controller would we free them. Thus, they could stay in RAM even after the circuit was freed (eg if we didn't have any controllers). Fixes bug 18673; bugfix on 0.2.5.1-alpha. --- changes/bug18673 | 4 ++++ src/or/circuitlist.c | 14 ++++++++++++++ src/or/circuitlist.h | 2 ++ src/or/control.c | 6 ++---- 4 files changed, 22 insertions(+), 4 deletions(-) diff --git a/changes/bug18673 b/changes/bug18673 new file mode 100644 index 0000000..5d61617 --- /dev/null +++ b/changes/bug18673 @@ -0,0 +1,4 @@ + o Minor bugfixes (memory leak): + - Fix a small memory leak that would occur when the + TestingEnableCellStatsEvent option was turned on. Fixes bug 18673; + bugfix on 0.2.5.2-alpha. diff --git a/src/or/circuitlist.c b/src/or/circuitlist.c index d6532dd..670c5b3 100644 --- a/src/or/circuitlist.c +++ b/src/or/circuitlist.c @@ -756,6 +756,18 @@ or_circuit_new(circid_t p_circ_id, channel_t *p_chan) return circ; } +/** Free all storage held in circ->testing_cell_stats */ +void +circuit_clear_testing_cell_stats(circuit_t *circ) +{ + if (!circ) + return; + SMARTLIST_FOREACH(circ->testing_cell_stats, testing_cell_stats_entry_t *, + ent, tor_free(ent)); + smartlist_free(circ->testing_cell_stats); + circ->testing_cell_stats = NULL; +} + /** Deallocate space associated with circ. */ STATIC void @@ -767,6 +779,8 @@ circuit_free(circuit_t *circ) if (!circ) return; + circuit_clear_testing_cell_stats(circ); + if (CIRCUIT_IS_ORIGIN(circ)) { origin_circuit_t *ocirc = TO_ORIGIN_CIRCUIT(circ); mem = ocirc; diff --git a/src/or/circuitlist.h b/src/or/circuitlist.h index e4f1f47..2707b42 100644 --- a/src/or/circuitlist.h +++ b/src/or/circuitlist.h @@ -71,6 +71,8 @@ void assert_circuit_ok(const circuit_t *c); void circuit_free_all(void); void circuits_handle_oom(size_t current_allocation); +void circuit_clear_testing_cell_stats(circuit_t *circ); + void channel_note_destroy_pending(channel_t *chan, circid_t id); MOCK_DECL(void, channel_note_destroy_not_pending, (channel_t *chan, circid_t id)); diff --git a/src/or/control.c b/src/or/control.c index 2bec8f9..655b4dd 100644 --- a/src/or/control.c +++ b/src/or/control.c @@ -4971,7 +4971,7 @@ sum_up_cell_stats_by_command(circuit_t *circ, cell_stats_t *cell_stats) { memset(cell_stats, 0, sizeof(cell_stats_t)); SMARTLIST_FOREACH_BEGIN(circ->testing_cell_stats, - testing_cell_stats_entry_t *, ent) { + const testing_cell_stats_entry_t *, ent) { tor_assert(ent->command <= CELL_COMMAND_MAX_); if (!ent->removed && !ent->exitward) { cell_stats->added_cells_appward[ent->command] += 1; @@ -4984,10 +4984,8 @@ sum_up_cell_stats_by_command(circuit_t *circ, cell_stats_t *cell_stats) cell_stats->removed_cells_exitward[ent->command] += 1; cell_stats->total_time_exitward[ent->command] += ent->waiting_time * 10; } - tor_free(ent); } SMARTLIST_FOREACH_END(ent); - smartlist_free(circ->testing_cell_stats); - circ->testing_cell_stats = NULL; + circuit_clear_testing_cell_stats(circ); } /** Helper: append a cell statistics string to <code>event_parts</code>,

1 0

[tor/maint-0.2.8] Remove a couple of redundant lines from the makefile
by nickm＠torproject.org 28 Mar '16

28 Mar '16

1 0

[tor/maint-0.2.8] Merge remote-tracking branch 'sebastian/onlyonly' into maint-0.2.8
by nickm＠torproject.org 28 Mar '16

28 Mar '16

1 0

[tor/maint-0.2.8] Merge branch 'bug18673_028_v2' into maint-0.2.8
by nickm＠torproject.org 28 Mar '16

28 Mar '16

commit f780d196a91b8c9c5c2581d37326599b4e97b945 Merge: 79e5348 addd181 Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Mar 28 16:13:39 2016 -0400 Merge branch 'bug18673_028_v2' into maint-0.2.8 changes/bug18673 | 4 ++++ src/or/circuitlist.c | 14 ++++++++++++++ src/or/circuitlist.h | 2 ++ src/or/control.c | 6 ++---- 4 files changed, 22 insertions(+), 4 deletions(-)

1 0

[tor/master] Add more structure (and tests) to ReleasingTor.md
by nickm＠torproject.org 28 Mar '16

28 Mar '16

commit 05b52eea6aff88b6f7d6ce53c1b314bf31bc20cc Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Mar 28 16:07:19 2016 -0400 Add more structure (and tests) to ReleasingTor.md --- doc/HACKING/ReleasingTor.md | 66 ++++++++++++++++++++++++++++++++++----------- 1 file changed, 51 insertions(+), 15 deletions(-) diff --git a/doc/HACKING/ReleasingTor.md b/doc/HACKING/ReleasingTor.md index 2378aef..95b9bcd 100644 --- a/doc/HACKING/ReleasingTor.md +++ b/doc/HACKING/ReleasingTor.md @@ -4,13 +4,42 @@ Putting out a new release Here are the steps Roger takes when putting out a new Tor release: +=== 0. Preliminaries + +1. Get at least two of weasel/arma/Sebastian to put the new version number + in their approved versions list. + + +=== I. Make sure it works + 1. Use it for a while, as a client, as a relay, as a hidden service, and as a directory authority. See if it has any obvious bugs, and resolve those. As applicable, merge the `maint-X` branch into the `release-X` branch. -2. Gather the `changes/*` files into a changelog entry, rewriting many +2. Are all of the jenkins builders happy? See jenkins.torproject.org. + + What about the bsd buildbots? + See http://buildbot.pixelminers.net/builders/ + + What about Coverity Scan? + + Is make check-spaces happy? + + Does 'make distcheck' compain? + + How about 'make test-stem' and 'make test-network'? + + - Are all those tests still happy with --enable-expensive-hardening ? + + Any memory leaks? + + +=== II. Write a changelog. + + +1. Gather the `changes/*` files into a changelog entry, rewriting many of them and reordering to focus on what users and funders would find interesting and understandable. @@ -62,13 +91,13 @@ Here are the steps Roger takes when putting out a new Tor release: 7. Run `./scripts/maint/format_changelog.py` to make it prettier. -3. Compose a short release blurb to highlight the user-facing +2. Compose a short release blurb to highlight the user-facing changes. Insert said release blurb into the ChangeLog stanza. If it's a stable release, add it to the ReleaseNotes file too. If we're adding to a release-0.2.x branch, manually commit the changelogs to the later git branches too. - If you're doing the first stable release in a series, you need to +3. If you're doing the first stable release in a series, you need to create a ReleaseNotes for the series as a whole. To get started there, copy all of the Changelog entries from the series into a new file, and run `./scripts/maint/sortChanges.py` on it. That will @@ -78,7 +107,10 @@ Here are the steps Roger takes when putting out a new Tor release: to start sorting and condensing entries. (Generally, we don't edit the text of existing entries, though.) -4. In `maint-0.2.x`, bump the version number in `configure.ac` and run + +=== III. Making the source release. + +1. In `maint-0.2.x`, bump the version number in `configure.ac` and run `scripts/maint/updateVersions.pl` to update version numbers in other places, and commit. Then merge `maint-0.2.x` into `release-0.2.x`. @@ -86,20 +118,19 @@ Here are the steps Roger takes when putting out a new Tor release: either `make`, or `perl scripts/maint/updateVersions.pl`, depending on your version.) -5. Make distcheck, put the tarball up somewhere, and tell `#tor` about +2. Make distcheck, put the tarball up somewhere, and tell `#tor` about it. Wait a while to see if anybody has problems building it. Try to get Sebastian or somebody to try building it on Windows. -6. Get at least two of weasel/arma/Sebastian to put the new version number - in their approved versions list. +=== IV. Commit, upload, announce -7. Sign the tarball, then sign and push the git tag: +1. Sign the tarball, then sign and push the git tag: gpg -ba <the_tarball> git tag -u <keyid> tor-0.2.x.y-status git push origin tag tor-0.2.x.y-status -8. scp the tarball and its sig to the dist website, i.e. +2. scp the tarball and its sig to the dist website, i.e. `/srv/dist-master.torproject.org/htdocs/` on dist-master. When you want it to go live, you run "static-update-component dist.torproject.org" on dist-master. @@ -110,7 +141,7 @@ Here are the steps Roger takes when putting out a new Tor release: once. Nonetheless, do not call your version "alpha" if it is stable, or people will get confused.) -9. Email the packagers (cc'ing tor-assistants) that a new tarball is up. +3. Email the packagers (cc'ing tor-assistants) that a new tarball is up. The current list of packagers is: - {weasel,gk,mikeperry} at torproject dot org @@ -120,24 +151,29 @@ Here are the steps Roger takes when putting out a new Tor release: - {lfleischer} at archlinux dot org - {tails-dev} at boum dot org -10. Add the version number to Trac. To do this, go to Trac, log in, +4. Add the version number to Trac. To do this, go to Trac, log in, select "Admin" near the top of the screen, then select "Versions" from the menu on the left. At the right, there will be an "Add version" box. By convention, we enter the version in the form "Tor: 0.2.2.23-alpha" (or whatever the version is), and we select the date as the date in the ChangeLog. -11. Forward-port the ChangeLog (and ReleaseNotes if appropriate). - -12. Wait up to a day or two (for a development release), or until most +5. Wait up to a day or two (for a development release), or until most packages are up (for a stable release), and mail the release blurb and changelog to tor-talk or tor-announce. (We might be moving to faster announcements, but don't announce until the website is at least updated.) -13. If it's a stable release, bump the version number in the `maint-x.y.z` + +=== V. Aftermath and cleanup + +1. If it's a stable release, bump the version number in the `maint-x.y.z` branch to "newversion-dev", and do a `merge -s ours` merge to avoid taking that change into master. Do a similar `merge -s theirs` merge to get the change (and only that change) into release. (Some of the build scripts require that maint merge cleanly into release.) + +2. Forward-port the ChangeLog (and ReleaseNotes if appropriate). + +

1 0

[tor/master] Merge branch 'reldoc'
by nickm＠torproject.org 28 Mar '16

28 Mar '16

commit 1275d923990b668632126890e19cd50224c79101 Merge: 447b1c6 05b52ee Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Mar 28 16:07:27 2016 -0400 Merge branch 'reldoc' doc/HACKING/ReleasingTor.md | 66 ++++++++++++++++++++++++++++++++++----------- 1 file changed, 51 insertions(+), 15 deletions(-)

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits March 2016