reading freed memory on handshake timeout

[charles]

==28122== 
==28122== Thread 2:
==28122== Invalid read of size 4
==28122==    at 0x4247E1: tr_isBandwidth (bandwidth.h:142)
==28122==    by 0x4249B0: allocateBandwidth (bandwidth.c:158)
==28122==    by 0x424BAB: allocateBandwidth (bandwidth.c:195)
==28122==    by 0x424E56: tr_bandwidthAllocate (bandwidth.c:250)
==28122==    by 0x432869: bandwidthPulse (peer-mgr.c:2466)
==28122==    by 0x41F177: timerCallback (trevent.c:303)
==28122==    by 0x44E7FE: event_base_loop (event.c:392)
==28122==    by 0x41EED7: libeventThreadFunc (trevent.c:238)
==28122==    by 0x40CA66: ThreadFunc (platform.c:106)
==28122==    by 0x3DD20073D9: start_thread (in /lib64/libpthread-2.9.so)
==28122==    by 0x3DD14E62BC: clone (in /lib64/libc-2.9.so)
==28122==  Address 0xa7979ec is 2,772 bytes inside a block of size 3,104 free'd
==28122==    at 0x4A0609F: free (vg_replace_malloc.c:323)
==28122==    by 0x42A867: tr_free (utils.h:302)
==28122==    by 0x42B619: io_dtor (peer-io.c:446)
==28122==    by 0x41F385: tr_runInEventThread (trevent.c:362)
==28122==    by 0x42B696: tr_peerIoFree (peer-io.c:458)
==28122==    by 0x42B7FF: tr_peerIoUnrefImpl (peer-io.c:482)
==28122==    by 0x443AE2: tr_handshakeFree (handshake.c:1116)
==28122==    by 0x443B96: tr_handshakeDone (handshake.c:1134)
==28122==    by 0x443BCB: tr_handshakeAbort (handshake.c:1142)
==28122==    by 0x443D38: handshakeTimeout (handshake.c:1183)
==28122==    by 0x41F177: timerCallback (trevent.c:303)
==28122==    by 0x44E7FE: event_base_loop (event.c:392)
==28122==    by 0x41EED7: libeventThreadFunc (trevent.c:238)
==28122==    by 0x40CA66: ThreadFunc (platform.c:106)
==28122==    by 0x3DD20073D9: start_thread (in /lib64/libpthread-2.9.so)
==28122==    by 0x3DD14E62BC: clone (in /lib64/libc-2.9.so)
==28122== 

[charles]

Short follow-up: I can't get this bug to re-trigger itself. Changing HANDSHAKE_TIMEOUT_MSEC from 60,000 down to 100 or so for testing might help flush this bug into the open.

The code for this looks correct. My first guess is that tr_bandwidthSetParent() isn't correctly removing the child from its parent's list of children, but I don't yet see the steps required to get to that point.

[charles]

I ran the daemon in valgrind over night and this still hasn't happened again... :/

[charles]

I've run the daemon inside of valgrind for a cumulative ~48 hours since then, and it hasn't happened again. The bug's still there, presumably, but it's nice to know that at least it's rare...

[charles]

I've now logged an additional ~48 hours of valgrind and this problem still hasn't appeared again.

[charles]

I've now clocked a full week's worth of valgrind time seeding various linux distros and this still hasn't reoccurred, and I don't see any problems in the code by inspection, either. I'm going to close this for now.