engine: tor pubsub_install tor_raw_abort #2406
Assignees
Labels
bug
Something isn't working
interrupt
needs investigation
This issue needs extra data and investigation
ooni/probe-engine
platform/android
priority/high
testing
Comments
bassosimone
added
bug
|
The relevant tor code is the following: /** Install the publish/subscribe relationships for all the subsystems. */
void
pubsub_install(void)
{
pubsub_builder_t *builder = pubsub_builder_new();
int r = subsystems_add_pubsub(builder);
tor_assert(r == 0);
r = tor_mainloop_connect_pubsub(builder); // consumes builder
tor_assert(r == 0);
}It's not completely clear to me whether the first or the second |
|
I applied the following patch to investigate: diff --git a/src/app/main/main.c b/src/app/main/main.c
index 838e129d04..3aa1b334fa 100644
--- a/src/app/main/main.c
+++ b/src/app/main/main.c
@@ -92,6 +92,8 @@
#include <unistd.h>
#endif
+#include <stdio.h>
+
#ifdef HAVE_SYSTEMD
# if defined(__COVERITY__) && !defined(__INCLUDE_LEVEL__)
/* Systemd's use of gcc's __INCLUDE_LEVEL__ extension macro appears to confuse
@@ -1284,8 +1286,16 @@ pubsub_install(void)
{
pubsub_builder_t *builder = pubsub_builder_new();
int r = subsystems_add_pubsub(builder);
+ if (r != 0) {
+ fprintf(stderr, "SBSDEBUG: subsystems_add_pubsub failed: %d\n", r);
+ /* FALLTHROUGH */
+ }
tor_assert(r == 0);
r = tor_mainloop_connect_pubsub(builder); // consumes builder
+ if (r != 0) {
+ fprintf(stderr, "SBSDEBUG: tor_mainloop_connect_pubsub failed: %d\n", r);
+ /* FALLTHROUGH */
+ }
tor_assert(r == 0);
}
I saw the following logs before the usual crash: So, we see that the issue happens when we run It's also worth mentioning that this kind of crash is currently the number one cause of crashes in the Android app based on the information that we could retrieve from the Google Play console. So, it's worth investigating it. |
|
I wrote an extended patch to log more messages: diff --git a/src/app/main/main.c b/src/app/main/main.c
index 838e129d04..3aa1b334fa 100644
--- a/src/app/main/main.c
+++ b/src/app/main/main.c
@@ -92,6 +92,8 @@
#include <unistd.h>
#endif
+#include <stdio.h>
+
#ifdef HAVE_SYSTEMD
# if defined(__COVERITY__) && !defined(__INCLUDE_LEVEL__)
/* Systemd's use of gcc's __INCLUDE_LEVEL__ extension macro appears to confuse
@@ -1284,8 +1286,16 @@ pubsub_install(void)
{
pubsub_builder_t *builder = pubsub_builder_new();
int r = subsystems_add_pubsub(builder);
+ if (r != 0) {
+ fprintf(stderr, "SBSDEBUG: subsystems_add_pubsub failed: %d\n", r);
+ /* FALLTHROUGH */
+ }
tor_assert(r == 0);
r = tor_mainloop_connect_pubsub(builder); // consumes builder
+ if (r != 0) {
+ fprintf(stderr, "SBSDEBUG: tor_mainloop_connect_pubsub failed: %d\n", r);
+ /* FALLTHROUGH */
+ }
tor_assert(r == 0);
}
diff --git a/src/core/mainloop/mainloop_pubsub.c b/src/core/mainloop/mainloop_pubsub.c
index 1e72ada5f0..72dd348a2e 100644
--- a/src/core/mainloop/mainloop_pubsub.c
+++ b/src/core/mainloop/mainloop_pubsub.c
@@ -26,6 +26,8 @@
#include "lib/pubsub/pubsub.h"
#include "lib/pubsub/pubsub_build.h"
+#include <stdio.h>
+
/**
* Dispatcher to use for delivering messages.
**/
@@ -63,8 +65,10 @@ tor_mainloop_connect_pubsub(struct pubsub_builder_t *builder)
tor_mainloop_disconnect_pubsub();
the_dispatcher = pubsub_builder_finalize(builder, &the_pubsub_items);
- if (! the_dispatcher)
+ if (! the_dispatcher) {
+ fprintf(stderr, "SBSDEBUG: the_distpatcher is NULL\n");
goto err;
+ }
rv = 0;
goto done;
diff --git a/src/lib/pubsub/pubsub_build.c b/src/lib/pubsub/pubsub_build.c
index 30b9194062..6a554c06bd 100644
--- a/src/lib/pubsub/pubsub_build.c
+++ b/src/lib/pubsub/pubsub_build.c
@@ -25,7 +25,8 @@
#include "lib/log/util_bug.h"
#include "lib/malloc/malloc.h"
- #include <string.h>
+#include <string.h>
+#include <stdio.h>
/** Construct and return a new empty pubsub_items_t. */
static pubsub_items_t *
@@ -281,19 +282,24 @@ pubsub_builder_finalize(pubsub_builder_t *builder,
dispatch_t *dispatcher = NULL;
tor_assert_nonfatal(builder->n_connectors == 0);
- if (pubsub_builder_check(builder) < 0)
+ if (pubsub_builder_check(builder) < 0) {
+ fprintf(stderr, "SBSDEBUG: pubsub_builder_check failed\n");
goto err;
+ }
if (builder->n_errors) {
log_warn(LD_GENERAL, "At least one error occurred previously when "
"configuring the dispatcher.");
+ fprintf(stderr, "SBSDEBUG: builder->n_errors is not zero\n");
goto err;
}
dispatcher = dispatch_new(builder->cfg);
- if (!dispatcher)
+ if (!dispatcher) {
+ fprintf(stderr, "SBSDEBUG: dispatcher_new failed\n");
goto err;
+ }
pubsub_items_install_bindings(builder->items, dispatcher);
if (items_out) {
This is an excerpt from the logs: So, now we know that the function that fails is |
|
Since I introduced the following diff: diff --git a/src/lib/pubsub/pubsub_check.c b/src/lib/pubsub/pubsub_check.c
index 99e604d715..a9ae957551 100644
--- a/src/lib/pubsub/pubsub_check.c
+++ b/src/lib/pubsub/pubsub_check.c
@@ -25,6 +25,7 @@
#include "lib/malloc/malloc.h"
#include "lib/string/compat_string.h"
+#include <stdio.h>
#include <string.h>
static void pubsub_adjmap_add(pubsub_adjmap_t *map,
@@ -343,21 +344,27 @@ lint_message(const pubsub_adjmap_t *map, message_id_t msg)
log_warn(LD_MESG|LD_BUG,
"Message \"%s\" has subscribers, but no publishers.",
get_message_id_name(msg));
+ fprintf(stderr, "SBSDEBUG: n_pub == 0\n");
ok = false;
} else if (n_sub == 0) {
log_warn(LD_MESG|LD_BUG,
"Message \"%s\" has publishers, but no subscribers.",
get_message_id_name(msg));
+ fprintf(stderr, "SBSDEBUG: n_sub == 0\n");
ok = false;
}
/* Check the message graph topology. */
- if (lint_message_graph(map, msg, pub, sub) < 0)
+ if (lint_message_graph(map, msg, pub, sub) < 0) {
+ fprintf(stderr, "SBSDEBUG: lint_message_graph failed\n");
ok = false;
+ }
/* Check whether the messages have the same fields set on them. */
- if (lint_message_consistency(msg, pub, sub) < 0)
+ if (lint_message_consistency(msg, pub, sub) < 0) {
+ fprintf(stderr, "SBSDEBUG: lint_message_consistency failed\n");
ok = false;
+ }
if (!ok) {
/* There was a problem -- let's log all the publishers and subscribers on
@@ -385,6 +392,7 @@ pubsub_adjmap_check(const pubsub_adjmap_t *map)
bool all_ok = true;
for (unsigned i = 0; i < map->n_msgs; ++i) {
if (lint_message(map, i) < 0) {
+ fprintf(stderr, "lint_message failed for %u\n", i);
all_ok = false;
}
}
@@ -401,11 +409,15 @@ pubsub_builder_check(pubsub_builder_t *builder)
pubsub_adjmap_t *map = pubsub_build_adjacency_map(builder->items);
int rv = -1;
- if (!map)
+ if (!map) {
+ fprintf(stderr, "SBSDEBUG: pubsub_build_adjacency_map failed\n");
goto err; // should be impossible
+ }
- if (pubsub_adjmap_check(map) < 0)
+ if (pubsub_adjmap_check(map) < 0) {
+ fprintf(stderr, "SBSDEBUG: pubsub_adjmap_check failed\n");
goto err;
+ }
rv = 0;
err:
I am not able to reproduce the problem anymore. I run 39 tests with this diff plus other |
|
After reverting all the patches, I finally managed to see another crash. Here is the logcat: This was the 13th run. However, it was the third run in a row where I was running all tests as opposed to just running tor. |
|
I spent some time wondering whether this crash could be a memory corruption caused by code we introduced in ooni/probe-cli#1052 and other pull requests. To understand whether that was the case, I searched for crashes in the Google Play Console. I found the same crash for ooniprobe-android 3.7.3 (95). This release of the Android app is definitely using a version engine that predates ooni/probe-cli#1052. Here's one of the stacktrace(s) provided by the Google Play console (others look similar): This event occurred 526 times in the last 28 days. There are more crashes that look like this one, but it is not clear to me how come that they are not grouped together. Perhaps the strings of the stacktrace slightly differ depending on the actual mechanism with which the app has been installed. |
bassosimone
added a commit
to ooni/probe-cli
that referenced
this issue
Feb 9, 2023
This diff modifies tunnel, torsf, and vanilla such that: 1. we return a special error when tor is not found on PATH 2. we use such an error to avoid submitting By doing that, we save some useless submissions. Part of ooni/probe#2406 because I wrote this diff while investigating it.
|
With ooni/probe-cli@a372027, I tried to make a reproducible test case for Linux but, so far, no luck. |
|
Hooray! I could finally reproduce the issue on Linux after 26 repetitions. This is the relevant crash log: The above log provides us with the following information:
I still do not fully understand what these messages are and why would this happen. There is also something weird with the number of blocked goroutines; see #2443. |
|
It turns out the previous patch produced not-so-actionable data. Here's a better patch: diff --git a/src/lib/pubsub/pubsub_check.c b/src/lib/pubsub/pubsub_check.c
index 99e604d715..a5cc4b7658 100644
--- a/src/lib/pubsub/pubsub_check.c
+++ b/src/lib/pubsub/pubsub_check.c
@@ -25,6 +25,7 @@
#include "lib/malloc/malloc.h"
#include "lib/string/compat_string.h"
+#include <stdio.h>
#include <string.h>
static void pubsub_adjmap_add(pubsub_adjmap_t *map,
@@ -343,21 +344,27 @@ lint_message(const pubsub_adjmap_t *map, message_id_t msg)
log_warn(LD_MESG|LD_BUG,
"Message \"%s\" has subscribers, but no publishers.",
get_message_id_name(msg));
+ fprintf(stderr, "SBSDEBUG: n_pub == 0 for %s\n", get_message_id_name(msg));
ok = false;
} else if (n_sub == 0) {
log_warn(LD_MESG|LD_BUG,
"Message \"%s\" has publishers, but no subscribers.",
get_message_id_name(msg));
+ fprintf(stderr, "SBSDEBUG: n_sub == 0 for %s\n", get_message_id_name(msg));
ok = false;
}
/* Check the message graph topology. */
- if (lint_message_graph(map, msg, pub, sub) < 0)
+ if (lint_message_graph(map, msg, pub, sub) < 0) {
+ fprintf(stderr, "SBSDEBUG: lint_message_graph failed for %s\n", get_message_id_name(msg));
ok = false;
+ }
/* Check whether the messages have the same fields set on them. */
- if (lint_message_consistency(msg, pub, sub) < 0)
+ if (lint_message_consistency(msg, pub, sub) < 0) {
+ fprintf(stderr, "SBSDEBUG: lint_message_consistency failed for %s\n", get_message_id_name(msg));
ok = false;
+ }
if (!ok) {
/* There was a problem -- let's log all the publishers and subscribers on
@@ -385,6 +392,7 @@ pubsub_adjmap_check(const pubsub_adjmap_t *map)
bool all_ok = true;
for (unsigned i = 0; i < map->n_msgs; ++i) {
if (lint_message(map, i) < 0) {
+ fprintf(stderr, "SBSDEBUG: lint_message failed for %u %s\n", i, get_message_id_name((message_id_t)i));
all_ok = false;
}
}
@@ -401,11 +409,15 @@ pubsub_builder_check(pubsub_builder_t *builder)
pubsub_adjmap_t *map = pubsub_build_adjacency_map(builder->items);
int rv = -1;
- if (!map)
+ if (!map) {
+ fprintf(stderr, "SBSDEBUG: pubsub_build_adjacency_map failed\n");
goto err; // should be impossible
+ }
- if (pubsub_adjmap_check(map) < 0)
+ if (pubsub_adjmap_check(map) < 0) {
+ fprintf(stderr, "SBSDEBUG: pubsub_adjmap_check failed\n");
goto err;
+ }
rv = 0;
err:Now, let's go fishing for |
|
This time it crashed in a completely different way after 24 runs: This is not the error I expected, but it still seems interesting because it's again related to pubsub. I am going to fish for a couple more errors before trying to use |
|
Another crash (we are starting to shed some light on what happens, I think) after 17 runs: Another crash after 16 runs: Another crash after 6 runs: Another crash after 6 runs: Another crash after 6 runs: Another crash after 6 runs: |
|
I tried to use export CGO_LDFLAGS="-ltsan"This export turned out to be quite serendipitous (well, maybe?). Here's the crash log: Now, it would be my pleasure to figure out what I am looking at 😬. |
|
I added ooni/probe-cli@51292a4 and ooni/probe-cli@9e5e967, which solve part of the data race that existed, however, I still see the following in the logs: I don't fully understand the first race. I am not sure what happens later. I think the main issue at the moment is that I am using the race detector only for C code compiled by Go, due to the |
|
With ooni/probe-cli@ef7ec14, I wrote a C test case that bypasses Go code and runs tor more or less like we run it from Go. The main difference with that code is that we do not disable networking and then re-enable it as part of the bootstrap of tor. I chose to go down this road because I could not manage to compile tor with What is very interesting (and unexpected by me) here is that we don't see any data races. I am reasonably sure I have compiled the code using So, it seems it's possible to reduce the problem to just using C code with tor 0.4.7.13. Now, it would probably be useful to further reduce the minimal test case to avoid recompiling all the dependencies (but It may also be a good idea to check whether the problem has been fixed in the main development branch. |
|
So, I managed to write a minimal example to reproduce the behavior. Copying from my notes:
diff --git a/src/lib/pubsub/pubsub_check.c b/src/lib/pubsub/pubsub_check.c
index 99e604d715..a5cc4b7658 100644
--- a/src/lib/pubsub/pubsub_check.c
+++ b/src/lib/pubsub/pubsub_check.c
@@ -25,6 +25,7 @@
#include "lib/malloc/malloc.h"
#include "lib/string/compat_string.h"
+#include <stdio.h>
#include <string.h>
static void pubsub_adjmap_add(pubsub_adjmap_t *map,
@@ -343,21 +344,27 @@ lint_message(const pubsub_adjmap_t *map, message_id_t msg)
log_warn(LD_MESG|LD_BUG,
"Message \"%s\" has subscribers, but no publishers.",
get_message_id_name(msg));
+ fprintf(stderr, "SBSDEBUG: n_pub == 0 for %s\n", get_message_id_name(msg));
ok = false;
} else if (n_sub == 0) {
log_warn(LD_MESG|LD_BUG,
"Message \"%s\" has publishers, but no subscribers.",
get_message_id_name(msg));
+ fprintf(stderr, "SBSDEBUG: n_sub == 0 for %s\n", get_message_id_name(msg));
ok = false;
}
/* Check the message graph topology. */
- if (lint_message_graph(map, msg, pub, sub) < 0)
+ if (lint_message_graph(map, msg, pub, sub) < 0) {
+ fprintf(stderr, "SBSDEBUG: lint_message_graph failed for %s\n", get_message_id_name(msg));
ok = false;
+ }
/* Check whether the messages have the same fields set on them. */
- if (lint_message_consistency(msg, pub, sub) < 0)
+ if (lint_message_consistency(msg, pub, sub) < 0) {
+ fprintf(stderr, "SBSDEBUG: lint_message_consistency failed for %s\n", get_message_id_name(msg));
ok = false;
+ }
if (!ok) {
/* There was a problem -- let's log all the publishers and subscribers on
@@ -385,6 +392,7 @@ pubsub_adjmap_check(const pubsub_adjmap_t *map)
bool all_ok = true;
for (unsigned i = 0; i < map->n_msgs; ++i) {
if (lint_message(map, i) < 0) {
+ fprintf(stderr, "SBSDEBUG: lint_message failed for %u %s\n", i, get_message_id_name((message_id_t)i));
all_ok = false;
}
}
@@ -401,11 +409,15 @@ pubsub_builder_check(pubsub_builder_t *builder)
pubsub_adjmap_t *map = pubsub_build_adjacency_map(builder->items);
int rv = -1;
- if (!map)
+ if (!map) {
+ fprintf(stderr, "SBSDEBUG: pubsub_build_adjacency_map failed\n");
goto err; // should be impossible
+ }
- if (pubsub_adjmap_check(map) < 0)
+ if (pubsub_adjmap_check(map) < 0) {
+ fprintf(stderr, "SBSDEBUG: pubsub_adjmap_check failed\n");
goto err;
+ }
rv = 0;
err:
#include "../src/feature/api/tor_api.h"
#include <pthread.h>
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
static void *threadMain(void *ptr) {
int *fdp = (int*)ptr;
(void)sleep(45 /* second */);
(void)close(*fdp);
free(fdp);
return NULL;
}
int main() {
for (;;) {
tor_main_configuration_t *config = tor_main_configuration_new();
if (config == NULL) {
exit(1);
}
char *argv[] = {
"tor",
"Log",
"notice stderr",
"DataDirectory",
"./x",
NULL,
};
int argc = 5;
if (tor_main_configuration_set_command_line(config, argc, argv) != 0) {
exit(2);
}
int filedesc = tor_main_configuration_setup_control_socket(config);
if (filedesc < 0) {
exit(3);
}
int *fdp = malloc(sizeof(*fdp));
if (fdp == NULL) {
exit(4);
}
*fdp = filedesc;
pthread_t thread;
if (pthread_create(&thread, NULL, threadMain, /* move */ fdp) != 0) {
exit(5);
}
tor_run_main(config);
if (pthread_join(thread, NULL) != 0) {
exit(6);
}
fprintf(stderr, "********** doing another round\n");
}
}
When I ran this on a Ubuntu 22.04.2 LTS distro, I got this output: Please, see also the complete LOG.txt file. However, I must say the error we see here is different from the one I would expect to see. Sure, we see the usual messages indicating something is wrong with the pubsub subsystem, but here we're getting an "IOT instruction", which is different from what we used to see from Go. According to the GNU libc manual, "on most platforms SIGIOT is equivalent to SIGABRT". Also, include/linux/signal.h mentions |
|
I have just seen another crash: This was after six repetitions again (WTF?!). Also, it seems weird that it previously run for ~1h without crashes after I patched the code to install a signal handler for Here is the full LOG.txt. |
|
The next step is probably to patch It's also worth recompiling just |
What happens if I just prevent tor from aborting?TL;DR nothing (save for possible memory corruption that I cannot demonstrate at this time). Please see the LOG-without-aborting.txt, which includes: The full patch I am using is: diff --git a/src/app/main/main.c b/src/app/main/main.c
index 838e129d04..6a7c99f9f7 100644
--- a/src/app/main/main.c
+++ b/src/app/main/main.c
@@ -92,6 +92,8 @@
#include <unistd.h>
#endif
+#include <stdio.h>
+
#ifdef HAVE_SYSTEMD
# if defined(__COVERITY__) && !defined(__INCLUDE_LEVEL__)
/* Systemd's use of gcc's __INCLUDE_LEVEL__ extension macro appears to confuse
@@ -1279,14 +1281,16 @@ run_tor_main_loop(void)
}
/** Install the publish/subscribe relationships for all the subsystems. */
-void
+int
pubsub_install(void)
{
pubsub_builder_t *builder = pubsub_builder_new();
int r = subsystems_add_pubsub(builder);
- tor_assert(r == 0);
+ if (r != 0) {
+ return r;
+ }
r = tor_mainloop_connect_pubsub(builder); // consumes builder
- tor_assert(r == 0);
+ return r;
}
/** Connect the mainloop to its publish/subscribe message delivery events if
@@ -1331,7 +1335,10 @@ tor_run_main(const tor_main_configuration_t *tor_cfg)
if (POSSIBLE(done))
goto done;
- pubsub_install();
+ if (pubsub_install() != 0) {
+ fprintf(stderr, "SBSDEBUG: pubsub_install failed; all bets are off\n");
+ goto done;
+ }
{
int init_rv = tor_init(argc, argv);
diff --git a/src/app/main/main.h b/src/app/main/main.h
index a8fa0959ab..08ba27253d 100644
--- a/src/app/main/main.h
+++ b/src/app/main/main.h
@@ -25,7 +25,7 @@ int tor_init(int argc, char **argv);
int run_tor_main_loop(void);
-void pubsub_install(void);
+int pubsub_install(void);
void pubsub_connect(void);
#endif /* !defined(TOR_MAIN_H) */
diff --git a/src/lib/pubsub/pubsub_check.c b/src/lib/pubsub/pubsub_check.c
index 99e604d715..a5cc4b7658 100644
--- a/src/lib/pubsub/pubsub_check.c
+++ b/src/lib/pubsub/pubsub_check.c
@@ -25,6 +25,7 @@
#include "lib/malloc/malloc.h"
#include "lib/string/compat_string.h"
+#include <stdio.h>
#include <string.h>
static void pubsub_adjmap_add(pubsub_adjmap_t *map,
@@ -343,21 +344,27 @@ lint_message(const pubsub_adjmap_t *map, message_id_t msg)
log_warn(LD_MESG|LD_BUG,
"Message \"%s\" has subscribers, but no publishers.",
get_message_id_name(msg));
+ fprintf(stderr, "SBSDEBUG: n_pub == 0 for %s\n", get_message_id_name(msg));
ok = false;
} else if (n_sub == 0) {
log_warn(LD_MESG|LD_BUG,
"Message \"%s\" has publishers, but no subscribers.",
get_message_id_name(msg));
+ fprintf(stderr, "SBSDEBUG: n_sub == 0 for %s\n", get_message_id_name(msg));
ok = false;
}
/* Check the message graph topology. */
- if (lint_message_graph(map, msg, pub, sub) < 0)
+ if (lint_message_graph(map, msg, pub, sub) < 0) {
+ fprintf(stderr, "SBSDEBUG: lint_message_graph failed for %s\n", get_message_id_name(msg));
ok = false;
+ }
/* Check whether the messages have the same fields set on them. */
- if (lint_message_consistency(msg, pub, sub) < 0)
+ if (lint_message_consistency(msg, pub, sub) < 0) {
+ fprintf(stderr, "SBSDEBUG: lint_message_consistency failed for %s\n", get_message_id_name(msg));
ok = false;
+ }
if (!ok) {
/* There was a problem -- let's log all the publishers and subscribers on
@@ -385,6 +392,7 @@ pubsub_adjmap_check(const pubsub_adjmap_t *map)
bool all_ok = true;
for (unsigned i = 0; i < map->n_msgs; ++i) {
if (lint_message(map, i) < 0) {
+ fprintf(stderr, "SBSDEBUG: lint_message failed for %u %s\n", i, get_message_id_name((message_id_t)i));
all_ok = false;
}
}
@@ -401,11 +409,15 @@ pubsub_builder_check(pubsub_builder_t *builder)
pubsub_adjmap_t *map = pubsub_build_adjacency_map(builder->items);
int rv = -1;
- if (!map)
+ if (!map) {
+ fprintf(stderr, "SBSDEBUG: pubsub_build_adjacency_map failed\n");
goto err; // should be impossible
+ }
- if (pubsub_adjmap_check(map) < 0)
+ if (pubsub_adjmap_check(map) < 0) {
+ fprintf(stderr, "SBSDEBUG: pubsub_adjmap_check failed\n");
goto err;
+ }
rv = 0;
err:
|
|
Regarding running the experiment using
Also: Here's the full log of this run: LOG-tsan-2.txt |
|
Okay, enough with the investigation. I am not sure how to proceed and I think understanding the problem probably requires a better understanding of C code debugging techniques and of the tor codebase. I just opened an issue on the tor bug tracker: https://gitlab.torproject.org/tpo/core/tor/-/issues/40774. |
bassosimone
added a commit
to ooni/probe-cli
that referenced
this issue
Apr 5, 2023
There's a data race in the `libtor` package, as documented by ooni/probe#2406 (comment). This diff applies the commits mentioned by ooni/probe#2406 (comment).
bassosimone
added a commit
to ooni/probe-cli
that referenced
this issue
Jun 12, 2023
This diff modifies tunnel, torsf, and vanilla such that: 1. we return a special error when tor is not found on PATH 2. we use such an error to avoid submitting By doing that, we save some useless submissions. Part of ooni/probe#2406 because I wrote this diff while investigating it. --------- Co-authored-by: DecFox <mehul707gulati@gmail.com>
bassosimone
added a commit
to ooni/probe-cli
that referenced
this issue
Jun 12, 2023
This diff backports e9cc324. This diff modifies tunnel, torsf, and vanilla such that: 1. we return a special error when tor is not found on PATH 2. we use such an error to avoid submitting By doing that, we save some useless submissions. Part of ooni/probe#2406 because I wrote this diff while investigating it. --------- Co-authored-by: DecFox <mehul707gulati@gmail.com>
bassosimone
added a commit
to ooni/probe-android
that referenced
this issue
Jul 12, 2023
Unfortunately, because of ooni/probe#2406, we are going to see crashes when using these proxies. This diff is part of ooni/probe#2500. Since we're increasingly being blocked, it makes sense to exposes all the possible proxies we can feature. We're going to touch upon the same files again once we land the ooni/probe-cli#1162 pull request.
cyBerta
pushed a commit
to cyBerta/probe-cli
that referenced
this issue
Aug 4, 2023
There's a data race in the `libtor` package, as documented by ooni/probe#2406 (comment). This diff applies the commits mentioned by ooni/probe#2406 (comment).
cyBerta
pushed a commit
to cyBerta/probe-cli
that referenced
this issue
Aug 4, 2023
This diff modifies tunnel, torsf, and vanilla such that: 1. we return a special error when tor is not found on PATH 2. we use such an error to avoid submitting By doing that, we save some useless submissions. Part of ooni/probe#2406 because I wrote this diff while investigating it. --------- Co-authored-by: DecFox <mehul707gulati@gmail.com>
|
Sentry issue: PROBE-ANDROID-12E |
bassosimone
added a commit
to ooni/probe-cli
that referenced
this issue
Oct 19, 2023
The reference issue is ooni/probe#2553. When I implemented the disabled-by-default functionality, I missed that we should also disable-by-default vanilla_tor. The reason for doing that is that the experiment crashes on Android and possibly iOS due to ooni/probe#2406.
bassosimone
added a commit
to ooni/probe-cli
that referenced
this issue
Oct 19, 2023
The reference issue is ooni/probe#2553. When I implemented the disabled-by-default functionality, I missed that we should also disable-by-default vanilla_tor. The reason for doing that is that the experiment crashes on Android and possibly iOS due to ooni/probe#2406.
bassosimone
added a commit
to ooni/probe-cli
that referenced
this issue
Oct 19, 2023
This diff backports #1374 to release/3.19. The reference issue is ooni/probe#2553. When I implemented the disabled-by-default functionality, I missed that we should also disable-by-default vanilla_tor. The reason for doing that is that the experiment crashes on Android and possibly iOS due to ooni/probe#2406.
|
We're continuing to discuss with Tor developers at https://gitlab.torproject.org/tpo/core/tor/-/issues/40774#note_2959394. |
Murphy-OrangeMud
pushed a commit
to Murphy-OrangeMud/probe-cli
that referenced
this issue
Feb 13, 2024
The reference issue is ooni/probe#2553. When I implemented the disabled-by-default functionality, I missed that we should also disable-by-default vanilla_tor. The reason for doing that is that the experiment crashes on Android and possibly iOS due to ooni/probe#2406.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Seems to be a not-so-frequent event. It occurred just once while testing #2405.
On 2023-02-07, the issues appeared again. The logcat contains these logs right before the crash:
Therefore, it seems this issue is related to the
torsfexperiment.The text was updated successfully, but these errors were encountered: