Opened 10 years ago

Closed 9 years ago

#4432 closed Bug (worksforme)

A segmentatioin fault happens in solaris when encryption is enabled

Reported by: cac2003 Owned by:
Priority: High Milestone: None Set
Component: Transmission Version: 2.33
Severity: Major Keywords:
Cc:

Description

Rencently I build transmission 2.33 in solaris 10 (x86) machine. Both the daemon and cmd client work fine when I set encryption to zero. However, when I enable encryption, the transmission process will report a segmentaion fault. There are two points at which the process crashes. The first one is listed as below:

=======================================================================

Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 3 (LWP 3)] 0xfef70b4f in evbuffer_add_buffer (outbuf=0x24, inbuf=0x80f33a0)

at buffer.c:817

817 EVBUFFER_LOCK2(inbuf, outbuf); (gdb) bt #0 0xfef70b4f in evbuffer_add_buffer (outbuf=0x24, inbuf=0x80f33a0)

at buffer.c:817

#1 0x08065bc6 in tr_peerIoWriteBuf (io=0x8159350, buf=0x80f33a0,

isPieceData=false) at peer-io.c:1065

#2 0x080941e1 in canRead (io=0x80f33a0, arg=0x8154b40, piece=0x80f33a0)

at handshake.c:490

#3 0x08064f13 in canReadWrapper (io=0x8159350) at peer-io.c:207 #4 0x080a4f6c in UTP_ProcessIncoming (conn=0x8159170,

packet=0xfe65de60 "\001", len=0, syn=false) at utp.cpp:2150

#5 0x080a6168 in UTP_IsIncomingUTP (incoming_proc=0x8073bbc <incoming>,

send_to_proc=0x8073c7c <tr_utpSendTo>, send_to_userdata=0x80c5cb8, buffer=0xfe65de60 "\001", len=244, to=0xfe65dd60, tolen=16) at utp.cpp:2579

#6 0x08073d9c in tr_utpPacket (buf=0xfe65de60 "\001", buflen=244,

from=0xfe65dd60, fromlen=16, ss=0x80c5cb8) at tr-utp.c:179

#7 0x08073630 in event_callback (s=18, type=2, sv=0x80c5cb8) at tr-udp.c:230

#8 0xfef6bf7c in event_base_loop (base=0x80c6108, flags=0) at event.c:1287

#9 0xfef6cc55 in event_base_dispatch (event_base=0x80c6108) at event.c:1382

#10 0x080746a9 in libeventThreadFunc (veh=0x80c5440) at trevent.c:248

#11 0x08066397 in ThreadFunc? (_t=0x80c4c18) at platform.c:118

#12 0xfeab7e66 in _thr_setup () from /usr/lib/libc.so.1

#13 0xfeab8150 in L3_doit () from /usr/lib/libc.so.1

#14 0xfe550200 in ?? ()

#15 0x00000000 in ?? ()

=======================================================================

Two questions can be raised from this backtrace: (1) the first parameter of the function "evbuffer_add_buffer" seems to have an invalid address (outbuf=0x24), and (2) the addresses of the first (io=0x80f33a0) and third parameters (piece=0x80f33a0) passed to the function "canRead" in handshake.c are the same, which puzzles me since these two parameters are pointers with different types. After I investigated the source code, I find that the first parameter passed to the function "canRead" must be the same as the parameter passed to the function "canReadWrapper" in which "canRead" is called. Hope my findings could help.

The transmission daemon may also crash when it executes the function "tr_peerIoSetEncryption" at peer-io.c:1025, as shown below: =================================================================

Program received signal SIGSEGV, Segmentation fault. [Switching to LWP 3] 0x08065ac1 in tr_peerIoSetEncryption (io=0xf40000,

encryption_type=PEER_ENCRYPTION_RC4) at peer-io.c:1025

1025 io->encryption_type = encryption_type;

0x08065ac1 in tr_peerIoSetEncryption (io=0xf40000,

encryption_type=PEER_ENCRYPTION_RC4) at peer-io.c:1025

1025 io->encryption_type = encryption_type; (gdb) bt #0 0x08065ac1 in tr_peerIoSetEncryption (io=0xf40000,

encryption_type=PEER_ENCRYPTION_RC4) at peer-io.c:1025

#1 0x0809415f in canRead (io=0xf40000, arg=0x81541f0, piece=0xf40000)

at handshake.c:469

#2 0x08064f13 in canReadWrapper (io=0x8153b90) at peer-io.c:207 #3 0x080a4f6c in UTP_ProcessIncoming (conn=0x81539b0,

packet=0xfe65de60 "\001", len=0, syn=false) at utp.cpp:2150

#4 0x080a6168 in UTP_IsIncomingUTP (incoming_proc=0x8073bbc <incoming>,

send_to_proc=0x8073c7c <tr_utpSendTo>, send_to_userdata=0x80c5cb8, buffer=0xfe65de60 "\001", len=313, to=0xfe65dd60, tolen=16) at utp.cpp:2579

#5 0x08073d9c in tr_utpPacket (buf=0xfe65de60 "\001", buflen=313,

from=0xfe65dd60, fromlen=16, ss=0x80c5cb8) at tr-utp.c:179

