# rtorrent-devel-0.9.3_2 segmentation fault



## manas (Feb 27, 2014)

Hello,

I am running FreeBSD 10.0-RELEASE. I am running into a segmentation fault with rtorrent-devel-0.9.3_2.
The segmentation fault happens when trying to load torrents. To reproduce, press <backspace> and press <tab> twice once.
At the recommendation from a friend, I built rtorrent with debugging symbols and put it through gdb. (this is my first use of gdb)
The segmentation fault happens at gthr-default.h line 199 which is a gcc46 file.


```
#0  0x00000000004bb272 in display::WindowStringList::set_range (this=0x0, first={_M_node = 0x80beff8e0}, last={_M_node = 0x805d3c7e8}) at gthr-default.h:199
#1  0x00000000004bb8d8 in ui::ElementStringList::set_range_dirent<__gnu_cxx::__normal_iterator<utils::directory_entry*, std::vector<utils::directory_entry, std::allocator<utils::directory_entry> > > > (this=0x805d3c780, first={_M_current = 0x8083c7368}, last={_M_current = 0x8083c7368}) at download_list.cc:76
#2  0x00000000004befbe in sigc::bound_mem_functor2<void, ui::ElementStringList, __gnu_cxx::__normal_iterator<utils::directory_entry*, std::vector<utils::directory_entry, std::allocator<utils::directory_entry> > >, __gnu_cxx::__normal_iterator<utils::directory_entry*, std::vector<utils::directory_entry, std::allocator<utils::directory_entry> > > >::operator() (
    this=0x80bf1dc78, _A_a1=@0x7fffffffd400, _A_a2=@0x7fffffffd408) at download_list.cc:76
#3  0x00000000004bea4f in sigc::adaptor_functor<sigc::bound_mem_functor2<void, ui::ElementStringList, __gnu_cxx::__normal_iterator<utils::directory_entry*, std::vector<utils::directory_entry, std::allocator<utils::directory_entry> > >, __gnu_cxx::__normal_iterator<utils::directory_entry*, std::vector<utils::directory_entry, std::allocator<utils::directory_entry> > > > >::operator()<__gnu_cxx::__normal_iterator<utils::directory_entry*, std::vector<utils::directory_entry, std::allocator<utils::directory_entry> > > const&, __gnu_cxx::__normal_iterator<utils::directory_entry*, std::vector<utils::directory_entry, std::allocator<utils::directory_entry> > > const&> (this=0x80bf1dc70, _A_arg1=@0x7fffffffd400,
    _A_arg2=@0x7fffffffd408) at download_list.cc:76
#4  0x00000000004be20c in sigc::internal::slot_call2<sigc::bound_mem_functor2<void, ui::ElementStringList, __gnu_cxx::__normal_iterator<utils::directory_entry*, std::vector<utils::directory_entry, std::allocator<utils::directory_entry> > >, __gnu_cxx::__normal_iterator<utils::directory_entry*, std::vector<utils::directory_entry, std::allocator<utils::directory_entry> > > >, void, __gnu_cxx::__normal_iterator<utils::directory_entry*, std::vector<utils::directory_entry, std::allocator<utils::directory_entry> > >, __gnu_cxx::__normal_iterator<utils::directory_entry*, std::vector<utils::directory_entry, std::allocator<utils::directory_entry> > > >::call_it (rep=0x80bf1dc40, a_1=@0x7fffffffd400, a_2=@0x7fffffffd408)
    at download_list.cc:76
#5  0x0000000000527a55 in sigc::internal::signal_emit2<void, __gnu_cxx::__normal_iterator<utils::directory_entry*, std::vector<utils::directory_entry, std::allocator<utils::directory_entry> > >, __gnu_cxx::__normal_iterator<utils::directory_entry*, std::vector<utils::directory_entry, std::allocator<utils::directory_entry> > >, sigc::nil>::emit (impl=0x80befdac0,
    _A_a1=@0x7fffffffd400, _A_a2=@0x7fffffffd408) at path_input.cc:58
#6  0x00000000005276bb in sigc::signal2<void, __gnu_cxx::__normal_iterator<utils::directory_entry*, std::vector<utils::directory_entry, std::allocator<utils::directory_entry> > >, __gnu_cxx::__normal_iterator<utils::directory_entry*, std::vector<utils::directory_entry, std::allocator<utils::directory_entry> > >, sigc::nil>::emit (this=0x80c559dc0,
    _A_a1=@0x7fffffffd400, _A_a2=@0x7fffffffd408) at path_input.cc:58
#7  0x0000000000526e16 in input::PathInput::receive_do_complete (this=0x80c559d40) at path_input.cc:58
#8  0x0000000000526b2a in input::PathInput::pressed (this=0x80c559d40, key=9) at path_input.cc:58
#9  0x0000000000525e8d in input::Manager::pressed (this=0x805c830c0, key=9) at manager.cc:59
#10 0x000000000046db31 in sigc::bound_mem_functor1<void, input::Manager, int>::operator() (this=0x805c174f8, _A_a1=@0x7fffffffd5ec) at typeinfo:127
#11 0x000000000046d755 in sigc::adaptor_functor<sigc::bound_mem_functor1<void, input::Manager, int> >::operator()<int const&> (this=0x805c174f0, _A_arg1=@0x7fffffffd5ec)
    at typeinfo:127
#12 0x000000000046cff6 in sigc::internal::slot_call1<sigc::bound_mem_functor1<void, input::Manager, int>, void, int>::call_it (rep=0x805c174c0, a_1=@0x7fffffffd5ec) at typeinfo:127
#13 0x0000000000525c7b in sigc::slot1<void, int>::operator() (this=0x805c830f0, _A_a1=@0x7fffffffd5ec) at slot_base.h:273
#14 0x0000000000525bdf in input::InputEvent::event_read (this=0x805c830e0) at slot_base.h:273
#15 0x0000000803045bdf in torrent::PollKQueue::perform () from /usr/local/lib/libtorrent.so.17
#16 0x0000000000000000 in ?? ()
```

Is this something I can fix by changing rtorrent's source and recompiling?

Thanks,
Manas


----------



## trh411 (Feb 27, 2014)

If you have the programming and debugging skills to do it, sure. If you fix the defect, provide a patch and submit it to the ports team. From what I see, this port has no maintainer. You could even take over maintenance of the port if you are so inclined.


----------



## manas (Feb 27, 2014)

Yeah, don't know if I have the skills to fix it. No harm trying, I guess.

From frame 0, the problem seems to happen in a function called set_range. It is defined in 
display/window_string_list.h on line 56

```
void             set_range(iterator first, iterator last) { m_first = m_drawEnd = first; m_last = last; }
```

Going to poke some more after I understand what is going on here. (I apologize for any misuse of terminology, I am not a computer scientist)

*Has something changed with the way FreeBSD responds to requests for list of files in a directory? My intuition is no because such a change would have serious effects. Rtorrent might just need to be adjusted to FreeBSD's methods.


----------



## trh411 (Feb 27, 2014)

You might want to compare (i.e., diff(1)) net-p2p/rtorrrent-devel  against net-p2p/rtorrent, and then focus on those files/programs in which there are differences. Seeing the differences in the code and/or headers might reveal something instructive.


----------



## trh411 (Feb 27, 2014)

I tried to find details of the changes from net-p2p/rtorrent 0.9.2 to net-p2p/rtorrent-devel 0.9.3, but the Changelog Wiki has not been updated in 3 years. Thought that might offer a shortcut.


----------



## manas (Feb 28, 2014)

trh411 said:
			
		

> I tried to find details of the changes from net-p2p/rtorrent 0.9.2 to net-p2p/rtorrent-devel 0.9.3, but the Changelog Wiki has not been updated in 3 years. Thought that might offer a shortcut.



I think I tried net-p2p/rtorrent, it also had the same error.


----------



## mix_room (Feb 28, 2014)

I'm using 9.2-RELEASE and rtorrent 0.9.2, I can not reproduce the error. Mine is stable. However, it seems as though only the first <tab> actually changes anything.


----------



## trh411 (Feb 28, 2014)

manas said:
			
		

> I think I tried net-p2p/rtorrent, it also had the same error.


I have not used it recently, but I did not have any issues using net-p2p/rtorrent on FreeBSD-10.0-RELEASE. I'm now on -CURRENT and have not had a reason to use net-p2p/rtorrent recently. Maybe it's worth a shot to try net-p2p/rtorrent just to make sure it does not work for you. I'll also give it a try later today and report back.


----------



## manas (Feb 28, 2014)

mix_room said:
			
		

> I'm using 9.2-RELEASE and rtorrent 0.9.2, I can not reproduce the error. Mine is stable. However, it seems as though only the first <tab> actually changes anything.



I am running rtorrent-devel on FreeBSD 9.2-RELEASE and have no issues at all there. rtorrent-devel causes problems on FreeBSD 10.0-RELEASE.
You are right about the number of <tab>s, the segmentation fault happens after the first press.

I tried net-p2p/rtorrent and it also produces the same problem.

```
Caught Segmentation fault, dumping stack:
Stack dump not enabled.
fish: Job 1, “rtorrent” terminated by signal SIGABRT (Abort)
```

I made a github post on the rtorrent page, rakshasa closed it so it may be fixed in the git code. (https://github.com/rakshasa/rtorrent/issues/177)

When I try to compile the code from github on FreeBSD 10.0-RELEASE, it is not successful.
I cloned both the libtorrent and rtorrent code. I tried to compile libtorrent first
The ouput from `./autogen.sh` is:

```
aclocal...
configure.ac:22: warning: macro 'AM_PATH_CPPUNIT' not found in library
autoheader...
libtoolize... using libtoolize
automake...
autoconf...
configure.ac:22: error: possibly undefined macro: AM_PATH_CPPUNIT
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
```

A configure file is created anyways, running that gives:

```
./configure: 11844: Syntax error: word unexpected (expecting ")")
```
configure contains at line 11844

```
AM_PATH_CPPUNIT(1.9.6)
```

So still working on it.

*UPDATE*
I had to install the devel/cppunit port. `autogen.sh` runs correctly now.

*UPDATE*
I get a colorful error when trying to `make`

```
In file included from block.cc:44:
In file included from ./../../protocol/peer_connection_base.h:42:
./../../torrent/poll.h:49:16: error: no member named 'tr1' in namespace 'std'
  typedef std::tr1::function<Poll* ()> slot_poll;
          ~~~~~^
./../../torrent/poll.h:49:29: error: expected member name or ';' after declaration specifiers
  typedef std::tr1::function<Poll* ()> slot_poll;
  ~~~~~~~~~~~~~~~~~~~~~~~~~~^
./../../torrent/poll.h:94:10: error: unknown type name 'slot_poll'
  static slot_poll&   slot_create_poll() { return m_slot_create_poll; }
         ^
./../../torrent/poll.h:97:10: error: unknown type name 'slot_poll'
  static slot_poll    m_slot_create_poll;
         ^
In file included from block.cc:44:
In file included from ./../../protocol/peer_connection_base.h:47:
In file included from ./../../protocol/extensions.h:47:
./../../torrent/download_info.h:57:16: error: no member named 'tr1' in namespace 'std'
  typedef std::tr1::function<uint64_t ()>                              slot_stat_type;
          ~~~~~^
./../../torrent/download_info.h:57:29: error: expected member name or ';' after declaration specifiers
  typedef std::tr1::function<uint64_t ()>                              slot_stat_type;
  ~~~~~~~~~~~~~~~~~~~~~~~~~~^
./../../torrent/download_info.h:59:26: error: no member named 'tr1' in namespace 'std'
  typedef std::list<std::tr1::function<void ()> >                      signal_void_type;
                    ~~~~~^
./../../torrent/download_info.h:59:49: error: expected member name or ';' after declaration specifiers
  typedef std::list<std::tr1::function<void ()> >                      signal_void_type;
  ~~~~~~~                                       ^
./../../torrent/download_info.h:60:26: error: no member named 'tr1' in namespace 'std'
  typedef std::list<std::tr1::function<void (const std::string&)> >    signal_string_type;
                    ~~~~~^
./../../torrent/download_info.h:60:46: error: expected expression
  typedef std::list<std::tr1::function<void (const std::string&)> >    signal_string_type;
                                             ^
./../../torrent/download_info.h:60:67: error: expected member name or ';' after declaration specifiers
  typedef std::list<std::tr1::function<void (const std::string&)> >    signal_string_type;
  ~~~~~~~                                                         ^
./../../torrent/download_info.h:159:3: error: unknown type name 'signal_void_type'
  signal_void_type&   signal_tracker_success() const               { return m_signalTrackerSuccess; }
  ^
./../../torrent/download_info.h:160:3: error: unknown type name 'signal_string_type'
  signal_string_type& signal_tracker_failed() const                { return m_signalTrackerFailed; }
  ^
./../../torrent/download_info.h:171:3: error: unknown type name 'slot_stat_type'
  slot_stat_type&     slot_left()                                  { return m_slotStatLeft; }
  ^
./../../torrent/download_info.h:172:3: error: unknown type name 'slot_stat_type'
  slot_stat_type&     slot_completed()                             { return m_slotStatCompleted; }
  ^
./../../torrent/download_info.h:198:3: error: unknown type name 'slot_stat_type'
  slot_stat_type      m_slotStatLeft;
  ^
./../../torrent/download_info.h:199:3: error: unknown type name 'slot_stat_type'
  slot_stat_type      m_slotStatCompleted;
  ^
./../../torrent/download_info.h:201:11: error: unknown type name 'signal_void_type'
  mutable signal_void_type    m_signalTrackerSuccess;
          ^
./../../torrent/download_info.h:202:11: error: unknown type name 'signal_string_type'
  mutable signal_string_type  m_signalTrackerFailed;
          ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
*** Error code 1

Stop.
make[4]: stopped in /root/src/libtorrent/src/torrent/data
*** Error code 1

Stop.
make[3]: stopped in /root/src/libtorrent/src/torrent
*** Error code 1

Stop.
make[2]: stopped in /root/src/libtorrent/src
*** Error code 1

Stop.
make[1]: stopped in /root/src/libtorrent
*** Error code 1

Stop.
make: stopped in /root/src/libtorrent
```

*UPDATE*
If I install net-p2p/libtorrent-devel from ports and then try to compile rtorrent from git source after setting `setenv CC gcc46` & `setenv CXX c++46` I encounter (have to use alternate compilers, clang fails with the colorful error above):

```
In file included from path_input.cc:51:0:
/usr/include/sys/dir.h:39:2: warning: #warning "The information in this file should be obtained from <dirent.h>" [-Wcpp]
/usr/include/sys/dir.h:40:2: warning: #warning "and is provided solely (and temporarily) for backward compatibility." [-Wcpp]
path_input.cc: In member function 'void input::PathInput::receive_do_complete()':
path_input.cc:94:3: error: 'LOG_UI_EVENTS' is not a member of 'torrent'
path_input.cc:94:3: error: 'LOG_UI_EVENTS' is not a member of 'torrent'
path_input.cc:129:5: error: 'LOG_UI_EVENTS' is not a member of 'torrent'
path_input.cc:129:5: error: 'LOG_UI_EVENTS' is not a member of 'torrent'
*** Error code 1

Stop.
make[3]: stopped in /root/src/rtorrent/src/input
*** Error code 1

Stop.
make[2]: stopped in /root/src/rtorrent/src
*** Error code 1

Stop.
make[1]: stopped in /root/src/rtorrent
*** Error code 1

Stop.
make: stopped in /root/src/rtorrent
```

*UPDATE*
I thought I would try compiling libtorrent with the alternate compilers. This is the result:

```
In file included from ./../../torrent/connection_manager.h:46:0,
                 from option_strings.cc:43:
/usr/include/netinet/in_systm.h:49:9: error: 'u_int16_t' does not name a type
/usr/include/netinet/in_systm.h:50:9: error: 'u_int32_t' does not name a type
/usr/include/netinet/in_systm.h:52:9: error: 'u_int32_t' does not name a type
In file included from ./../../torrent/connection_manager.h:47:0,
                 from option_strings.cc:43:
/usr/include/netinet/ip.h:51:2: error: 'u_char' does not name a type
/usr/include/netinet/ip.h:58:2: error: 'u_char' does not name a type
/usr/include/netinet/ip.h:59:2: error: 'u_short' does not name a type
/usr/include/netinet/ip.h:60:2: error: 'u_short' does not name a type
/usr/include/netinet/ip.h:61:2: error: 'u_short' does not name a type
/usr/include/netinet/ip.h:66:2: error: 'u_char' does not name a type
/usr/include/netinet/ip.h:67:2: error: 'u_char' does not name a type
/usr/include/netinet/ip.h:68:2: error: 'u_short' does not name a type
/usr/include/netinet/ip.h:166:2: error: 'u_char' does not name a type
/usr/include/netinet/ip.h:167:2: error: 'u_char' does not name a type
/usr/include/netinet/ip.h:168:2: error: 'u_char' does not name a type
/usr/include/netinet/ip.h:170:2: error: 'u_char' does not name a type
/usr/include/netinet/ip.h:217:2: error: 'u_char' does not name a type
/usr/include/netinet/ip.h:218:2: error: 'u_char' does not name a type
/usr/include/netinet/ip.h:219:2: error: 'u_short' does not name a type
*** Error code 1

Stop.
make[4]: stopped in /root/src/libtorrent/src/torrent/utils
*** Error code 1

Stop.
make[3]: stopped in /root/src/libtorrent/src/torrent
*** Error code 1

Stop.
make[2]: stopped in /root/src/libtorrent/src
*** Error code 1

Stop.
make[1]: stopped in /root/src/libtorrent
*** Error code 1

Stop.
make: stopped in /root/src/libtorrent
```


----------



## manas (Mar 5, 2014)

Is there a way to find out what had to be changed to a software package such as rtorrent to make it work with FreeBSD?


----------



## trh411 (Mar 6, 2014)

manas said:
			
		

> Is there a way to find out what had to be changed to a software package such as rtorrent to make it work with FreeBSD?


Any changes required should be in the form of patch files in /usr/ports/net-p2p/rtorrent/files.


----------



## manas (Mar 6, 2014)

trh411 said:
			
		

> manas said:
> 
> 
> 
> ...




I will read through that, thanks.

I went on the rtorrent IRC channel and got told that "FreeBSD is not for doing things with, it is for looking at".


----------



## kpa (Mar 6, 2014)

manas said:
			
		

> trh411 said:
> 
> 
> 
> ...



Well if that's true then why does net-p2p/transmission work perfectly on FreeBSD and the author of net-p2p/rtorrent can not get his act together with FreeBSD compatibility of his software?


----------



## manas (Mar 6, 2014)

Yeah, exactly. I didn't believe their message for even a second.
I can compile software like ffmpeg straight from git without any modification whatsoever, I am sure the same can be done for other software.


----------



## kommissar (Mar 16, 2014)

I think I tracked this down. See the bug I filed: https://github.com/rakshasa/rtorrent/issues/181

I'm not positive, but it looks like a recent commit added some NULL checking around this area:
https://github.com/rakshasa/rtorrent/co ... 32fb64c5e3

Perhaps it's already fixed. I hope that rakshasa actually responds instead of simply closing the issue, but who knows.


----------



## manas (Jul 16, 2014)

Looks like it did get fixed by rakshasa. I have moved over to transmission-daemon so I have not had the opportunity to test out the change.


----------



## marvel (Jul 17, 2015)

Hi guys sorry for hijacking this topic but since the last couple of days I have a similar issue. I've been running rtorrent/rutorrent for more than a year now and it's very stable, it probably crashed only once every few months but right now, since I fully updated my system and packages, and gave my server a restart I can't run rtorrent for much longer than a few hours, but usually only 15 - 20 minutes.

Log only shows this:


```
pid 42936 (rtorrent), uid 1001: exited on signal 6
pid 90326 (rtorrent), uid 1001: exited on signal 6
pid 90654 (rtorrent), uid 1001: exited on signal 6
pid 36624 (rtorrent), uid 1001: exited on signal 6
pid 38618 (rtorrent), uid 1001: exited on signal 6
pid 39145 (rtorrent), uid 1001: exited on signal 6 (core dumped)
```

GDB output from the last crash says this:


```
#0  0x00000008026dc6ca in thr_kill () from /lib/libc.so.7
#1  0x00000008027b1179 in abort () from /lib/libc.so.7
#2  0x00000000004148e1 in ?? ()
#3  0x0000000801b4647a in swapcontext () from /lib/libthr.so.3
#4  0x0000000801b46062 in sigaction () from /lib/libthr.so.3
#5  <signal handler called>
#6  0x00000008036304b8 in sha1_block_data_order () from /lib/libcrypto.so.7
#7  0x116d5e9ea7ab0706 in ?? ()
#8  0xcf96675ca98e45d5 in ?? ()
#9  0xbbc256aa1fbf86d9 in ?? ()
#10 0xbdb7b6326bd67291 in ?? ()
#11 0x26ff0e721d74a3a2 in ?? ()
#12 0x186b598043072ca7 in ?? ()
#13 0x4ab64a8edd182dda in ?? ()
#14 0xdb65744e0f95f105 in ?? ()
#15 0x00007fffffffe680 in ?? ()
#16 0x00007fffffffe670 in ?? ()
#17 0x0000000003ffffff in ?? ()
#18 0x0000000803628c1b in SHA1_Update () from /lib/libcrypto.so.7
```

I've been trying everything, re-did my entire .rtorrent.rc, rebuilt curl with c-ares support like some suggested, compiled rtorrent from scratch but no go, keeps crashing even with a few small torrents active.

Any idea where to start looking? It's driving me nuts.

Thanks.

Before I forget, I run FreeBSD 10.1 AMD64, latest updates so system and packages.


----------



## marvel (Jul 18, 2015)

Just replying to myself seems like I solved the issue by changing the session directory to another folder. Weird but it works.


----------

