tor-commits

tor-commits@lists.torproject.org

1 participants
212433 discussions

[tor/master] Merge remote-tracking branch 'origin/maint-0.2.2'
by nickm＠torproject.org 26 Apr '11

26 Apr '11

commit 47f472510fab2bc2c06e53ee932b13cfe1bdcbe4 Merge: 6a726d3 bb6d45a Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Apr 26 12:49:58 2011 -0400 Merge remote-tracking branch 'origin/maint-0.2.2' Conflicts: src/or/rephist.c changes/bug2899 | 4 ++++ src/or/rephist.c | 42 ++++++++++++++++++++++-------------------- src/or/routerlist.c | 4 ++-- 3 files changed, 28 insertions(+), 22 deletions(-)

1 0

[tor/maint-0.2.2] Downgrade notice to info when downloading a cert.
by nickm＠torproject.org 26 Apr '11

26 Apr '11

commit bb6d45af1fc738b9f71e798cde6c7564172b6e04 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Apr 26 12:46:07 2011 -0400 Downgrade notice to info when downloading a cert. --- changes/bug2899 | 4 ++++ src/or/routerlist.c | 4 ++-- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/changes/bug2899 b/changes/bug2899 new file mode 100644 index 0000000..6af86d0 --- /dev/null +++ b/changes/bug2899 @@ -0,0 +1,4 @@ + - Minor bugfixes: + o Downgrade "no current certificates known for authority" message from + Notice to Info. Bugfix on 0.2.0.10-alpha; fixes bug 2899. + diff --git a/src/or/routerlist.c b/src/or/routerlist.c index 4deff53..c02654f 100644 --- a/src/or/routerlist.c +++ b/src/or/routerlist.c @@ -531,8 +531,8 @@ authority_certs_fetch_missing(networkstatus_t *status, time_t now) if (!found && download_status_is_ready(&cl->dl_status, now,MAX_CERT_DL_FAILURES) && !digestmap_get(pending, ds->v3_identity_digest)) { - log_notice(LD_DIR, "No current certificate known for authority %s; " - "launching request.", ds->nickname); + log_info(LD_DIR, "No current certificate known for authority %s; " + "launching request.", ds->nickname); smartlist_add(missing_digests, ds->v3_identity_digest); } } SMARTLIST_FOREACH_END(ds);

1 0

[arm/master] fix: Accounting for multiple results from lsof
by atagar＠torproject.org 26 Apr '11

26 Apr '11

commit 12077adddb88f1a2e7ae2f8e0078c54ce3e70fd2 Author: Damian Johnson <atagar(a)torproject.org> Date: Tue Apr 26 08:32:50 2011 -0700 fix: Accounting for multiple results from lsof When querying lsof from the python process this can provide multiple results with the same pid. The second is from the lsof query itself (this was observed with an earlier change for querying our own process). Accounting for this by checking all pid results from the query to see if they're in agreement. --- src/util/torTools.py | 16 ++++++++++++++-- 1 files changed, 14 insertions(+), 2 deletions(-) diff --git a/src/util/torTools.py b/src/util/torTools.py index 08b04c0..f4a29af 100644 --- a/src/util/torTools.py +++ b/src/util/torTools.py @@ -224,8 +224,20 @@ def getPid(controlPort=9051, pidFilePath=None): try: results = sysTools.call("lsof -wnPi | egrep \"^tor.*:%i\"" % controlPort) - if len(results) == 1 and len(results[0].split()) > 1: - pid = results[0].split()[1] + + # This can result in multiple entries with the same pid (maybe from the + # query itself?). Checking all lines to see if they have the same pid. + + if results: + pid = "" + + for line in results: + lineComp = line.split() + + if len(lineComp) >= 2 and (not pid or lineComp[1] == pid): + pid = lineComp[1] + else: raise IOError + if pid.isdigit(): return pid except IOError: pass

1 0

[tor/maint-0.2.2] fix some comments before they create conflicts
by arma＠torproject.org 26 Apr '11

26 Apr '11

