Opened 12 years ago

Closed 12 years ago

#1776 closed Bug (fixed)

crash in tr_cryptoComputeSecret()

Reported by: gnu Owned by: charles
Priority: High Milestone: 1.50
Component: Transmission Version: 1.42
Severity: Major Keywords: coredump
Cc:

Description

I'm running 1.50b3 (7776) on Ubuntu Hardy, using the GTK+ GUI, on a T1 line, with 24 ipv4 torrents seeding, and one or two IPv6 torrents downloading or seeding.

I left it running overnight and when I came back it had dumped core. After an hour of pain pulling in debug symbols, gdb tells me it core dumped in memcpy as called from tr_cryptoComputeSecret. Full backtrace attached.

My system is running slightly back-rev Hardy versions of a few libraries (which is why I can't get debug symbols for them). I could upgrade to the latest ones, of course, but then this core dump would become unreadable because the libraries it linked with would have changed.

I'd seen the 1.50b1 version also crashing earlier, but didn't get a core file the first few times. When I eventually did set up to get a core file, I was then advised to run 1.50b3. I upgraded to 1.50b3 and this, of course, wiped out the executable of 1.50b1 that would be needed to debug the previous core file. So I can't tell if this is the same bug as in 1.50b1.

Attachments (1)

transmission-core-typescript (17.9 KB) - added by gnu 12 years ago.
Terminal output from running GDB on transmission's core-pse.

Download all attachments as: .zip

Change History (12)

Changed 12 years ago by gnu

Terminal output from running GDB on transmission's core-pse.

comment:1 Changed 12 years ago by charles

money shot:

294 	(gdb) bt
295 	#0  0xb77149bc in memcpy () from /lib/tls/i686/cmov/libc.so.6
296 	#1  0x0809f092 in tr_cryptoComputeSecret ()
297 	#2  0x080bab7d in ?? ()
298 	#3  0x080bb95d in ?? ()
299 	#4  0x080a2b9d in ?? ()
300 	#5  0x080a2f21 in ?? ()
301 	#6  0x080bdb63 in event_base_loop ()
302 	#7  0x080bde8a in event_loop ()
303 	#8  0x080bdea2 in event_dispatch ()
304 	#9  0x08098619 in ?? ()
305 	#10 0x08087653 in ?? ()

code:

    int      len, offset;
    uint8_t  secret[KEY_LEN];
    BIGNUM * bn = BN_bin2bn( peerPublicKey, KEY_LEN, NULL );
    DH *     dh = getSharedDH( );

    assert( DH_size( dh ) == KEY_LEN );

    len = DH_compute_key( secret, bn, dh );
    assert( len <= KEY_LEN );
    offset = KEY_LEN - len;
    memset( crypto->mySecret, 0, offset );
    memcpy( crypto->mySecret + offset, secret, len );
    crypto->mySecretIsSet = 1;

    BN_free( bn );

    return crypto->mySecret;

comment:2 Changed 12 years ago by gnu

After upgrading the libraries used by Transmission, and running the nightly deb, it ran for 24 hours under gdb without crashing and without log messages. Then I shut it down cleanly, upgraded the rest of the debs on the machine, rebooted, got the latest nightly, and restarted it -- two hours later, without incident so far. Will keep testing, and report back if it crashes again.

comment:3 Changed 12 years ago by charles

  • Resolution set to invalid
  • Status changed from new to closed

Since nobody else is reporting this error, and it seems to have been cleared up after the library upgrades on your machine, this smells like a configuration error.

I'm going to close the ticket as "invalid" for now but please reopen if more information becomes available.

Thanks for taking the time to report issue to make Transmission a better program.

comment:4 Changed 12 years ago by gnu

After another day, it's stll running. It produced two messages I hadn't seen before, on stdout or stderr:

index 135 offset 409600 length 3687459277 err 3

index 7139 offset 3131452911 length 1879243769 err 3

Otherwise, the nightly (svn 7821) appears to be running fine.

I don't know how it could be called a "configuration error" -- but perhaps it was a bug, recently rectified, in one of the many packages Transmission uses.

comment:5 Changed 12 years ago by gnu

  • Priority changed from Normal to High
  • Resolution invalid deleted
  • Status changed from closed to reopened

It crashed again for me. Here's the backtrace:

Program received signal SIGSEGV, Segmentation fault.

[Switching to Thread 0xb5ddeb90 (LWP 6961)]

0xb77699bc in memcpy () from /lib/tls/i686/cmov/libc.so.6

(gdb) bt

#0 0xb77699bc in memcpy () from /lib/tls/i686/cmov/libc.so.6

#1 0x080a0f9e in tr_cryptoComputeSecret (crypto=0x92815c0,

peerPublicKey=0xb5dde030 '�' <repeats 96 times>) at crypto.c:165