#6 0x08073630 in event_callback (s=18, type=2, sv=0x80c5cb8) at tr-udp.c:230

#7 0xfef6bf7c in event_base_loop (base=0x80c6108, flags=0) at event.c:1287

#8 0xfef6cc55 in event_base_dispatch (event_base=0x80c6108) at event.c:1382

#9 0x080746a9 in libeventThreadFunc (veh=0x80c5440) at trevent.c:248

#10 0x08066397 in ThreadFunc? (_t=0x80c4c18) at platform.c:118

#11 0xfeab7e66 in _thr_setup () from /usr/lib/libc.so.1

#12 0xfeab8150 in L3_doit () from /usr/lib/libc.so.1

#13 0xfe550200 in ?? ()

#14 0x00000000 in ?? ()

========================================================================== It seems that the problem also results from the parameters passed to the function "canRead" at handshake.c, as shown in #2 of the gdb backtrace.

Below are the results of "ldd transmission-daemon" =======================================================================

libevent-2.0.so.5 => /usr/local/lib/libevent-2.0.so.5

libsendfile.so.1 => /usr/lib/libsendfile.so.1

libcurl.so.4 => /usr/local/lib/libcurl.so.4

libidn.so.11 => /usr/local/lib/libidn.so.11

librt.so.1 => /usr/lib/librt.so.1

libssh2.so.1 => /usr/local/lib/libssh2.so.1

libssl.so.0.9.8 => /usr/local/ssl/lib/libssl.so.0.9.8

libcrypto.so.0.9.8 => /usr/local/ssl/lib/libcrypto.so.0.9.8

libdl.so.1 => /usr/lib/libdl.so.1

libintl.so.8 => /usr/local/lib/libintl.so.8

libiconv.so.2 => /usr/local/lib/libiconv.so.2

libsec.so.1 => /usr/lib/libsec.so.1

libc.so.1 => /usr/lib/libc.so.1

libz.so => /usr/lib/libz.so

libnsl.so.1 => /usr/lib/libnsl.so.1

libsocket.so.1 => /usr/lib/libsocket.so.1

libm.so.2 => /usr/lib/libm.so.2

libpthread.so.1 => /usr/lib/libpthread.so.1

libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1

libssl.so.1.0.0 => /usr/local/ssl/lib/libssl.so.1.0.0

libcrypto.so.1.0.0 => /usr/local/ssl/lib/libcrypto.so.1.0.0

libaio.so.1 => /usr/lib/libaio.so.1

libmd.so.1 => /usr/lib/libmd.so.1

libavl.so.1 => /usr/lib/libavl.so.1

libmp.so.2 => /usr/lib/libmp.so.2

libscf.so.1 => /usr/lib/libscf.so.1

libdoor.so.1 => /usr/lib/libdoor.so.1

libuutil.so.1 => /usr/lib/libuutil.so.1

libgen.so.1 => /usr/lib/libgen.so.1

===============================================================

Attachments (1)

backtrace.jpg (85.3 KB) - added by cac2003 10 years ago.

Download all attachments as: .zip

Change History (8)

Changed 10 years ago by cac2003

comment:1 Changed 10 years ago by cac2003

any idea?

comment:2 follow-up: Changed 10 years ago by jordan

One thing I'm seeing is that the line numbers don't match Transmission 2.33's line numbers. Your debugger says that tr_peerIoWriteBuf() calls evbuffer_add_buffer() from peer-io.c:1065, but in Transmission 2.33 that happens on line 1057 -- tr_peerIoWriteBytes() is on line 1065.

Are you sure you're debugging the correct build?

comment:3 in reply to: ↑ 2 Changed 10 years ago by cac2003

Replying to jordan:

One thing I'm seeing is that the line numbers don't match Transmission 2.33's line numbers. Your debugger says that tr_peerIoWriteBuf() calls evbuffer_add_buffer() from peer-io.c:1065, but in Transmission 2.33 that happens on line 1057 -- tr_peerIoWriteBytes() is on line 1065.

Are you sure you're debugging the correct build?

Thanks for reply. I was using the right build. At first I want to solve this problem by myself, so I add some print statements to see what's going on. That's why there is a difference between our backtraces.

comment:4 Changed 10 years ago by jordan

It's odd that you're able to get this so consistently but nobody else is reporting it. What version of libevent are you running? Do encrypted connections crash for you on other platforms?

comment:5 Changed 10 years ago by cac2003

I am using libevent-2.0.10-stable. I also run Transmission in Ubuntu 11.04, and it works fine on that platform. For your reference, this problem has already been raised in ticket 3812; the corresponding link is https://trac.transmissionbt.com/ticket/3812. The reporter of this ticket also found that the segmentation fault only occurs when encryption is enabled, and avoided this situation by setting io->encryptionMode to 0. However, as my ISP may block the plain BT connection, it is necessargy for me to enable the encryption.

comment:6 Changed 9 years ago by livings124

cac2003: Are you still seeing this with a currently nightly?

comment:7 Changed 9 years ago by livings124

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

I'm going to close this. I suspect it was a local issue. Please reopen if this is still an issue with a current release.

Note: See TracTickets for help on using tickets.