Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T14:10:36Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/468Tor Server excessive ram usage2020-06-27T14:10:36ZAndrew LewmanTor Server excessive ram usageA number of people on or-talk are reporting very high memory usage (512MB to 1GB) for their servers. This entry is
to track the issues and provide feedback to those experiencing the problem.
See http://archives.seul.org/or/talk/Jul-20...A number of people on or-talk are reporting very high memory usage (512MB to 1GB) for their servers. This entry is
to track the issues and provide feedback to those experiencing the problem.
See http://archives.seul.org/or/talk/Jul-2007/msg00135.html for the start of the thread.
If you are experiencing this problem, please list your operating system (uname -rmpio), tor version, zlib version,
openssl version, exit server or not, and virtual/resident memory usage of Tor.
Thanks!
[Automatically added by flyspray2trac: Operating System: Other Linux]post 0.2.0.xNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/467r10895 suicide strlcpy.c:56, circuitbuild.c:17572020-06-27T14:10:36ZTracr10895 suicide strlcpy.c:56, circuitbuild.c:1757
Checked out revision 10895.
gdb /usr/bin/tor /var/lib/tor/core.17532
GNU gdb Red Hat Linux (6.3.0.0-1.143.el4rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are...
Checked out revision 10895.
gdb /usr/bin/tor /var/lib/tor/core.17532
GNU gdb Red Hat Linux (6.3.0.0-1.143.el4rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1".
Core was generated by `/usr/bin/tor -f /etc/tor/torrc --pidfile /var/run/tor/tor.pid --log notice file'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /usr/lib/libevent-1.3b.so.1...Reading symbols from /usr/lib/debug/usr/lib/libevent-1.3b.so.1.0.3.debug...done.
done.
Loaded symbols for /usr/lib/libevent-1.3b.so.1
Reading symbols from /lib/libssl.so.4...done.
Loaded symbols for /lib/libssl.so.4
Reading symbols from /lib/libcrypto.so.4...done.
Loaded symbols for /lib/libcrypto.so.4
Reading symbols from /lib/tls/libpthread.so.0...done.
Loaded symbols for /lib/tls/libpthread.so.0
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/tls/libc.so.6...btdone.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /usr/lib/libgssapi_krb5.so.2...done.
Loaded symbols for /usr/lib/libgssapi_krb5.so.2
Reading symbols from /usr/lib/libkrb5.so.3...done.
Loaded symbols for /usr/lib/libkrb5.so.3
Reading symbols from /lib/libcom_err.so.2...done.
Loaded symbols for /lib/libcom_err.so.2
Reading symbols from /usr/lib/libk5crypto.so.3...done.
Loaded symbols for /usr/lib/libk5crypto.so.3
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_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /lib/libnss_dns.so.2...done.
Loaded symbols for /lib/libnss_dns.so.2
#0 strlcpy (dst=0xa80aff0 "", src=0x0, siz=42) at strlcpy.c:56
56 s++;
(gdb) bt
#0 strlcpy (dst=0xa80aff0 "", src=0x0, siz=42) at strlcpy.c:56
#1 0x080529e0 in extend_info_alloc (nickname=0x0, digest=0x9f559b0 "��\224~\215e\004�\001", onion_key=0x9c01520, addr=176205808, port=0)
at circuitbuild.c:1743
legacy/trac#2 0x08052a3b in extend_info_from_router (r=0x9f55980) at circuitbuild.c:1757
legacy/trac#3 0x080543e1 in circuit_establish_circuit (purpose=Variable "purpose" is not available.
) at circuitbuild.c:1398
legacy/trac#4 0x08059bc1 in circuit_get_open_circ_or_launch (conn=0xa76bf68, desired_circuit_purpose=5 '\005', circp=0xbfe572d8) at circuituse.c:1074
legacy/trac#5 0x0805a663 in connection_ap_handshake_attach_circuit (conn=0xa76bf68) at circuituse.c:1284
legacy/trac#6 0x0806bb19 in connection_ap_attach_pending () at connection_edge.c:443
legacy/trac#7 0x08059554 in circuit_build_needed_circs (now=1185051593) at circuituse.c:454
legacy/trac#8 0x0808b34f in second_elapsed_callback (fd=-1, event=1, args=0x0) at main.c:1035
legacy/trac#9 0x0032e62d in event_base_loop (base=0x9c01520, flags=Variable "flags" is not available.
) at event.c:315
legacy/trac#10 0x0032e6e0 in event_loop (flags=176205808) at event.c:366
legacy/trac#11 0x0808c7d1 in tor_main (argc=15, argv=0xbfe57994) at main.c:1369
legacy/trac#12 0x080b0ac3 in main (argc=15, argv=0xbfe57994) at tor_main.c:28
(gdb)
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: xiandohttps://gitlab.torproject.org/tpo/core/tor/-/issues/463[notice] dns_cancel_pending_resolve(): Bug: Address [scrubbed] is not pending...2020-06-27T14:10:36ZTrac[notice] dns_cancel_pending_resolve(): Bug: Address [scrubbed] is not pending. Dropping.Been getting a bunch of those messages in my server log.
They seem to occur an hour or two after startup, and then in small bunches.
I set logging to debug level. Here follow three of the errors in context;
i can send the full 80MB log...Been getting a bunch of those messages in my server log.
They seem to occur an hour or two after startup, and then in small bunches.
I set logging to debug level. Here follow three of the errors in context;
i can send the full 80MB log file if anyone needs it:
Jul 16 06:26:43.325 [debug] connection_exit_begin_conn(): Creating new exit connection.
Jul 16 06:26:43.325 [debug] buf_get_initial_mem(): Got buf mem from 4096-byte freelist. Freelist has 84 entries.
Jul 16 06:26:43.325 [debug] buf_get_initial_mem(): Got buf mem from 4096-byte freelist. Freelist has 83 entries.
Jul 16 06:26:43.325 [debug] connection_exit_begin_conn(): about to start the dns_resolve().
Jul 16 06:26:43.325 [info] Rejecting invalid destination address [scrubbed]
Jul 16 06:26:43.325 [notice] dns_cancel_pending_resolve(): Bug: Address [scrubbed] is not pending. Dropping.
Jul 16 06:26:43.325 [debug] add_buf_mem_to_freelist(): Add buf mem to 4096-byte freelist. Freelist has 84 entries.
Jul 16 06:26:43.325 [debug] add_buf_mem_to_freelist(): Add buf mem to 4096-byte freelist. Freelist has 85 entries.
Jul 16 06:26:43.325 [debug] relay_send_command_from_edge(): delivering 3 cell backward.
Jul 16 06:26:43.326 [debug] append_cell_to_circuit_queue(): Made a circuit active.
Jul 16 06:26:43.326 [debug] append_cell_to_circuit_queue(): Primed a buffer.
Jul 16 06:26:43.326 [debug] write_to_buf(): added 512 bytes to buf (now 512 total).
Jul 16 06:26:43.326 [debug] connection_or_flush_from_first_active_circuit(): Made a circuit inactive.
Jul 16 06:26:43.326 [debug] connection_or_process_cells_from_inbuf(): 138: starting, inbuf_datalen 15360 (0 pending in tls object).
Jul 16 06:26:43.326 [debug] circuit_receive_relay_cell(): Sending away from origin.
Jul 16 06:26:43.326 [debug] connection_edge_process_relay_cell(): Now seen 199320 relay cells here.
Jul 16 06:26:43.326 [debug] connection_exit_begin_conn(): Creating new exit connection.
Jul 16 06:26:43.326 [debug] buf_get_initial_mem(): Got buf mem from 4096-byte freelist. Freelist has 84 entries.
Jul 16 06:26:43.326 [debug] buf_get_initial_mem(): Got buf mem from 4096-byte freelist. Freelist has 83 entries.
Jul 16 06:26:43.326 [debug] connection_exit_begin_conn(): about to start the dns_resolve().
Jul 16 06:26:43.326 [info] Rejecting invalid destination address [scrubbed]
Jul 16 06:26:43.326 [notice] dns_cancel_pending_resolve(): Bug: Address [scrubbed] is not pending. Dropping.
Jul 16 06:26:43.326 [debug] add_buf_mem_to_freelist(): Add buf mem to 4096-byte freelist. Freelist has 84 entries.
Jul 16 06:26:43.326 [debug] add_buf_mem_to_freelist(): Add buf mem to 4096-byte freelist. Freelist has 85 entries.
Jul 16 06:26:43.326 [debug] relay_send_command_from_edge(): delivering 3 cell backward.
Jul 16 06:26:43.326 [debug] append_cell_to_circuit_queue(): Made a circuit active.
Jul 16 06:26:43.326 [debug] connection_or_process_cells_from_inbuf(): 138: starting, inbuf_datalen 14848 (0 pending in tls object).
Jul 16 06:26:43.327 [debug] circuit_receive_relay_cell(): Sending away from origin.
Jul 16 06:26:43.327 [debug] connection_edge_process_relay_cell(): Now seen 199321 relay cells here.
Jul 16 06:26:43.327 [debug] connection_exit_begin_conn(): Creating new exit connection.
Jul 16 06:26:43.327 [debug] buf_get_initial_mem(): Got buf mem from 4096-byte freelist. Freelist has 84 entries.
Jul 16 06:26:43.327 [debug] buf_get_initial_mem(): Got buf mem from 4096-byte freelist. Freelist has 83 entries.
Jul 16 06:26:43.327 [debug] connection_exit_begin_conn(): about to start the dns_resolve().
Jul 16 06:26:43.327 [info] Rejecting invalid destination address [scrubbed]
Jul 16 06:26:43.327 [notice] dns_cancel_pending_resolve(): Bug: Address [scrubbed] is not pending. Dropping.
OS/Distro:
Xubuntu 7.04 fresh install
Tor 0.2.0.2-alpha from Debian Etch distro install
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: kebhttps://gitlab.torproject.org/tpo/core/tor/-/issues/458router_add_to_routerlist returns >=0 but ri gets freed2020-06-27T14:10:36ZRoger Dingledinerouter_add_to_routerlist returns >=0 but ri gets freedRunning r10828 inside valgrind:
==21699== Invalid read of size 1
==21699== at 0x80C6C2D: routerlist_descriptors_added (routerlist.c:2752)
==21699== by 0x80C7169: router_load_routers_from_string (routerlist.c:2870)
==21699== by ...Running r10828 inside valgrind:
==21699== Invalid read of size 1
==21699== at 0x80C6C2D: routerlist_descriptors_added (routerlist.c:2752)
==21699== by 0x80C7169: router_load_routers_from_string (routerlist.c:2870)
==21699== by 0x80C077D: router_reload_router_list_impl (routerlist.c:566)
==21699== by 0x80C0818: router_reload_router_list (routerlist.c:594)
==21699== by 0x80A7A2E: do_main_loop (main.c:1330)
==21699== by 0x80A8F26: tor_main (main.c:2606)
==21699== by 0x80DD9D9: main (tor_main.c:28)
==21699== Address 0x51EC212 is 154 bytes inside a block of size 172 free'd
==21699== at 0x401CFA5: free (vg_replace_malloc.c:233)
==21699== by 0x80C3992: routerinfo_free (routerlist.c:1761)
==21699== by 0x80C51FF: routerlist_replace (routerlist.c:2195)
==21699== by 0x80C6053: router_add_to_routerlist (routerlist.c:2484)
==21699== by 0x80C712F: router_load_routers_from_string (routerlist.c:2841)
==21699== by 0x80C077D: router_reload_router_list_impl (routerlist.c:566)
==21699== by 0x80C0818: router_reload_router_list (routerlist.c:594)
==21699== by 0x80A7A2E: do_main_loop (main.c:1330)
==21699== by 0x80A8F26: tor_main (main.c:2606)
==21699== by 0x80DD9D9: main (tor_main.c:28)
I only notice this now because I recently changed the call to
control_event_descriptors_changed() so we also look at the ri's when
we're not listening for certain controller events -- see
routerlist_descriptors_added().
I notice there are a few other places that call router_add_to_routerlist()
and expect ri to be usable if it doesn't fail -- including in dirserv.c,
which might explain some of these "routerlist has a freed routerinfo" bugs
we keep seeing on authorities.
So the first question is: what's the chain of events that causes
router_add_to_routerlist() to return >=0 yet to free the routerinfo?
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/456sometimes dir mirrors answer 503 busy when they should say 4042020-06-27T14:10:36ZRoger Dingledinesometimes dir mirrors answer 503 busy when they should say 404In dirserv_estimate_data_size() we estimate the size assuming we have a descriptor
for every server we're asked about. This results in cases like
Jul 12 20:03:56.471 [info] connection_dir_client_reached_eof(): Received http status code ...In dirserv_estimate_data_size() we estimate the size assuming we have a descriptor
for every server we're asked about. This results in cases like
Jul 12 20:03:56.471 [info] connection_dir_client_reached_eof(): Received http status code 404 ("Servers unavailable") from server '161.53.160.104:9091' while fetching "/tor/server/d/15EB28E14A7983129CD78FC6DEA20FD21098A7EF+161342319749ADD4116CE0427DB328F5C4BE1629+165BAFDA7253DFEC1DE0A3C548F21DDEAEF52F9E+1692BCEEC6431120B7AEC3A1685C8FD0EEC5F5A9+16D6BEE79128246B32EE1C565B2C2DBCB9AB41D3+16E162BE70678D6BFD5CF63F86B9188FE771B31F+16E567D955496CA338D3432B097F157DF35DE8BC+1715CD5D98964C7E31B36B66C52E14DDA7816EA9+1723E44E2245391BEC1B483126B5FAA870444B7C+1731772EE54F2A51E6749F25F9EE6BFB65FB6858+1759016C497AC642B5A50130AFCCF1BB6B643A02+17AEAC0A87BB35E4F2EA041FDA24F5DBC3A792AB+17B881474EA0A2F64F989263A7AD30A0DCE6377D+183528CAC37D3FA3EF18281C948DD213CF08D087+184C7E375ACB1CC1AF908DD957A180C93AA4227E+1869C3BA669EF6264614A3888D5E9B43C5FE3884+1874E43C98993E8285DBC3752920D02C6C951663+18965516ED4CF01866788451421C9EDF1E6BD1AA+190A1DF5C543AC6BB9AB72FE8C4C7CDCAE86D2B0+197F9E91C8D2FED74C36FBD4DA00C5D632144468+19A126F8CC87F339F2B16A273F1CD0A247F2FA4A+19C704F44ECB6BF79170E09C634790B98C8D8544+19E487A6A3A272A04EF882FB07A2EE90895090CE+1A720FCD4A2849C83A2701CDD0D39D8FFD2E314D+1AA750EE5B7FED285F368B6FEB4428DF92C2BB31+1AB2DABF6007241131C5E443CDC60394761816AC+1AF2B7488D10BFDCFE6CA79D56FB83656F4ADC8D+1AF69AAD27DFB6AA63D1072FA5AED92B468540DE+1B6D306CA8E0C693FAD3FFAAFC59F653DEFB1491+1BA661163B8A14B9AFB98AA9D12B18A24CBE562A+1BC0D0980C5EB734AAD02B9E70CCFCC898CB315A+1BDDBDA5C4E6DB9B3443D979352A7BC9A9576FE1+1BE953E3BB58CE9B6EE261BF441C7F9B3BDA752D+1C0E414654093BA94EE84764C711449B0ED5704F+1C11365A76C3A583E708C040E6A3307F9043D02F+1C1CC7E04750FB2A0CADD6B2C70FFF50CC31C632+1C34CC4FEA875DBDDCF419DEB6A9DB48DDA652F9+1C7DFC2A6F38DC9EB1B3FCB6C2F865EBA6D19F74+1CB80E88CBE0573EE7E856797E0A7B32ECE7B4B7+1CF9F520154EA3C12A3AA42AE79C75F1DE4B6309+1D2BC778F1CEC8A37C33A6EE2897C7597B7CD526+1D878DC7566F10B8303138B36971023038F6F36C+1DB1A4D87A94E8CC2838C8E83F411A8CF5FBA0AC+1DC7FE119A441AFBD18E821B56CAB844278F8AF3+1DED6B4805370219D52E1C14C52092789C7EB8D7+1E33A33694596F3D6121C92FDA8882E2EC3A76C4+1E67F16C391DAFBD830049A379DD691EBC22E6B1+1ED62D8D7DA9F76501B7F95D9D7DD7E002F93640+1F35B4C9F94020AE9893C7358D9FA6D15A0B6807+1FCCEC0102ABE5A8BA18B4D34CBA3F3300FDE5AE+1FDE4FBC452C5D2BECEAF0B3CB15F644380D2A75+1FF2733FC1812FBAD51FEBBDE259B06BE0921A59+204697B4DF76664425ADB9F3F8D0B1A3591CA695+209F6EFEE6FDE553FEE8748FA5A7BA70964965F9+20AC0F4CFC447C4C9C18F42356104CABDFBD0D20+21036C9FF860815C8C043597B39BC80AE40A3560+212474B60CC275F91F716F89C5751E4BB7A78B5F+213E8B394E0590A9EC9360BB415867E00A1978E7+214AE65A8196F9C6EFC4765F0488A3CE7FBC433A+2172560E8EE391D29C5218446A242F822F1E1AE1+21743952EB0C848BE0D513926C989AA79EEAA0AC+21976CED8984D0099810A17793F49585C2BE5DD0+21A3E413C450399FD8AE5A7CEE3624DF7953DF54+21CE269692672D3FED7435B6F1F5D7BC22D334BC.z". I'll try again soon.
Jul 12 20:03:58.430 [info] connection_dir_client_reached_eof(): Received server info (size 0) from server '213.239.207.67:9032'
Jul 12 20:03:58.430 [info] connection_dir_client_reached_eof(): Received http status code 404 ("Servers unavailable") from server '213.239.207.67:9032' while fetching "/tor/server/d/9CE4717E88E096DF81C1C4FF04F9ECBEC7CD3A5B+9CF6B523BEDDAF0BB9E0365F235A30FE9B773481+9D1A6720FBD2A10956C0EC3F9906DB05F73BD0D4+9D6755D980C8A0FDE344C8D9DC075EFB55C1E65A+9D9674E83A649A5DB589467AE1BFC5D8C788344F+9DFE225679B7D8D1695E2F86EB9D5E25D8EBAB34+9E1B301AD61B971FE4014F90834D86167DB010CF+9E3C0B1343829809EEF2232B8F8A147DF40EB489+9E7D917BFA42EFA9A2FD520905662700FF39B6A9+9EFD73CEE0CF4DC558813599D6192FD493543894+9F0C194B70D97C3CDFFD8567054434BC58D241F4+9F37436BFE30729AE1C0F950F33BFC9111EA1C73+9F3E0FB041996920B40459961F195B5CD6399DC6+9FFCA011607CA2D04E5203DB9D0E81895F44C3F3+A0069CAD4ECA76DCB8A65665320DA7E17FFC93AD+A0133D0C1179A17FAC6C330012EAACE88CC611B9+A06385CA613FB0FCA712B7A5A2D2C5295AEBABAF+A09C82BE0551B262534A5E86343641B4D6773F85+A0AB774DE5543FBF9F9E79D6EA1EA7CF661E4461+A0AE08580B0169C82DB5D7D10FDC943BF8EEA7D3+A0C9E180FEAC7560B0560FAB88BF501C4714661A+A11B9D281FEA020597B0446248768F87D49EFE7A+A1841B8634E7766CD45119C907BF277C81C94FDB+A229B8C784C10932F5DD54F015E25D04730253EE+A23AB6FA0D08881A364E0E2CB881D7E3B805440F+A28055279C866549A1A0F51640D664D4A6FB3B41+A2BD80D6BD0E0805AEB05DF56178F0C158935A5C+A2C78532A2681EC56FCBE7E45C02353769BC1D95+A2D1067D7018B5EC457FFBF300F8829CB75031D2+A2E18660748CD4E2889655C13C515D2DDBC41256+A310436DD2C0BB21D0F1D821F25CF306C0BB8C37+A3329045F8D856CE1FC53318AF5078A36AD2012D+A3B99B3F0FD34C724249BD96D22B19402F3D028C+A419E8229A5DA157D2A08B76D29812B20E4F4433+A42CDE78731DB4732D4081737159F04945FE1AF2+A62B099009D02859F8B6CEAC9EC7593565B39E2A+A647325F16245859ABE97A91589550580719BEA1+A64CB0CF7D84039AC62B94727BF652204EC6816A+A695737A181822C144918FF5F4E9442EBB1A1249+A6CFCF877338AEF9423682989BE59A47910C9AFB+A6D5D4F300AEC3D2547A8087BECB2DC4BB7C3522+A705D5C1A04E02FEC2B9C65268B6066C53A95F3C+A723F2CCA05D6DBD26AD94C3A944E32BFDC78CDD+A72E0D5CA9E9EA457DA4FE59E94D0A9196F2C1E3+A74F5A31716382AA22CDBE96B5802527B5E4060E+A79F558B7A04CDCC76F3B9D7F57B12A49CEDC1E7+A7A114CFB2FD516205398920C8FC736305D8FE45+A828AB492F31A601136DD88EA4FAF313CB6B1A8A+A86240001CFD23E8501EB2CEE9B7E4FB0BE975DE+A8659A991509E1C2F26CB365184A106862A5060B+A878DCD037042319797E8017710138E835BE13BE+A886F2F8922803AD86242E20BDF17DA28A176791+A8DA069ABD97A98F4B842657D712E294648B6255+A8E6040879A14E6201D07DB10EE7AEBF1AC594C9+A9A306117B642E064D6065682325FAB355808904+A9B2472A36D800F37D31C7FCFDBA9625168CC6E1+AAEC2FDD441EC9AB9BF7C9F61B8E1C187A0643D7+AB03995964674450EC79D4A88E79898639780404+AB05341E510E4915874FF2C8A678B3FD0BE0EA7A+AB29C2B963427F98B18D4D8CA8927B671990AFDC+AB40DAFA0B6E91C114DBD9A6DEC69DF9A10C4D4A+ABBBE14C5B168675FE13B129B8B3076A0E1DFB59.z". I'll try again soon.
Jul 12 20:03:59.267 [info] connection_dir_client_reached_eof(): Received http status code 503 ("Directory busy, try again later") from server '70.84.114.153:9030'. I'll try again soon.
where the client is inefficient at realizing that it's asking for descriptors
that aren't available anywhere. If we estimated a bit better (by checking if we
have an answer at all), we could help clients react quicker. This would require
figuring out what descriptors we're being asked about, which means doing more
work before we decide whether to 503.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/455tor segfaults on 64k-aligned cached-routers file2020-06-27T14:10:37ZTractor segfaults on 64k-aligned cached-routers fileThis bug is for svn and the 0.1.2.x tree, which are both affected.
When Tor gets to the end of an 4k-aligned file (page size?), it segfaults in eat_whitespace()
The problem is imminent at routerparse.c:899 when both end and eos are out...This bug is for svn and the 0.1.2.x tree, which are both affected.
When Tor gets to the end of an 4k-aligned file (page size?), it segfaults in eat_whitespace()
The problem is imminent at routerparse.c:899 when both end and eos are out of bounds. (eos is (always?) out of bounds when the mmap is page-aligned.)
Execution then enters router_parse_entry_from_string(), which calls tokenize_string(s, end...) with end out of bounds. That calls eat_whitespace, which is not safe for non-null-terminated strings (as it has no end pointer or length specifier).
Steps to reproduce:
1. minimal torrc with RunAsDaemon 0, DataDirectory /some/path/ which points to...
2. A valid 4096-byte (I've only tested with 2!^x * 4096-byte files) cached-routers file (below, or take an existing cached-routers file and chop it, then duplicate/remove/modify exit policy entries until you get to an appropriate size)
I've collected sample cached-routers files of the obvious sizes that seems to trigger the bug on both my x86 and x86-64 machines.
http://70.242.110.86/svn/cr/
The crashes I get are in eat_whitespace(), but the original reporter on IRC was seeing segfaults in 0.1.2.14, routerparse.c:679 -- on PPC.
A representative backtrace from his PPC is at http://www.pastebin.ca/608408
One with a segfault in eat_whitespace (on x86-64) is at http://www.pastebin.ca/608454
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: crouphttps://gitlab.torproject.org/tpo/core/tor/-/issues/454streams never reaching SocksTimeout2020-06-27T14:10:37ZRoger Dingledinestreams never reaching SocksTimeoutReported by lodger:
<lodger> arma: i found the endless attempt to change circuit at
connection_edge.c; connection_ap_expire_beginning(); There is no limit to the
number of attempts to replace circuit, if the expectation it is more than ...Reported by lodger:
<lodger> arma: i found the endless attempt to change circuit at
connection_edge.c; connection_ap_expire_beginning(); There is no limit to the
number of attempts to replace circuit, if the expectation it is more than 15
seconds of answer to cell RELAY_COMAND_BEGIN. If the application of user does
not have a time out of expectation, and the process of constructing the new
circuits is always successful, but the address inquired by user is not
accessible, then the process of changing
the circuits is infinite.
<lodger> hang up on the stream after only if no new circuit
> see connection_ap_handshake_attach_circuit() in circuituse.c
> hm. or maybe not that. hang on. :)
> hm. that was where it used to be. it appears to be in
+connection_ap_expire_beginning() now, you're right.
> i wonder why the timeout got moved from attach-circuit to expire-beginning.
> probably because not everything was hitting attach-circuit. e.g. controller
connections don't.
> but maybe we should put a check in both places?
> lodger: have you actually experienced this, or you just think it might
happen?
<lodger> i have that situation in practice
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/453main.c:367 connection_stop_writing2020-06-27T14:10:37ZTracmain.c:367 connection_stop_writingMy server has been running for weeks fine and it ended recently with the following error: ERR: main.c:367 connection_stop_writing.
I will reply to this message if it happens again. I will also enable error logs this time for more details...My server has been running for weeks fine and it ended recently with the following error: ERR: main.c:367 connection_stop_writing.
I will reply to this message if it happens again. I will also enable error logs this time for more details.
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: johndoe32102002https://gitlab.torproject.org/tpo/core/tor/-/issues/452libevent call with win32 failed: No buffer space available [WSAENOBUFS ] [10055]2020-06-27T14:10:37ZTraclibevent call with win32 failed: No buffer space available [WSAENOBUFS ] [10055]This is occurring frequently, It stops tor server.
jun 30 13:39:03.011 [Fout] libevent call with win32 failed: No buffer space available [WSAENOBUFS ] [10055]
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**T...This is occurring frequently, It stops tor server.
jun 30 13:39:03.011 [Fout] libevent call with win32 failed: No buffer space available [WSAENOBUFS ] [10055]
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: pjzzzhttps://gitlab.torproject.org/tpo/core/tor/-/issues/451Bug: main.c:367: connection_stop_writing: Assertion conn->write_event failed;...2020-06-27T14:10:37Zweasel (Peter Palfrader)Bug: main.c:367: connection_stop_writing: Assertion conn->write_event failed; abortingOn tor26, after running for about 2 weeks, I get:
[err] Bug: main.c:367: connection_stop_writing: Assertion conn->write_event failed; aborting.
tor26 is:
* r10579
-O0
../../patch-debian-rules-DDEBUG_ROUTERLIST+INSTRUMENTDOWNLOADS...On tor26, after running for about 2 weeks, I get:
[err] Bug: main.c:367: connection_stop_writing: Assertion conn->write_event failed; aborting.
tor26 is:
* r10579
-O0
../../patch-debian-rules-DDEBUG_ROUTERLIST+INSTRUMENTDOWNLOADS
../../patch-tor-docs
../../patch-routerlist--two-asserts # just assert pointers added to the rl->routers list are even (legacy/trac%"0.0.9.5"==0)
../../patch-routerlist--shouldrebuildstore # rebuild store iff stats->journal_len > (5000)
../../patch-routerlist--writeoutforeach # in routerlist_assert_ok write out the first instance of the SMARTLIST_FOREACH makro
(gdb) bt
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7d04885 in raise () from /lib/tls/i686/cmov/libc.so.6
legacy/trac#2 0xb7d06002 in abort () from /lib/tls/i686/cmov/libc.so.6
legacy/trac#3 0x080a0c0f in connection_stop_writing (conn=0xed58948) at main.c:367
legacy/trac#4 0x0807b8f4 in connection_or_finished_flushing (conn=0xed58948) at connection_or.c:283
legacy/trac#5 0x08071afe in connection_finished_flushing (conn=0xed58948) at connection.c:2601
legacy/trac#6 0x08070ad1 in connection_handle_write (conn=0xed58948, force=0) at connection.c:2144
legacy/trac#7 0x080a14a5 in conn_write_callback (fd=241, events=4, _conn=0xed58948) at main.c:525
(gdb) p *conn
$1 = {magic = 2100428547, type = 4 '\004', state = 5 '\005', purpose = 0 '\0',
read_blocked_on_bw = 0, write_blocked_on_bw = 0,
hold_open_until_flushed = 0, inbuf_reached_eof = 0, edge_has_sent_end = 0,
edge_blocked_on_circ = 0, or_is_obsolete = 0, chosen_exit_optional = 0,
s = -1, conn_array_index = 561, read_event = 0x0, write_event = 0x0,
inbuf = 0xae38088, outbuf = 0xa0ee8a0, outbuf_flushlen = 0,
timestamp_lastread = 1182903016, timestamp_lastwritten = 1182903023,
timestamp_created = 1182869105, socket_family = 2, addr = 2331677697,
port = 41178, marked_for_close = 2087,
marked_for_close_file = 0x80fb026 "connection.c",
address = 0x8c44208 "138.250.148.1", linked_conn = 0x0, linked = 0,
reading_from_linked_conn = 0, writing_to_linked_conn = 0,
active_on_link = 0, dns_server_port = 0x0}
Let me know if there's any more info you might want to have.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/450routerlist_assert_ok: Assertion !memcmp(r->cache_info.identity_digest, d, DIG...2020-06-27T14:10:37Zweasel (Peter Palfrader)routerlist_assert_ok: Assertion !memcmp(r->cache_info.identity_digest, d, DIGEST_LEN) failed * r10564
Jun 13 05:41:37.038 [err] Bug: routerlist.c:5197: routerlist_assert_ok: Assertion !memcmp(r->cache_info.identity_digest, d, DIGEST_LEN) failed; aborting.
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7d2a885 in raise () from ... * r10564
Jun 13 05:41:37.038 [err] Bug: routerlist.c:5197: routerlist_assert_ok: Assertion !memcmp(r->cache_info.identity_digest, d, DIGEST_LEN) failed; aborting.
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7d2a885 in raise () from /lib/tls/i686/cmov/libc.so.6
legacy/trac#2 0xb7d2c002 in abort () from /lib/tls/i686/cmov/libc.so.6
legacy/trac#3 0x080c6b92 in routerlist_assert_ok (rl=0x8167808) at routerlist.c:5197
legacy/trac#4 0x080be709 in routerlist_remove (rl=0x8167808, ri=0x86344e0, idx=52, make_old=1) at routerlist.c:2064
legacy/trac#5 0x080c04c2 in routerlist_remove_old_routers () at routerlist.c:2679
legacy/trac#6 0x080c5756 in update_router_have_minimum_dir_info () at routerlist.c:4858
legacy/trac#7 0x080c56f0 in router_have_minimum_dir_info () at routerlist.c:4829
legacy/trac#8 0x080a2329 in run_scheduled_events (now=1181706097) at main.c:1024
legacy/trac#9 0x080a274d in second_elapsed_callback (fd=-1, event=1, args=0x0) at main.c:1163
(gdb)
legacy/trac#3 0x080c6b92 in routerlist_assert_ok (rl=0x8167808) at routerlist.c:5197
5197 tor_assert(!memcmp(r->cache_info.identity_digest, d, DIGEST_LEN));
(gdb) p r
$1 = (routerinfo_t *) 0x86344e0
(gdb) p iter
$2 = (digestmap_iter_t *) 0x85b8524
(gdb) p d
$3 = 0x8b9f4bc "nzxß\235\035/W\b5ë£\222bàwñä\016½("
(gdb) p *r
$4 = {cache_info = {signed_descriptor_body = 0x86340e8 "(", signed_descriptor_len = 3085125992, signed_descriptor_digest = 'M' <repeats 20 times>,
identity_digest = 'M' <repeats 20 times>, published_on = 1296911693, extra_info_digest = 'M' <repeats 20 times>, ei_dl_status = {next_attempt_at = 1296911693,
n_download_failures = 77 'M'}, saved_location = 1296911693, saved_offset = 5570193308531903821, do_not_cache = 1, is_extrainfo = 0},
address = 0x4d4d4d4d <Address 0x4d4d4d4d out of bounds>, nickname = 0x4d4d4d4d <Address 0x4d4d4d4d out of bounds>, addr = 1296911693, or_port = 19789,
dir_port = 19789, onion_pkey = 0x4d4d4d4d, identity_pkey = 0x4d4d4d4d, platform = 0x4d4d4d4d <Address 0x4d4d4d4d out of bounds>, bandwidthrate = 1296911693,
bandwidthburst = 1296911693, bandwidthcapacity = 1296911693, exit_policy = 0x4d4d4d4d, uptime = 1296911693, declared_family = 0x4d4d4d4d,
contact_info = 0x4d4d4d4d <Address 0x4d4d4d4d out of bounds>, is_hibernating = 1, has_old_dnsworkers = 0, caches_extra_info = 1, is_running = 1, is_valid = 0,
is_named = 0, is_fast = 1, is_stable = 0, is_possible_guard = 1, is_exit = 0, is_bad_exit = 1, purpose = 77 'M', last_reachable = 1296911693,
testing_since = 1296911693, num_unreachable_notifications = 1296911693, routerlist_index = 176}
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/449dns failures prevent legitimate options being set2020-07-24T12:17:20ZRobert Hogandns failures prevent legitimate options being setOutright hostname lookup failures for previously configured hidden services prevent other options being set
while DNS is down.
For example, I configure a hidden service redirecting to google.com while DNS is working. DNS subsequently s...Outright hostname lookup failures for previously configured hidden services prevent other options being set
while DNS is down.
For example, I configure a hidden service redirecting to google.com while DNS is working. DNS subsequently stops working,
e.g. nameserver becomes completely unreachable. If I then attempt to set a config option using the controller, it will
not get set as long as tor cannot resolve the hidden service name.
Rejection of hidden service configurations (and hence any subsequent or unrelated config change) made while tor is running
needs to be more tolerant of lookup failures.
The following attempts to validate the hidden service config currently in use (and previously validated when DNS was working).
If the validation fails, it must be because DNS is down, so the existing config is retained. If the user was attempting to add
a new hidden service config, then it doesn't get added.
```
Index: src/or/config.c
===================================================================
--- src/or/config.c (revision 10545)
+++ src/or/config.c (working copy)
@@ -963,10 +963,15 @@
}
}
- if (running_tor && rend_config_services(options, 0)<0) {
- log_warn(LD_BUG,
- "Previously validated hidden services line could not be added!");
- return -1;
+ if (running_tor && rend_config_services(options, 1)<0) {
+ log_warn(LD_CONFIG,
+ "Previously validated hidden services line no longer valid! Retaining existing hidden services config if there is one.");
+ }else{
+ if (rend_config_services(options, 0)<0){
+ log_warn(LD_BUG,
+ "Previously validated hidden services line could not be added!");
+ return -1;
+ }
}
if (running_tor) {
@@ -2920,9 +2925,10 @@
}
}
+/*
if (rend_config_services(options, 1) < 0)
REJECT("Failed to configure rendezvous options. See logs for details.");
-
+*/
if (parse_virtual_addr_network(options->VirtualAddrNetwork, 1, NULL)<0)
return -1;
```
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/448We discard old guards before getting new networkstatuses2020-06-27T14:10:38ZRoger DingledineWe discard old guards before getting new networkstatuses Jun 09 01:23:05.146 [info] router_set_networkstatus(): Setting networkstatus cac
hed from directory server "moria1" at 128.31.0.34:9031 (published 2007-05-09 06:
29:03)
Jun 09 01:23:05.174 [info] networkstatus_list_update_recent(): Netw... Jun 09 01:23:05.146 [info] router_set_networkstatus(): Setting networkstatus cac
hed from directory server "moria1" at 128.31.0.34:9031 (published 2007-05-09 06:
29:03)
Jun 09 01:23:05.174 [info] networkstatus_list_update_recent(): Networkstatus fro
m directory server "moria1" at 128.31.0.34:9031 (published 2007-05-09 06:29:03)
is now "recent"
Jun 09 01:23:05.189 [info] router_set_networkstatus(): Setting networkstatus cac
hed from directory server "tor26" at 86.59.21.38:80 (published 2007-05-09 06:26:
56)
Jun 09 01:23:05.217 [info] networkstatus_list_update_recent(): Networkstatus fro
m directory server "tor26" at 86.59.21.38:80 (published 2007-05-09 06:26:56) is
now "recent"
Jun 09 01:23:05.232 [info] router_set_networkstatus(): Setting networkstatus cac
hed from directory server "dizum" at 194.109.206.212:80 (published 2007-05-09 06
:27:03)
Jun 09 01:23:05.261 [info] networkstatus_list_update_recent(): Networkstatus fro
m directory server "dizum" at 194.109.206.212:80 (published 2007-05-09 06:27:03)
is now "recent"
Jun 09 01:23:05.276 [info] router_set_networkstatus(): Setting networkstatus cac
hed from directory server "moria2" at 128.31.0.34:9032 (published 2007-05-09 06:
27:13)
Jun 09 01:23:05.304 [info] networkstatus_list_update_recent(): Networkstatus fro
m directory server "moria2" at 128.31.0.34:9032 (published 2007-05-09 06:27:13)
is now "recent"
Jun 09 01:23:05.304 [info] networkstatus_list_update_recent(): Networkstatus fro
m directory server "tor26" at 86.59.21.38:80 (published 2007-05-09 06:26:56) is
no longer "recent"
Jun 09 01:23:05.319 [info] router_set_networkstatus(): Setting networkstatus cac
hed from directory server "lefkada" at 140.247.60.64:80 (published 2007-05-09 06
:27:01)
Jun 09 01:23:05.348 [info] networkstatus_list_clean(): Removing too-old networks
tatus in moria5/cached-status/847B1F850344D7876491A54892F904934E4EB85D
Jun 09 01:23:05.348 [info] networkstatus_list_clean(): Removing too-old networks
tatus in moria5/cached-status/FFCB46DB1339DA84674C70D7CB586434C4370441
Jun 09 01:23:05.349 [info] networkstatus_list_clean(): Removing too-old networks
tatus in moria5/cached-status/719BE45DE224B607C53707D0E2143E2D423E74CF
Jun 09 01:23:05.349 [info] networkstatus_list_clean(): Removing too-old networks
tatus in moria5/cached-status/7EA6EAD6FD83083C538F44038BBFA077587DD755
Jun 09 01:23:05.349 [info] networkstatus_list_clean(): Removing too-old networks
tatus in moria5/cached-status/38D4F5FCF7B1023228B895EA56EDE7D5CCDCAF32
Jun 09 01:23:05.350 [info] routerstatus_list_update_from_networkstatus(): Not en
ough statuses to update router status list. (0/5)
Jun 09 01:23:05.350 [info] entry_guards_compute_status(): Summary: Entry 'h76066
2' is reachable, unusable and not live.
Jun 09 01:23:05.350 [info] remove_dead_entries(): Entry guard 'h760662' (554EC78
2556A47590FB5B4DEFF56A5B52DB9CD59) has been down or unlisted since 2007-05-08 05
:39:00 local time; removing.
The problem is that routers_update_all_from_networkstatus() calls
entry_guards_compute_status() even if there aren't enough statuses
around yet.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/447Directory information not kept up to date2020-06-27T14:10:38ZTracDirectory information not kept up to dateJun 05 23:14:10.928 [notice] Tor 0.1.2.14 opening log file.
Jun 05 23:14:11.096 [notice] Your Tor server's identity key fingerprint is 'dragon E710 B7B1 BCC6 5FEC E5BA 345C EC8B 81BE A216 318F'
Jun 05 23:14:11.526 [notice] I learned some...Jun 05 23:14:10.928 [notice] Tor 0.1.2.14 opening log file.
Jun 05 23:14:11.096 [notice] Your Tor server's identity key fingerprint is 'dragon E710 B7B1 BCC6 5FEC E5BA 345C EC8B 81BE A216 318F'
Jun 05 23:14:11.526 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 05 23:14:15.555 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Jun 05 23:14:24.607 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 05 23:14:54.738 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 05 23:15:03.791 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 05 23:15:08.821 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 05 23:15:09.798 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 05 23:15:09.805 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 05 23:15:13.852 [notice] We now have enough directory information to build circuits.
Jun 05 23:15:18.839 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Jun 05 23:15:40.795 [notice] Performing bandwidth self-test...done.
Jun 07 19:51:15.879 [notice] Our directory information is no longer up-to-date enough to build circuits.
Jun 07 19:55:29.929 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 07 20:25:53.705 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 07 20:56:31.611 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 07 21:26:57.203 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 07 21:57:27.637 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 07 22:27:53.741 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 07 22:58:24.316 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 07 23:28:55.848 [notice] I learned some more directory information, but not enough to build a circuit.
It stays stuck here until I poke it:
Jun 07 23:51:32.901 [notice] Application request when we're believed to be offline. Optimistically trying directory fetches again.
Jun 07 23:51:46.292 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 07 23:52:17.430 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 07 23:52:31.504 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 07 23:52:32.514 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 07 23:52:33.512 [notice] We now have enough directory information to build circuits.
Restarting works too. The time delay is usually about the same, just under 2 days. I don't know when this started happening, so I can't tell you if it's due to 0.1.2.14 or not.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: taral0.2.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/446we don't check which hop a cell is from well enough2020-06-27T14:10:38ZRoger Dingledinewe don't check which hop a cell is from well enoughIf the streamid of one stream on our circuit collides with the streamid of another
stream (say, because they exit at different hops), this goes bad. There may also be
an attack here where intermediate hops can try to inject cells into st...If the streamid of one stream on our circuit collides with the streamid of another
stream (say, because they exit at different hops), this goes bad. There may also be
an attack here where intermediate hops can try to inject cells into streams that
are supposed to be at different hops.
(Somebody should look at this harder before we blindly put the patch in.)
Patch from lodger:
--- relay.c Fri May 25 06:51:40 2007
+++ relay.c Tue Jun 5 07:30:38 2007
@@ -18,5 +18,5 @@
crypt_path_t **layer_hint, char *recognized);
static edge_connection_t *relay_lookup_conn(circuit_t *circ, cell_t *cell,
- int cell_direction);
+ int cell_direction, crypt_path_t *layer_hint);
static int
@@ -163,5 +163,6 @@
if (recognized) {
- edge_connection_t *conn = relay_lookup_conn(circ, cell, cell_direction);
+ edge_connection_t *conn = relay_lookup_conn(circ, cell, cell_direction,
+ layer_hint);
if (cell_direction == CELL_DIRECTION_OUT) {
++stats_n_relay_cells_delivered;
@@ -373,5 +374,6 @@
*/
static edge_connection_t *
-relay_lookup_conn(circuit_t *circ, cell_t *cell, int cell_direction)
+relay_lookup_conn(circuit_t *circ, cell_t *cell, int cell_direction,
+ crypt_path_t *layer_hint)
{
edge_connection_t *tmpconn;
@@ -391,5 +393,6 @@
tmpconn=tmpconn->next_stream) {
if (rh.stream_id == tmpconn->stream_id &&
- !tmpconn->_base.marked_for_close) {
+ !tmpconn->_base.marked_for_close &&
+ tmpconn->cpath_layer == layer_hint) {
log_debug(LD_APP,"found conn for stream %d.", rh.stream_id);
return tmpconn;
[Automatically added by flyspray2trac: Operating System: All]Roger DingledineRoger Dingledinehttps://gitlab.torproject.org/tpo/core/tor/-/issues/445tor-gencert should create files with proper permissions2020-06-27T14:10:38Zweasel (Peter Palfrader)tor-gencert should create files with proper permissionstor-gencert creates files with the default mode. It should probably ensure that the
private key files are created in such a way that they are not world or group readable
[Automatically added by flyspray2trac: Operating System: All]tor-gencert creates files with the default mode. It should probably ensure that the
private key files are created in such a way that they are not world or group readable
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/444connecting to a hidden service port that does not exist kills existing connec...2020-06-27T14:10:38Zweasel (Peter Palfrader)connecting to a hidden service port that does not exist kills existing connectionsThis is either a bug in the hidden service, or in the client code, I don't know which.
Symptoms: If you have a connection established to a hidden service on some port,
and then open a new connection to a port that it does not listen on...This is either a bug in the hidden service, or in the client code, I don't know which.
Symptoms: If you have a connection established to a hidden service on some port,
and then open a new connection to a port that it does not listen on your already
existing connection is torn down.
e.g.:
socat TCP4-LISTEN:4242,fork SOCKS4A:localhost:37lnq2veifl4kar7.onion:6667,socksport=9050 &
telnet to localhost 4242, log on to IRC.
socat TCP4-LISTEN:4343,fork SOCKS4A:localhost:37lnq2veifl4kar7.onion:80,socksport=9050
telnet localhost 4343 -> irc connection dies.
[Automatically added by flyspray2trac: Operating System: All]Roger DingledineRoger Dingledinehttps://gitlab.torproject.org/tpo/core/tor/-/issues/443niutil and nidump are no longer existant in 10.5 leopard, so you should use d...2020-06-27T14:10:38ZTracniutil and nidump are no longer existant in 10.5 leopard, so you should use dscl insteadas the niutil tool does not exist in osx 10.5 leopard installation of tor fails,
because the user _tor is not created.
instead of nidump you could maybe create the user via dscl
[Automatically added by flyspray2trac: Operating System...as the niutil tool does not exist in osx 10.5 leopard installation of tor fails,
because the user _tor is not created.
instead of nidump you could maybe create the user via dscl
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: dave0.1.2.15Andrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/tpo/core/tor/-/issues/442[err] Bug: routerlist.c:51792020-06-27T14:10:38ZTrac[err] Bug: routerlist.c:5179Latest svn builds are dying after a few minutes:
May 29 06:40:02.099 [notice] Tor 0.2.0.0-alpha-dev (r10386) opening log file.
May 29 06:41:56.503 [err] Bug: routerlist.c:5144: routerlist_assert_ok: Assertion !memcmp(sd->extra_info_dige...Latest svn builds are dying after a few minutes:
May 29 06:40:02.099 [notice] Tor 0.2.0.0-alpha-dev (r10386) opening log file.
May 29 06:41:56.503 [err] Bug: routerlist.c:5144: routerlist_assert_ok: Assertion !memcmp(sd->extra_info_digest, d, DIGEST_LEN) failed; aborting.
May 29 20:40:35.883 [notice] Tor 0.2.0.0-alpha-dev (r10403) opening log file.
May 29 20:41:16.716 [err] Bug: routerlist.c:5179: routerlist_assert_ok: Assertion !memcmp(sd->extra_info_digest, d, DIGEST_LEN) failed; aborting.
Jun 01 17:06:20.127 [notice] Tor 0.2.0.1-alpha (r10442) opening log file.
Jun 01 17:07:00.140 [err] Bug: routerlist.c:5179: routerlist_assert_ok: Assertion !memcmp(sd->extra_info_digest, d, DIGEST_LEN) failed; aborting.
Jun 01 17:51:49.405 [notice] Tor 0.2.0.1-alpha (r10442) opening log file.
Jun 01 17:52:31.211 [err] Bug: routerlist.c:5179: routerlist_assert_ok: Assertion !memcmp(sd->extra_info_digest, d, DIGEST_LEN) failed; aborting.
debug backtrace:
clarity 130 -> gdb /usr/local/bin/tor tor.core
GNU gdb 5.3nb1
Core was generated by `tor'.
Program terminated with signal 6, Aborted.
Reading symbols from /usr/pkg/lib/libz.so.1...done.
Loaded symbols for /usr/pkg/lib/libz.so.1
Reading symbols from /usr/pkg/lib/libevent-1.3b.so.1...done.
Loaded symbols for /usr/pkg/lib/libevent-1.3b.so.1
Reading symbols from /usr/lib/libssl.so.3...done.
Loaded symbols for /usr/lib/libssl.so.3
Reading symbols from /usr/lib/libcrypto.so.2...done.
Loaded symbols for /usr/lib/libcrypto.so.2
Reading symbols from /usr/lib/libpthread.so.0...done.
Loaded symbols for /usr/lib/libpthread.so.0
Reading symbols from /usr/lib/libc.so.12...done.
Loaded symbols for /usr/lib/libc.so.12
Reading symbols from /lib/libcrypt.so.0...done.
Loaded symbols for /lib/libcrypt.so.0
Reading symbols from /usr/libexec/ld.elf_so...done.
Loaded symbols for /usr/libexec/ld.elf_so
#0 0xbd9f40fb in kill () from /usr/lib/libc.so.12
(gdb) bt
#0 0xbd9f40fb in kill () from /usr/lib/libc.so.12
#1 0xbda7517f in abort () from /usr/lib/libc.so.12
legacy/trac#2 0x080a0764 in routerlist_assert_ok (rl=0x8116240) at routerlist.c:5160
legacy/trac#3 0x0809bd10 in routerlist_remove_old_routers () at routerlist.c:2670
legacy/trac#4 0x0809fbfd in update_router_have_minimum_dir_info () at routerlist.c:4826
legacy/trac#5 0x0809fb5b in router_have_minimum_dir_info () at routerlist.c:4797
legacy/trac#6 0x080861a3 in directory_info_has_arrived (now=1180734750, from_cache=1)
at main.c:676
legacy/trac#7 0x08087211 in do_main_loop () at main.c:1345
legacy/trac#8 0x08087fed in tor_main (argc=7, argv=0xbfbfed1c) at main.c:2610
legacy/trac#9 0x080aa1bb in main (argc=7, argv=0xbfbfed1c) at tor_main.c:28
legacy/trac#10 0x0804ca66 in ___start ()
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: yancmhttps://gitlab.torproject.org/tpo/core/tor/-/issues/441Tor v0.2.0.1-alpha on IRIX crashes shortly after startup2020-06-27T14:10:39ZTracTor v0.2.0.1-alpha on IRIX crashes shortly after startupTor v0.2.0.1-alpha on IRIX crashes shortly after startup. Log snippet and backtrace attached below.
Jun 01 20:47:45.602 [notice] Tor v0.2.0.1-alpha. This is experimental software. Do not rely on it for strong anonymity. (Running on IRIX...Tor v0.2.0.1-alpha on IRIX crashes shortly after startup. Log snippet and backtrace attached below.
Jun 01 20:47:45.602 [notice] Tor v0.2.0.1-alpha. This is experimental software. Do not rely on it for strong anonymity. (Running on IRIX64 IP30)
[...]
Jun 01 20:47:54.161 [info] routerlist_remove_old_routers(): Forgetting obsolete (too old) routerinfo for router 'whowantstoknow'
Jun 01 20:47:54.162 [info] routerlist_remove_old_routers(): Forgetting obsolete (too old) routerinfo for router 'peleion'
Jun 01 20:47:54.162 [info] routerlist_remove_old_routers(): Forgetting obsolete (too old) routerinfo for router 'gondortor'
Jun 01 20:47:54.163 [info] routerlist_remove_old_routers(): Forgetting obsolete (too old) routerinfo for router 'splunk'
Jun 01 20:47:54.163 [info] routerlist_remove_old_routers(): Forgetting obsolete (too old) routerinfo for router 'opgdev'
Jun 01 20:47:54.164 [info] routerlist_remove_old_routers(): Forgetting obsolete (too old) routerinfo for router '2Wire6726'
Jun 01 20:47:54.164 [info] routerlist_remove_old_routers(): Forgetting obsolete (too old) routerinfo for router 'homer'
Jun 01 20:47:54.165 [err] Bug: routerlist.c:5179: routerlist_assert_ok: Assertion !memcmp(sd->extra_info_digest, d, DIGEST_LEN) failed; aborting.
routerlist.c:5179 routerlist_assert_ok: Assertion !memcmp(sd->extra_info_digest, d, DIGEST_LEN) failed; aborting.
Abort (core dumped)
---
dbx version 7.3.4 (86441_Nov11 MR) Nov 11 2002 11:31:55
Core from signal SIGABRT: Abort (see abort(3c))
(dbx) where
Thread 0x10000
> 0 _prctl(0x15, 0x4, 0xffff, 0x0, 0x0, 0x118, 0x2c0, 0x1a0) ["/xlv41/6.5.30m/work/irix/lib/libc/libc_n32_M4/proc/prctl.s":15, 0xfa4ac28]
1 pthread_kill(0x15, 0x6, 0xffff, 0x0, 0x0, 0x118, 0x2c0, 0x1a0) ["/xlv41/6.5.30m/work/eoe/lib/libpthread/libpthread_n32_M3/sig.c":150, 0xc0900c4]
2 _SGIPT_libc_raise(0x15, 0x4, 0xffff, 0x0, 0x0, 0x118, 0x2c0, 0x1a0) ["/xlv41/6.5.30m/work/eoe/lib/libpthread/libpthread_n32_M3/sig.c":660, 0xc0910d8]
3 _raise(0x15, 0x4, 0xffff, 0x0, 0x0, 0x118, 0x2c0, 0x1a0) ["/xlv41/6.5.30m/work/irix/lib/libc/libc_n32_M4/signal/raise.c":26, 0xfad1f3c]
4 abort(0x15, 0x4, 0xffff, 0x0, 0x0, 0x118, 0x2c0, 0x1a0) ["/xlv41/6.5.30m/work/irix/lib/libc/libc_n32_M4/gen/abort.c":52, 0xfa6f6b0]
5 routerlist_assert_ok(rl = 0x1012ebc0) ["/usr/people/jm/tmp/xxx/tor/src/or/routerlist.c":5179, 0x100b2714]
6 routerlist_remove_old_routers() ["/usr/people/jm/tmp/xxx/tor/src/or/routerlist.c":2670, 0x100a979c]
7 update_router_have_minimum_dir_info() ["/usr/people/jm/tmp/xxx/tor/src/or/routerlist.c":4826, 0x100b08ec]
8 router_have_minimum_dir_info() ["/usr/people/jm/tmp/xxx/tor/src/or/routerlist.c":4797, 0x100b086c]
9 directory_info_has_arrived(now = 1180723673, from_cache = 1) ["/usr/people/jm/tmp/xxx/tor/src/or/main.c":676, 0x1007fc94]
10 do_main_loop() ["/usr/people/jm/tmp/xxx/tor/src/or/main.c":1345, 0x10081808]
11 tor_main(argc = 3, argv = 0x7fff2f64) ["/usr/people/jm/tmp/xxx/tor/src/or/main.c":2610, 0x10083280]
12 main(argc = 3, argv = 0x7fff2f64) ["/usr/people/jm/tmp/xxx/tor/src/or/tor_main.c":28, 0x100c53dc]
13 __start() ["/xlv55/kudzu-apr12/work/irix/lib/libc/libc_n32_M4/csu/crt1text.s":177, 0x10014318]
(dbx) up 5
routerlist_assert_ok:5179 tor_assert(!memcmp(sd->extra_info_digest, d, DIGEST_LEN));
(dbx) p *sd
struct signed_descriptor_t {
signed_descriptor_body = 0x10201860 = ""
signed_descriptor_len = 1296911693
signed_descriptor_digest = ""
identity_digest = "MMMMMMMMMMMMMMMMMMMM"
published_on = 1296911693
extra_info_digest = "MMMMMMMMMMMMMMMMMMMM"
ei_dl_status = struct download_status_t {
next_attempt_at = 1296911693
n_download_failures = 'M'
}
saved_location = 1296911693
saved_offset = 5570193308531903821
do_not_cache = 0
is_extrainfo = 1
}
(dbx) p d
0x1023f214 = ""
[Automatically added by flyspray2trac: Operating System: Other]
**Trac**:
**Username**: jm