commit 9d673dcd206289bceb8f5ff527e63336ef0a50b9 Author: Roger Dingledine <arma(a)torproject.org> Date: Tue Apr 26 11:28:49 2011 -0400 fix some comments before they create conflicts --- src/or/rephist.c | 44 +++++++++++++++++++++++--------------------- 1 files changed, 23 insertions(+), 21 deletions(-) diff --git a/src/or/rephist.c b/src/or/rephist.c index 524cd1d..5703e3e 100644 --- a/src/or/rephist.c +++ b/src/or/rephist.c @@ -992,10 +992,10 @@ find_next_with(smartlist_t *sl, int i, const char *prefix) return -1; } -/** How many bad times has parse_possibly_bad_iso_time parsed? */ +/** How many bad times has parse_possibly_bad_iso_time() parsed? */ static int n_bogus_times = 0; /** Parse the ISO-formatted time in s into *time_out, but - * rounds any pre-1970 date to Jan 1, 1970. */ + * round any pre-1970 date to Jan 1, 1970. */ static int parse_possibly_bad_iso_time(const char *s, time_t *time_out) { @@ -1288,7 +1288,7 @@ commit_max(bw_array_t *b) b->total_in_period = 0; } -/** Shift the current observation time of 'b' forward by one second. */ +/** Shift the current observation time of b forward by one second. */ static INLINE void advance_obs(bw_array_t *b) { @@ -1318,16 +1318,16 @@ advance_obs(bw_array_t *b) static INLINE void add_obs(bw_array_t *b, time_t when, uint64_t n) { - /* Don't record data in the past. */ - if (when<b->cur_obs_time) - return; + if (when < b->cur_obs_time) + return; /* Don't record data in the past. */ + /* If we're currently adding observations for an earlier second than * 'when', advance b->cur_obs_time and b->cur_obs_idx by an - * appropriate number of seconds, and do all the other housekeeping */ - while (when>b->cur_obs_time) { + * appropriate number of seconds, and do all the other housekeeping. */ + while (when > b->cur_obs_time) { /* Doing this one second at a time is potentially inefficient, if we start with a state file that is very old. Fortunately, it doesn't seem to - show up in profiles, so we can just ignore it for now. */ + show up in profiles, so we can just ignore it for now. */ advance_obs(b); } @@ -1375,7 +1375,7 @@ bw_arrays_init(void) dir_write_array = bw_array_new(); } -/** We read num_bytes more bytes in second when. +/** Remember that we read num_bytes bytes in second when. * * Add num_bytes to the current running total for when. * @@ -1396,7 +1396,7 @@ rep_hist_note_bytes_written(size_t num_bytes, time_t when) add_obs(write_array, when, num_bytes); } -/** We wrote num_bytes more bytes in second when. +/** Remember that we wrote num_bytes bytes in second when. * (like rep_hist_note_bytes_written() above) */ void @@ -1406,8 +1406,8 @@ rep_hist_note_bytes_read(size_t num_bytes, time_t when) add_obs(read_array, when, num_bytes); } -/** We wrote num_bytes more directory bytes in second when. - * (like rep_hist_note_bytes_written() above) +/** Remember that we wrote num_bytes directory bytes in second + * when. (like rep_hist_note_bytes_written() above) */ void rep_hist_note_dir_bytes_written(size_t num_bytes, time_t when) @@ -1415,8 +1415,8 @@ rep_hist_note_dir_bytes_written(size_t num_bytes, time_t when) add_obs(dir_write_array, when, num_bytes); } -/** We read num_bytes more directory bytes in second when. - * (like rep_hist_note_bytes_written() above) +/** Remember that we read num_bytes directory bytes in second + * when. (like rep_hist_note_bytes_written() above) */ void rep_hist_note_dir_bytes_read(size_t num_bytes, time_t when) @@ -1511,7 +1511,8 @@ rep_hist_fill_bandwidth_history(char *buf, size_t len, const bw_array_t *b) } /** Allocate and return lines for representing this server's bandwidth - * history in its descriptor. + * history in its descriptor. We publish these lines in our extra-info + * descriptor. */ char * rep_hist_get_bandwidth_lines(void) @@ -1559,7 +1560,7 @@ rep_hist_get_bandwidth_lines(void) } /** Write a single bw_array_t into the Values, Ends, Interval, and Maximum - * entries of an or_state_t. */ + * entries of an or_state_t. Done before writing out a new state file. */ static void rep_hist_update_bwhist_state_section(or_state_t *state, const bw_array_t *b, @@ -1619,7 +1620,8 @@ rep_hist_update_bwhist_state_section(or_state_t *state, smartlist_add(*s_maxima, cp); } -/** Update state with the newest bandwidth history. */ +/** Update state with the newest bandwidth history. Done before + * writing out a new state file. */ void rep_hist_update_state(or_state_t *state) { @@ -1643,7 +1645,7 @@ rep_hist_update_state(or_state_t *state) } /** Load a single bw_array_t from its Values, Ends, Maxima, and Interval - * entries in an or_state_t. */ + * entries in an or_state_t. Done while reading the state file. */ static int rep_hist_load_bwhist_state_section(bw_array_t *b, const smartlist_t *s_values, @@ -1718,7 +1720,7 @@ rep_hist_load_bwhist_state_section(bw_array_t *b, return retval; } -/** Set bandwidth history from our saved state. */ +/** Set bandwidth history from the state file we just loaded. */ int rep_hist_load_state(or_state_t *state, char **err) { @@ -1766,7 +1768,7 @@ static smartlist_t *predicted_ports_times=NULL; static void add_predicted_port(time_t now, uint16_t port) { - /* XXXX we could just use uintptr_t here, I think. */ + /* XXXX we could just use uintptr_t here, I think. -NM */ uint16_t *tmp_port = tor_malloc(sizeof(uint16_t)); time_t *tmp_time = tor_malloc(sizeof(time_t)); *tmp_port = port;

1 0

[tor/master] Fix more of bug 2704
by nickm＠torproject.org 26 Apr '11

26 Apr '11

commit 6fde2b46d2cc2345ec955b1ed9674a777e5e8716 Author: Sebastian Hahn <sebastian(a)torproject.org> Date: Tue Apr 26 15:33:08 2011 +0200 Fix more of bug 2704 The last entry of the *Maxima values in the state file was inflated by a factor of NUM_SECS_ROLLING_MEASURE (currently 10). This could lead to a wrong maximum value propagating through the state file history. --- changes/bug2704 | 5 +++++ src/or/rephist.c | 3 ++- 2 files changed, 7 insertions(+), 1 deletions(-) diff --git a/changes/bug2704 b/changes/bug2704 new file mode 100644 index 0000000..821b38b --- /dev/null +++ b/changes/bug2704 @@ -0,0 +1,5 @@ + o Major bugfixes: + - When writing our maximum bw for the current interval to the state + file, don't wrongly inflate that value by a factor of 10 anymore. + Fixes more of bug 2704. + diff --git a/src/or/rephist.c b/src/or/rephist.c index fb091d5..9146fce 100644 --- a/src/or/rephist.c +++ b/src/or/rephist.c @@ -1614,7 +1614,8 @@ rep_hist_update_bwhist_state_section(or_state_t *state, } tor_asprintf(&cp, U64_FORMAT, U64_PRINTF_ARG(b->total_in_period & ~0x3ff)); smartlist_add(*s_values, cp); - tor_asprintf(&cp, U64_FORMAT, U64_PRINTF_ARG(b->max_total & ~0x3ff)); + maxval = b->max_total / NUM_SECS_ROLLING_MEASURE; + tor_asprintf(&cp, U64_FORMAT, U64_PRINTF_ARG(maxval & ~0x3ff)); smartlist_add(*s_maxima, cp); }

1 0

[tor/master] Merge remote-tracking branch 'sebastian/bug2704' into maint-0.2.2
by nickm＠torproject.org 26 Apr '11

26 Apr '11

commit f083347adf40164aac3b77d118ec372c89178d5a Merge: 4c789ec 6fde2b4 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Apr 26 11:07:48 2011 -0400 Merge remote-tracking branch 'sebastian/bug2704' into maint-0.2.2 changes/bug2704 | 5 +++++ src/or/rephist.c | 3 ++- 2 files changed, 7 insertions(+), 1 deletions(-)

1 0

[tor/master] Fix compilation in last patch
by nickm＠torproject.org 26 Apr '11

26 Apr '11

commit 1cff525973c9e3934a4e1661b721b8a13d20ff72 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Apr 26 11:14:46 2011 -0400 Fix compilation in last patch --- src/or/rephist.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/or/rephist.c b/src/or/rephist.c index 9146fce..524cd1d 100644 --- a/src/or/rephist.c +++ b/src/or/rephist.c @@ -1570,6 +1570,7 @@ rep_hist_update_bwhist_state_section(or_state_t *state, { char *cp; int i,j; + uint64_t maxval; if (*s_values) { SMARTLIST_FOREACH(*s_values, char *, val, tor_free(val)); @@ -1603,7 +1604,6 @@ rep_hist_update_bwhist_state_section(or_state_t *state, /* Set i to first position in circular array */ i = (b->num_maxes_set <= b->next_max_idx) ? 0 : b->next_max_idx; for (j=0; j < b->num_maxes_set; ++j,++i) { - uint64_t maxval; if (i >= NUM_TOTALS) i = 0; tor_asprintf(&cp, U64_FORMAT, U64_PRINTF_ARG(b->totals[i] & ~0x3ff));

1 0

[tor/master] Merge remote-tracking branch 'origin/maint-0.2.2'
by nickm＠torproject.org 26 Apr '11

26 Apr '11

commit 6a726d34e175e40cbf86617f9f9c761b52929f96 Merge: 075d904 1cff525 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Apr 26 11:15:03 2011 -0400 Merge remote-tracking branch 'origin/maint-0.2.2' changes/bug2704 | 5 +++++ src/or/rephist.c | 5 +++-- 2 files changed, 8 insertions(+), 2 deletions(-)

1 0

[tor/maint-0.2.2] Fix compilation in last patch
by nickm＠torproject.org 26 Apr '11

26 Apr '11

1 0

[tor/maint-0.2.2] Fix more of bug 2704
by nickm＠torproject.org 26 Apr '11

26 Apr '11

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits