[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #9299 [Tor]: Dump stack traces on assertion, crash, or general trouble

#9299: Dump stack traces on assertion, crash, or general trouble
-----------------------------+---------------------------------
     Reporter:  nickm        |      Owner:
         Type:  enhancement  |     Status:  needs_review
     Priority:  normal       |  Milestone:  Tor: 0.2.5.x-final
    Component:  Tor          |    Version:
   Resolution:               |   Keywords:  tor-relay debugging
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+---------------------------------

Comment (by andrea):

 Athena's code review follows:

 * 5343ee1a06ebb959fc77753898015186b94a5daa
   - Looks okay to me, but (nitpick) I don't think '0' + digit is quite
 perfectly portable.

 * f6d8bc9389db72dc654560d0f86fd3edd3b14934
   - Looks fine

 * 308ffbcfdd99424a1750b09f90721d9da38f761b
   - Why round to 15 minutes?

 * ff187fd1335968468f307d48157e5dcf4ad88b1f
   - Looks fine

 * 82743d6e560bbbbcbd22e09c3ec26f54d0656b75
   - Does TOR_CHECK_LDFLAGS actually add it to LDFLAGS for us?  what if it
 fails - shouldn't we set USE_BACKTRACE then?

 * 62645b5e18a8994c9257078f571d4227037a894c
   - Yeah, good move there :)

 * ab2a00ac4378e85f67da6e681a7c8609e3153db1
   - Looks okay to me, but yeesh signal handlers can get hairy.  I presume
 you've tested all this by actually invoking it from a signal handler?

 * fd7aa1af256b11cad9875fec875a570205aea0e0
   - Looks fine

 * c8ca168d0cfe58b8f86badbc17300f85adfedb31
   - Is not our code, and I sure hope Google didn't break it too badly.
 OpenBSD support seems to be missing and probably shouldn't be - and
 wouldn't be too hard to find out and add.  Linux/sparc{,64} is rather more
 obscure but I happen to have it at hand, so we could add that too.

 * 10411ee8c13bcf8de65a225a0cee5b0844fb5b9f
   - Looks fine

 * 3591d2079dabc7450b1a973045e000212a90b67d
   - Looks fine

 * 1d6af8099d9f3dafefdf75bb1411ec2bd669087f
   - Yay, unit tests!  Shouldn't tor_log_err_sigsafe() actually get invoked
 from a signal handler at some point though?

 * e1e638a169dd0a34455057b3f7cc895defd1f3cf
   - Yay, more unit tests!

 * abdfd8367b326e918ee49b4f35aa899859c6fca7
   - Looks fine

 * 74ac03f54b6d640e97330d4207cbb943337fa71d
   - Looks fine

 * 8b926717e601578f7f83aee9c7384d2ffb44d985
   - Looks fine

 * 85a520682f832314ffe5615ad2544558092bee52
   - Looks fine

 * e9f95a67ae4b35326293865034fe92e1df59ae43
   - Is an empty diff?

 * f0b9dd03abfd18a037f4ae0bbacecd34b35cad1a
   - Ouch! Am I reading that wrong, or did you just #error on any Linux
 that isn't one of the archs pc_from_ucontext.m4 supports? :(

 * 4871da62cd814a5ca50f03924b3492e8d3b2f89a
   - Looks fine

 * 511a8af458bbf56edaf7d1110dfe28c11274b7fb
   - Looks okay, but wouldn't it be better to just compile stuff like this
 with -O0?

 * 6fe53dc7ccd0e84316584a3352e598f66858d46c
   - Looks fine

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9299#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs