Opened 10 years ago

Closed 10 years ago

#4429 closed Bug (duplicate)

A segmentatioin fault happens in solaris when encryption is enabled

Reported by: cac2003 Owned by:
Priority: Normal Milestone: None Set
Component: Transmission Version: 2.33
Severity: Critical Keywords:


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. The GDB backtrace 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/

#13 0xfeab8150 in L3_doit () from /usr/lib/

#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.

Below are the results of "ldd transmission-daemon" ======================================================================= => /usr/local/lib/ => /usr/lib/ => /usr/local/lib/ => /usr/local/lib/ => /usr/lib/ => /usr/local/lib/ => /usr/local/ssl/lib/ => /usr/local/ssl/lib/ => /usr/lib/ => /usr/local/lib/ => /usr/local/lib/ => /usr/lib/ => /usr/lib/ => /usr/lib/ => /usr/lib/ => /usr/lib/ => /usr/lib/ => /usr/lib/ => /usr/local/lib/ => /usr/local/ssl/lib/ => /usr/local/ssl/lib/ => /usr/lib/ => /usr/lib/ => /usr/lib/ => /usr/lib/ => /usr/lib/ => /usr/lib/ => /usr/lib/ => /usr/lib/


Change History (1)

comment:1 Changed 10 years ago by jordan

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

This is a duplicate of #4432

Note: See TracTickets for help on using tickets.