#2 0x080bd22c in readYa (handshake=0x8bccc50, inbuf=0x92835b8)

at handshake.c:751

#3 0x080be00c in canRead (io=0x8d64ef8, arg=0x8bccc50, piece=0xb5dde10c)

at handshake.c:1033

#4 0x080a4b81 in canReadWrapper (io=0x8d64ef8) at peer-io.c:132

#5 0x080a6876 in tr_peerIoTryRead (io=0x8d64ef8, howmuch=1024)

at peer-io.c:786

#6 0x080a6b2e in tr_peerIoFlush (io=0x8d64ef8, dir=TR_PEER_TO_CLIENT,

limit=1024) at peer-io.c:838

#7 0x0809e9d1 in tr_bandwidthAllocate (b=0x81d6490, dir=TR_PEER_TO_CLIENT,

period_msec=500) at bandwidth.c:221

#8 0x080aca82 in bandwidthPulse (vmgr=0x81d7aa0) at peer-mgr.c:2369

#9 0x0809a1ff in timerCallback (fd=-1, event=1, vtimer=0x81d7ab8)

at trevent.c:315

#10 0x080c0243 in event_base_loop (base=0x81d8810, flags=0) at event.c:392

#11 0x080c056a in event_loop (flags=0) at event.c:468

#12 0x080c0582 in event_dispatch () at event.c:406

#13 0x08099f72 in libeventThreadFunc (veh=0x81d7920) at trevent.c:251

#14 0x0808772f in ThreadFunc? (_t=0x81d79b0) at platform.c:106

#15 0xb784a4fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0

---Type <return> to continue, or q <return> to quit---

#16 0xb77cce5e in clone () from /lib/tls/i686/cmov/libc.so.6

(gdb) up

#1 0x080a0f9e in tr_cryptoComputeSecret (crypto=0x92815c0,

peerPublicKey=0xb5dde030 '�' <repeats 96 times>) at crypto.c:165

165 crypto.c: No such file or directory.

in crypto.c

(gdb) print *crypto

$1 = {dec_key = {x = 0, y = 0, data = {0 <repeats 256 times>}}, enc_key = {

x = 0, y = 0, data = {0 <repeats 256 times>}},

torrentHash = '\0' <repeats 19 times>, isIncoming = 1 '\001', torrentHashIsSet = 0 '\0', mySecretIsSet = 0 '\0', myPublicKey = "���\227���e�0((�\001\t��\020�\n\003(�\004xQH��=\n�\021\235\210��\205\212�v0��Yi�\236�\226ɸ\004\036\001}D�\0335\223M�\204\206���p|\237�\000.�A�O��4�\006\035����AR�\025|\a,\004", mySecret = '\0' <repeats 95 times>}

(gdb) p len

$2 = -1

(gdb) p offset

$3 = 97

I poked at the process (which is still hung for further debugging, if you like), and the problem appears to be that "len", the result from DH_compute_key, is -1. The code does not check for this. I'm running the nightly from svn 7821.

There is no "apt-get source transmission" for the nightly debs, so I don't have the corresponding source code. I'll see if I can pull it from SVN.

comment:6 Changed 12 years ago by charles

  • Milestone changed from None Set to 1.50
  • Summary changed from transmission (GTK) coredump to crash in tr_cryptoComputeSecret()
  • Version changed from 1.42+ to 1.42

comment:7 Changed 12 years ago by charles

Fixed in trunk in r7862

comment:8 Changed 12 years ago by charles

  • Resolution set to fixed
  • Status changed from reopened to closed

Fixed in 1.5x branch in r7863

comment:9 Changed 12 years ago by charles

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:10 Changed 12 years ago by charles

  • Owner set to charles
  • Status changed from reopened to new

comment:11 Changed 12 years ago by charles

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.