core dump after moving to smb share

[ghost]

rtorrent core dumped after hashing and moving to smb share (plugin autotools from rutorrent project http://code.google.com/p/rutorrent/ , http://code.google.com/p/rutorrent/wiki/PluginAutotools#Auto_Move)

System
9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:15:25 UTC 2012 root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386

Configuration

cat .rtorrent.rc

ip = 127.0.0.1
port_random = yes
scgi_port=127.0.0.1:5000
encryption = require
directory =/usr/home/tor/download/incomplete
session = /usr/home/tor/download/session
max_memory_usage=512M

Mount Share

mount

/dev/da0p2 on / (ufs, local, journaled soft-updates)
devfs on /dev (devfs, local, multilabel)
//TORRENT@server07/VIDEO on /usr/home/tor/download/complete (smbfs)

Installed from ports

libtorrent-0.12.9 = up-to-date with port
rtorrent-0.8.9_1 = up-to-date with port

gdb output

[Throttle 102400/102400 KB] [Rate 0.0/ 0.0 KB] [Port: 6939] [Local 127.0.0.1
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 28804300 (LWP 100099/rtorrent)]
0x284cb0f3 in SHA1_Init () from /lib/libcrypto.so.6
(gdb) bt
#0 0x284cb0f3 in SHA1_Init () from /lib/libcrypto.so.6
#1 0x284cd06e in SHA1_Update () from /lib/libcrypto.so.6
#2 0x2834d208 in torrent::HashChunk::perform_part ()

from /usr/local/lib/libtorrent.so.14
#3 0x2834d354 in torrent::HashChunk::perform ()

from /usr/local/lib/libtorrent.so.14
#4 0x2834da1b in torrent::HashQueue::check ()

from /usr/local/lib/libtorrent.so.14
#5 0x2834dd83 in torrent::HashQueue::work ()

from /usr/local/lib/libtorrent.so.14
#6 0x2834e83b in rak::mem_fn0_t<torrent::HashQueue, void>::operator() ()

from /usr/local/lib/libtorrent.so.14
#7 0x28321f39 in torrent::perform () from /usr/local/lib/libtorrent.so.14
#8 0x08117100 in std::vector<std::string, std::allocatorstd::string >::insert ()
#9 0x0805978c in ?? ()
#10 0x08053f67 in ?? ()
#11 0x00000004 in ?? ()
#12 0xbfbfec6c in ?? ()
#13 0xbfbfec80 in ?? ()
#14 0xbfbfec50 in ?? ()
#15 0xbfbfec68 in ?? ()
#16 0x00000000 in ?? ()
#17 0xbfbfec64 in ?? ()
#18 0x08053ed8 in ?? ()

Previous frame inner to this frame (corrupt stack?)

Thank you very much.
Vital.

[rakshasa]

Compile with --enable-debug for both lib and client, run under gdb and use 'bt' when it crashes (SIGSEGV, not SIGPIPE or something else that should be set to ignore) to get a proper backtrace.

[ghost]

Sorry, but I'm not good in compiling under FreeBSD. I created a workaround for this issue - I'm using a Ubuntu LTS instead of FreeBSD.
I appreciate you help and thank you for your lovely program
You may close the issue

Thank you very much.