Opened 14 years ago

Last modified 7 years ago

#122 closed defect (Fixed)

0.1.0.2_RC_CVS - Unstable Builds Under NetBSD 2.0

Reported by: yancm Owned by: nickm
Priority: Low Milestone:
Component: Core Tor/Tor Version: 0.1.0.1-rc
Severity: Keywords:
Cc: yancm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

This is a Flyspray task for the NetBSD wierdness we have been discussing on the or-talk list.

To this point in time:

  • Beginning about March 30, my daily CVS builds were being unstable - for a few days they crashed upon launch
  • Then on April 3 or 4, the daily CVS builds started working again... web browsing through tor dramatically increased in speed relative to builds prior to March 30
  • About the same time there were many log messages. Initiated or-talk discussion...
  • On the evening of April 5 (I'm in Indiana - EST for ref.) Nick Mathewson informed me he fixed part of the problem in CVS but only for the no-pthreads version of tor.
  • Morning of April 6, tor was running fine and no new log messages.
  • Noticed new CVS changes so updated no-pthreads - restarted tor at 0600
  • Just Checked log @ April 6, 3:30PM:

Apr 06 06:06:49.935 [err] Catching signal TERM, exiting cleanly.
Apr 06 06:06:52.404 [notice] Tor 0.1.0.2-rc-cvs opening log file.
Apr 06 11:13:53.401 [warn] circuit_receive_relay_cell(): Didn't recognize cell, but circ stops here! Closing circ.
Apr 06 11:13:53.450 [warn] command_process_relay_cell(): circuit_receive_relay_cell (forward) failed. Closing.
Apr 06 11:15:01.928 [err] Catching signal TERM, exiting cleanly.
Apr 06 11:15:04.890 [notice] Tor 0.1.0.2-rc-cvs opening log file.

Note: I do not recall restarting tor at 11:15, no new core file was generated???

  • Just noticed more CVS changes, recompiled no-pthreads but have not installed and restarted ...should I?
  • If I don't hear back, I probably will update and restart prior to going to sleep tonight.

[Automatically added by flyspray2trac: Operating System: BSD]

Child Tickets

Change History (6)

comment:1 Changed 14 years ago by yancm

As of taoday, no-pthreads seems to be running fine.

I tried yes-pthreads this morning (04/07/2005 8AM EST) and it stopped responding
after a couple hours...I just rebuilt no-pthreads and am
letting that run.

comment:2 Changed 14 years ago by yancm

I compiled a CVS w/pthreads 4/7/2005 ~850PM EST

It crashed rather quickly...will go back to no-pthread, but here's the crash info FYI:

gdb backtrace
(gdb) bt
#0 0x4821cfeb in kill () from /usr/lib/libc.so.12
#1 0x481ecd80 in kq_dispatch () from /usr/lib/libevent.so.0
#2 0x4826430e in assert13 () from /usr/lib/libc.so.12
#3 0x48185a57 in RAND_SSLeay () from /usr/lib/libcrypto.so.2
#4 0x481856a2 in RAND_add () from /usr/lib/libcrypto.so.2
#5 0x481a277c in DH_OpenSSL () from /usr/lib/libcrypto.so.2
#6 0x481a290d in BN_rand () from /usr/lib/libcrypto.so.2
#7 0x481a240c in DH_OpenSSL () from /usr/lib/libcrypto.so.2
#8 0x481a2348 in DH_generate_key () from /usr/lib/libcrypto.so.2
#9 0x08089094 in crypto_dh_generate_public (dh=0x8191ad0) at crypto.c:1313
#10 0x080891f9 in crypto_dh_get_public (dh=0x8191ad0,

pubkey=0x4b3ffde8 "ö(mo\220HaI
AdoY-M@\236\e.E\213r\223\177-Ý4uy¯n'\023}\206¤~nA\202…}\225%E\226I\036‰7\230\201ñ–OˆD\002\226AWC\231r"i\026Ž3#\032AJ\235\222ö%@\03434\230g5O›N\177A\203\e\031\017F€”HAt\020H\b«(\212\236Š@ñ\234ñ$-{\004\216H=F«NOp1…š\0366;yi\177­U\t\210\232¯\215ª\223®", pubkey_len=128)
at crypto.c:1329

#11 0x0807088e in onion_skin_server_handshake (onion_skin=0x4b3ffed8 "œ",

private_key=0x80bb570, prev_private_key=0x0,
handshake_reply_out=0x4b3ffde8 "ö(mo\220HaI
AdoY-M@\236\e.E\213r\223\177-Ý4uy¯n'\023}\206¤~nA\202…}\225%E\226I\036‰7\230\201ñ–OˆD\002\226AWC\231r"i\026Ž3#\032AJ\235\222ö%@\03434\230g5O›N\177A\203\e\031\017F€”HAt\020H\b«(\212\236Š@ñ\234ñ$-{\004\216H=F«NOp1…š\0366;yi\177­U\t\210\232¯\215ª\223®",
key_out=0x4b3ffe88 "S&K‰\230\231¢\232™”?˜Y9ø\"EL0;–y€\aBIT“AI\220\215,Ž\034\026\aD\177Z\0251<m\202/‘§_.\026\221+n®x;£\037d\004j\205\232\bT~8_¢",
key_out_len=72) at onion.c:237

#12 0x08065003 in cpuworker_main (data=0x8191a70) at cpuworker.c:250
#13 0x08083eb7 in tor_pthread_helper_fn (_data=0x8191a90) at compat.c:686
#14 0x481fc4cd in pthread_create () from /usr/lib/libpthread.so.0

* Log File Entries
Apr 07 20:50:51.871 [notice] Tor 0.1.0.2-rc-cvs opening log file.
Apr 07 20:51:12.629 [err] cpuworker_main(): writing response buf failed. Exiting.
Apr 07 20:51:17.241 [err] cpuworker_main(): writing response buf failed. Exiting.
Apr 07 20:53:06.642 [err] cpuworker_main(): writing response buf failed. Exiting.
Apr 07 20:53:44.060 [err] cpuworker_main(): writing response buf failed. Exiting.
Apr 07 20:53:44.159 [err] cpuworker_main(): writing response buf failed. Exiting.
Apr 07 20:53:44.937 [err] cpuworker_main(): writing response buf failed. Exiting.
Apr 07 20:58:59.705 [err] cpuworker_main(): writing response buf failed. Exiting.

comment:3 Changed 14 years ago by yancm

Flyspray seems to limit comment length...annoying...

comment:4 Changed 14 years ago by nickm

Okay, this seems to be a general symptom of NetBSD not having
any way to do thread-safe DNS lookups. Stupid NetBSD!

The right fix here (for now) will be to disable multithreaded builds
when the system has no working reentrant gethostbyname/getaddrinfo,
and to be smarter with memory in that case too.

comment:5 Changed 14 years ago by arma

flyspray2trac: bug closed.
In 0.1.0.6-rc, we're going to disable pthreads by default for all netbsd servers. We think it's a bug in netbsd's getaddrinfo, which claims to be reentrant but seems not to be.

comment:6 Changed 7 years ago by nickm

Component: Tor RelayTor
Note: See TracTickets for help on using tickets.