Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2009-06-12T06:55:36Zhttps://gitlab.torproject.org/legacy/trac/-/issues/967Firefox crashed because of Torbutton2009-06-12T06:55:36ZTracFirefox crashed because of TorbuttonHi,
I'm using Firefox 3.08 at Ubuntu Jaunty. Just loaded a new page and while this page was loading I activated Torbutton.
Then Firefox crashed. After restarting Firefox I got following message:
Torbutton crash state conflict! Please f...Hi,
I'm using Firefox 3.08 at Ubuntu Jaunty. Just loaded a new page and while this page was loading I activated Torbutton.
Then Firefox crashed. After restarting Firefox I got following message:
Torbutton crash state conflict! Please file bug report with these four values: true,true,true,false
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: hias90https://gitlab.torproject.org/legacy/trac/-/issues/948Crash on rendcommon.c:332020-06-13T14:01:28ZTracCrash on rendcommon.c:33Revision 19068. Crash. No log (latest "[notice] Performing bandwidth self-test...done.")
Core was generated by `/usr/bin/tor --runasdaemon 1'.
Program terminated with signal 11, Segmentation fault.
[New process 8760]
[New process 8775]
...Revision 19068. Crash. No log (latest "[notice] Performing bandwidth self-test...done.")
Core was generated by `/usr/bin/tor --runasdaemon 1'.
Program terminated with signal 11, Segmentation fault.
[New process 8760]
[New process 8775]
#0 0x080b89e3 in rend_service_descriptor_free (desc=0x86c9040) at rendcommon.c:33
33 SMARTLIST_FOREACH(desc->successful_uploads, char *, c, tor_free(c););
(gdb) bt
#0 0x080b89e3 in rend_service_descriptor_free (desc=0x86c9040) at rendcommon.c:33
#1 0x080bef73 in rend_consider_services_upload (now=1237319764) at rendservice.c:545
#2 0x080a9774 in second_elapsed_callback (fd=-1, event=1, args=0x0) at main.c:1086
#3 0xb7f1c3ce in event_base_loop (base=0x81430b0, flags=0) at event.c:387
#4 0xb7f1c5b4 in event_loop (flags=0) at event.c:463
#5 0x080a9db5 in do_main_loop () at main.c:1435
#6 0x080aa04f in tor_main (argc=3, argv=0xbfd7b284) at main.c:2060
#7 0x080e67e6 in main (argc=Cannot access memory at address 0x11
) at tor_main.c:30
(gdb)
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: xiando0.2.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/946Old Polipo config causes TorButton to hang (or anything using http proxy)2009-03-27T04:48:36ZcodermanOld Polipo config causes TorButton to hang (or anything using http proxy)If an old polipo.txt config file exists in the local user data folder Polipo will
be configured with a parent proxy of localhost instead of the VM 10.10.10.1 address.
Manual workaround is to edit %LOCALAPPDATA%\Polipo\polipo.txt and com...If an old polipo.txt config file exists in the local user data folder Polipo will
be configured with a parent proxy of localhost instead of the VM 10.10.10.1 address.
Manual workaround is to edit %LOCALAPPDATA%\Polipo\polipo.txt and comment/delete
the socksParentProxy and socksProxyType settings; Tor VM will transparently proxy
Polipo's TCP connections out.
EDIT: fixed; to be included in 0.0.2
[Automatically added by flyspray2trac: Operating System: All]codermancodermanhttps://gitlab.torproject.org/legacy/trac/-/issues/945Vidalia config from previous install causes new Vidalia to hang2011-01-24T09:24:41ZcodermanVidalia config from previous install causes new Vidalia to hangIf a previous Vidalia install has created a vidalia.conf in the local application data folder it
will contain a control port setting that will not connect to the VM instance of Tor. Tor VM should
detect if the existing vidalia.conf needs...If a previous Vidalia install has created a vidalia.conf in the local application data folder it
will contain a control port setting that will not connect to the VM instance of Tor. Tor VM should
detect if the existing vidalia.conf needs to be replaced with a Tor VM default.
The manual work around is to move the %LOCALAPPDATA%\Vidalia\vidalia.conf elsewhere and restart.
EDIT: fixed; to be included in 0.0.2
[Automatically added by flyspray2trac: Operating System: All]codermancodermanhttps://gitlab.torproject.org/legacy/trac/-/issues/944Corrupted virtual disk image causes VM to hang2009-03-16T20:07:31ZcodermanCorrupted virtual disk image causes VM to hangIf the virtual disk used for persistent Tor state and other system data becomes corrupted
the VM is unable to detect failure to mount the volume. This will result in a VM that never
starts Tor and simply repeats the error "No such file o...If the virtual disk used for persistent Tor state and other system data becomes corrupted
the VM is unable to detect failure to mount the volume. This will result in a VM that never
starts Tor and simply repeats the error "No such file or directory" for /var/log/tor/notices.log
Manual work around is to remove the state\hdd.img file. For installs this is located at
%PROGRAMFILES%\Tor VM\state\hdd.img
[Automatically added by flyspray2trac: Operating System: All]codermancodermanhttps://gitlab.torproject.org/legacy/trac/-/issues/941circuit event lines sometimes miss verbose names2020-06-13T14:01:26ZRoger Dingledinecircuit event lines sometimes miss verbose namesIn my Vidalia logs
Mar 12 20:18:31.186 [notice] QtWarningMsg: torcontrol: Improperly formatted
circuit: '16 EXTENDED $5A583B838FDC22246E046E1D4E108F41EFBAD175'
edmanm:#vidalia> those circ events are spec compliant, but they're annoying
...In my Vidalia logs
Mar 12 20:18:31.186 [notice] QtWarningMsg: torcontrol: Improperly formatted
circuit: '16 EXTENDED $5A583B838FDC22246E046E1D4E108F41EFBAD175'
edmanm:#vidalia> those circ events are spec compliant, but they're annoying
since they don't include the nickname, even when you ask for verbose_names.
edmanm:#vidalia> i don't know why tor includes that with some circ events and
not others.
edmanm> when i say "usefeature verbose_names", tor gives me hops in circ
events as either "$id=nickname" for named relays or "$id~nickname" for
non-named relays.
edmanm> except in some cases, like the one you pasted above, all i get is
$id.
edmanm> that's the same format you get when you don't specify 'usefeature
verbose_names'. (i.e. just $id for non-named relays or just the nickname for
named relays)
[Automatically added by flyspray2trac: Operating System: All]0.2.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/939Our socket count is below zero2020-06-13T14:01:26ZRoger DingledineOur socket count is below zeroRunning moria1 on 0.2.1.12-alpha-dev (r18691), it ran for a few weeks. Then
I !^c'ed it to move to 0.2.1.13-alpha, and its last words were
Mar 09 17:22:50.253 [warn] tor_close_socket(): Bug: Our socket count is below zero: -1. Please su...Running moria1 on 0.2.1.12-alpha-dev (r18691), it ran for a few weeks. Then
I !^c'ed it to move to 0.2.1.13-alpha, and its last words were
Mar 09 17:22:50.253 [warn] tor_close_socket(): Bug: Our socket count is below zero: -1. Please submit a bug report.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/937Tor does not support OpenSSL dynamic hardware engines2020-06-13T14:01:26ZcodermanTor does not support OpenSSL dynamic hardware enginesNOTE: fix due in 0.2.2.x.
branch hardware_accel_improvements at git://git.torproject.org/~coderman/git/tor.git
The existing support for crypto acceleration in Tor via the HardwareAccel 1 option is not able to load dynamic engines.
For ...NOTE: fix due in 0.2.2.x.
branch hardware_accel_improvements at git://git.torproject.org/~coderman/git/tor.git
The existing support for crypto acceleration in Tor via the HardwareAccel 1 option is not able to load dynamic engines.
For example, padlock acceleration with Via processors. See also http://archives.seul.org/or/talk/Dec-2008/msg00314.html
To fix this the src/common/crypto.c should be extended to attempt dynamic engine loading.
NOTE: I have fixed the engine name to "padlock"; robust support for this feature will require a config option
like "HardwareEngineName" or such.
In crypto_global_init():
if (useAccel > 0) {
ENGINE *e = NULL;
log_info(LD_CRYPTO, "Initializing OpenSSL engine support.");
ENGINE_load_builtin_engines();
ENGINE_register_all_complete();
e = ENGINE_by_id ("padlock");
if (!e) {
log_info(LD_CRYPTO, "Trying to load dynamic Padlock OpenSSL engine.");
e = try_load_engine ("padlock");
if (!e) {
log_info(LD_CRYPTO, "Unable to load Padlock OpenSSL engine.");
}
}
if (e) {
log_info(LD_CRYPTO, "Loaded Padlock OpenSSL engine, setting default ciphers.");
ENGINE_set_default (e, ENGINE_METHOD_ALL);
}
}
Where the try_load_engine for dynamic libs is:
/* Try to load a dynamic engine library. */
static ENGINE *
try_load_engine(const char *engine)
{
ENGINE *e = ENGINE_by_id ("dynamic");
if (e)
{
if (!ENGINE_ctrl_cmd_string (e, "SO_PATH", engine, 0)
|| !ENGINE_ctrl_cmd_string (e, "LOAD", NULL, 0))
{
ENGINE_free (e);
e = NULL;
}
}
return e;
}
Depending on VIA processor/stepping this results in:
Mar 08 06:32:00.473 [info] crypto_global_init(): Initializing OpenSSL engine support.
Mar 08 06:32:00.473 [info] crypto_global_init(): Loaded Padlock OpenSSL engine, setting default ciphers.
Mar 08 06:32:00.473 [info] Using default implementation for RSA
Mar 08 06:32:00.473 [info] Using default implementation for DH
Mar 08 06:32:00.473 [info] Using default implementation for RAND
Mar 08 06:32:00.473 [notice] Using OpenSSL engine VIA PadLock: RNG (not used) ACE2 PHE(8192) PMM [padlock] for SHA1
Mar 08 06:32:00.473 [info] Using default implementation for 3DES
Mar 08 06:32:00.473 [notice] Using OpenSSL engine VIA PadLock: RNG (not used) ACE2 PHE(8192) PMM [padlock] for AES
...
[Automatically added by flyspray2trac: Operating System: All]post 0.2.1.xcodermancodermanhttps://gitlab.torproject.org/legacy/trac/-/issues/932Bridges report unbelievable numbers of clients2020-06-13T14:01:23ZKarsten LoesingBridges report unbelievable numbers of clientsDuring the evaluation of extra-info documents published by bridges it was
found that some bridges report unbelievable numbers of clients. As an
example, two subsequently published extra-info documents of the same bridge
look are as follo...During the evaluation of extra-info documents published by bridges it was
found that some bridges report unbelievable numbers of clients. As an
example, two subsequently published extra-info documents of the same bridge
look are as follows (* denotes removed parts). Here, the first extra-info
document is the first such document that was published by this bridge.
extra-info *
published 2008-10-28 17:20:32
geoip-start-time 2008-10-25 23:07:16
geoip-client-origins de=936,us=704,cn=664,it=288,fr=208,ru=192,gb=144,*
extra-info *
published 2008-10-29 09:20:33
geoip-start-time 2008-10-27 09:07:01
geoip-client-origins ae=8,bg=8,cn=8,cz=8,de=8,dk=8,es=8,hk=8,in=8,it=8,*
The same bridge was running as a relay before 2008-10-28 with the last
router descriptor published at around 2008-10-27 14:00:00.
A possible (and even likely) explanation for the high numbers of clients is
that these clients contacted the bridge back when it was running as a
relay. When being reconfigured to run as a bridge, the bridge did not clear
its geoip cache and counted the relay clients as bridge clients. Only when
clearing the cache on 2008-10-27 09:07:01, the relay clients were removed
from the cache.
A solution to the described problem is that bridges do not include geoip
information in their extra-info documents if they have published a router
descriptor within the past few days, e.g., 3 days. These 3 (or whatever
fits here) days ensure that clients do not know about the bridge as a relay
anymore, but only as a bridge. This prevents both overcounting and
unwantedly revealing information about relay usage.
There is another phenomenon of a bridge that publishes both router
descriptors and bridge descriptors at the same time. In fact, it's not
forbidden to set 'PublishServerDescriptor v2,v3,bridge'. However, this
defeats the point of counting only bridge clients and including them in
extra-info documents. Should this behavior be changed, so that nodes can
publish either router descriptors or bridge descriptors, but not both?
[Automatically added by flyspray2trac: Operating System: All]0.2.1.x-finalKarsten LoesingKarsten Loesinghttps://gitlab.torproject.org/legacy/trac/-/issues/930router_parse_entry_from_string (s=0x135 <Address 0x135 out of bounds>2020-06-13T14:01:22ZAndrew Lewmanrouter_parse_entry_from_string (s=0x135 <Address 0x135 out of bounds>gdb bt below. tor 0.2.0.34-stable does not have this issue.
Feb 22 18:48:53.906 [notice] Bootstrapped 90%: Establishing a Tor circuit.
Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fab760756e0 (LWP 18369)]
0x00007f...gdb bt below. tor 0.2.0.34-stable does not have this issue.
Feb 22 18:48:53.906 [notice] Bootstrapped 90%: Establishing a Tor circuit.
Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fab760756e0 (LWP 18369)]
0x00007fab74d11015 in raise () from /lib/libc.so.6
(gdb) bt
#0 0x00007fab74d11015 in raise () from /lib/libc.so.6
#1 0x00007fab74d12b83 in abort () from /lib/libc.so.6
#2 0x00007fab74d57a80 in ?? () from /lib/libc.so.6
#3 0x00000000004ad39d in memarea_drop_all (area=0x21a47f0) at memarea.c:102
#4 0x0000000000493c64 in router_parse_entry_from_string (s=0x135 <Address 0x135 out of bounds>, end=0x9a8 <Address 0x9a8 out of bounds>, cache_copy=1,
allow_annotations=295, prepend_annotations=0x135 <Address 0x135 out of bounds>) at routerparse.c:1438
#5 0x0000000000494eb4 in router_parse_list_from_string (s=0x7fff7e093e38, eos=0x7fab75ec6357 "", dest=0x21ecb10, saved_location=SAVED_NOWHERE,
want_extrainfo=0, allow_annotations=0, prepend_annotations=0x7fff7e093f70 "@downloaded-at 2009-02-22 23:48:56\n@source \"194.105.99.31\"\n")
at routerparse.c:1061
#6 0x000000000048cf05 in router_load_routers_from_string (
s=0x7fab75ebc614 "router che 81.233.224.95 443 0 80\nplatform Tor 0.2.0.33 (r18212) on Linux i686\nopt protocols Link 1 2 Circuit 1\npublished 2009-02-22 21:26:03\nopt fingerprint D5F2 C65F 4131 A146 8D5B 67A8 838A 9B7E D8"..., eos=0x0, saved_location=SAVED_NOWHERE, requested_fingerprints=0x2264440,
descriptor_digests=1, prepend_annotations=0x7fff7e093f70 "@downloaded-at 2009-02-22 23:48:56\n@source \"194.105.99.31\"\n") at routerlist.c:3500
#7 0x0000000000447b16 in connection_dir_client_reached_eof (conn=0x21a9440) at directory.c:1376
#8 0x00000000004486de in connection_dir_reached_eof (conn=0x21a9440) at directory.c:2041
#9 0x000000000042bde8 in connection_handle_read (conn=0x21a9440) at connection.c:2909
#10 0x0000000000461bc0 in conn_read_callback (fd=<value optimized out>, event=<value optimized out>, _conn=<value optimized out>) at main.c:456
#11 0x00007fab75a4e67d in event_base_loop () from /usr/lib/libevent-1.3e.so.1
#12 0x00000000004617a6 in do_main_loop () at main.c:1435
#13 0x00000000004619f5 in tor_main (argc=1, argv=<value optimized out>) at main.c:2060
#14 0x00007fab74cfc466 in __libc_start_main () from /lib/libc.so.6
#15 0x0000000000407469 in _start ()
[Automatically added by flyspray2trac: Operating System: Other Linux]0.2.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/929FAILURE to event_del (ev=0x9376e48) at event.c:8062020-06-13T14:01:19ZTracFAILURE to event_del (ev=0x9376e48) at event.c:806Feb 21 08:50:09.922 [notice] Tor v0.2.1.12-alpha-dev (r18582).
Crash on failure with event_del (event.c 806) involvement.
# gdb /usr/bin/tor /var/lib/tor/data/core.25599
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
L...Feb 21 08:50:09.922 [notice] Tor v0.2.1.12-alpha-dev (r18582).
Crash on failure with event_del (event.c 806) involvement.
# gdb /usr/bin/tor /var/lib/tor/data/core.25599
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib/libz.so.1...done.
Loaded symbols for /lib/libz.so.1
Reading symbols from /usr/lib/libevent-1.4.so.2...done.
Loaded symbols for /usr/lib/libevent-1.4.so.2
Reading symbols from /usr/lib/libssl.so.0.9.8...done.
Loaded symbols for /usr/lib/libssl.so.0.9.8
Reading symbols from /usr/lib/libcrypto.so.0.9.8...done.
Loaded symbols for /usr/lib/libcrypto.so.0.9.8
Reading symbols from /lib/libpthread.so.0...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/librt.so.1...done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libresolv.so.2...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnss_compat.so.2...done.
Loaded symbols for /lib/libnss_compat.so.2
Reading symbols from /lib/libnss_nis.so.2...done.
Loaded symbols for /lib/libnss_nis.so.2
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
Core was generated by `/usr/bin/tor --runasdaemon 1'.
Program terminated with signal 11, Segmentation fault.
[New process 25599]
[New process 25612]
#0 event_del (ev=0x9376e48) at event.c:806
806 event.c: No such file or directory.
in event.c
(gdb) bt
#0 event_del (ev=0x9376e48) at event.c:806
#1 0x080e2741 in request_finished (req=0x9376e10, head=<value optimized out>) at eventdns.c:616
#2 0xb7ea53ce in event_base_loop (base=0x81430a0, flags=0) at event.c:387
#3 0xb7ea55b4 in event_loop (flags=0) at event.c:463
#4 0x080a9d75 in do_main_loop () at main.c:1435
#5 0x080aa00f in tor_main (argc=3, argv=0xbfe03114) at main.c:2060
#6 0x080e650e in main (argc=Cannot access memory at address 0x1b
) at tor_main.c:30
(gdb)
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: xiando0.2.1.x-final