headers
Katharina Haselhorst | 1 Nov 2010 13:33
Picon
Favicon

Re: [solved] segmentation fault on dlopen

Hello again :)

I solved the issue: my machine failed to use the fPIC flag corretly when 
compiling the libcppcsp2 library and hence produced position dependent 
code which resulted in a segmentation fault when included in my shared 
libaray. Strangly enough my machine also failed to produce an error when 
linking my shared library (which other machines DID) against the 
position dependent code. Now it seems to work fine.
Thanks for you help!

Regards, Kathi Haselhorst

On 10/31/2010 11:05 AM, Katharina Haselhorst wrote:
> Hello,
>
> On 10/29/2010 11:14 PM, Lakshmanan Suryanarayanan wrote:
>> Are libtorrent and libcppcsp2 linking against different versions of boost by
>> any chance?
>> In an unrelated combination of libraries linked against different versions
>> of boost, we had dl_open related segfaults from boost.
>>
>
> libcppcsp2 is not built as a shared library (compilation results in a .a
> file), however it is only using parts of boost, that are contained
> within the boost headers and not using the parts of the library which
> require compilation. Hence, libcppcs2 has no runtime dependency on boost
> (and therefor not linked against it). But I used the same boost version
> for compiling both libraries. Might it be a problem that I combine a
> shared library and a non shared library into a new shared one (I tried
> to give the extra -fPIC flag to the CPP compiler when building
(Continue reading)

Permalink | Reply | 0 comments |
headers
imin imup | 2 Nov 2010 23:15
Picon

Re: Client triggers a kernel bug which causes whole system to die.

> The kernel is kind enough to print the stack trace:
>
> ...
> Aug 13 13:58:17 p2p kernel: [<84669f46>] vfs_read+0x86/0x180
> Aug 13 13:58:17 p2p kernel: [<8466a82a>] sys_pread64+0x8a/0xa0
> Aug 13 13:58:17 p2p kernel: [<846091f4>] sys_pread_wrapper+0x14/0x40
> Aug 13 13:58:17 p2p kernel: [<8460519c>] syscall_call+0xc/0x10
> Aug 13 13:58:17 p2p kernel: [<846091e0>] sys_pread_wrapper+0x0/0x40
>
> actually, a second look suggests that this might just be caused by the
> first
> issue in the MM, which seems likely. If the MM breaks, it's probably going
> to be
> a file I/O syscall that will notice it first.
>
> either way though, you might want to try to build libtorrent with regular
> file
> operations (read/write) instead of readv/writev. You can do this by making
> sure
> include/libtorrent/config.hpp defines:
>
> #define TORRENT_USE_READV 0
> #define TORRENT_USE_WRITEV 0
>
> You might try to disable other feature in there as well, such as
> TORRENT_USE_FALLOCATE.
>
>
These 3 are disabled and tested on STB. But It still triggers the kernel
bug. Further ideas appreciated.
(Continue reading)

Permalink | Reply | 0 comments |
headers
xuanwuv | 4 Nov 2010 02:41
Picon

Libtorrent-discuss cannot connect peer

Hello Arvid,
I use to test LT 15.4 with boost 1.44.
That recvice two different log is one success the other fail.

the success log 
*** starting log ***
*** OUTGOING CONNECTION
*** bt_peer_connection
Nov 04 08:51:02 *** CANNOT READ [ quota: 0 ignore: no queue-size: 0 queue-limit: 262144 disconnecting: no ]
0000000000000000000000000000000000000000000110000000000000000101Nov 04 08:51:02 ==> HANDSHAKE
bandwidth [ 0 ] + 68
Nov 04 08:51:02 *** ASYNC_WRITE [ bytes: 68 ]
Nov 04 08:51:02 *** REQUEST_BANDWIDTH [ upload: 68 prio: 1 channels: 00E79740 01720278 01732B90 00000000
ignore: 0 ]
Nov 04 08:51:02 *** REQUEST_BANDWIDTH [ download: 30 prio: 1 ]
bandwidth [ 1 ] + 50
Nov 04 08:51:02 *** SYNC_READ [ max: 20 ret: 0 e: Cannot complete immediately a non - blocking socket
operation. ]
Nov 04 08:51:02 *** ASYNC_READ [ max: 20 bytes ]
wrote 68 bytes
Nov 04 08:51:02 *** SEND BUFFER DEPLETED [ quota: 0 ignore: no buf: 0 connecting: no disconnecting: no ]
read 20 bytes
 BitTorrent protocol
Nov 04 08:51:02 *** SYNC_READ [ max: 28 ret: 28 e: action completed successfully ]
read 28 bytes
0000000000000000000000000000000000000000000100000000000000000101
supports DHT port message
supports FAST extensions
supports extensions protocol
 info_hash received
(Continue reading)

Permalink | Reply | 0 comments |
headers
Adam Fisk | 5 Nov 2010 16:59
Favicon

Compiling 0.15.4 on msvc-10.0 with Boost 1.44

Hi Arvid- I've moved on to getting 0.15.4 working on Windows,
compiling with msvc-10.0 and Boost 1.44.0. I unfortunately run into
the compilation issue at the end of this e-mail.

Interestingly, it works with 1.43.0 and below. Running with 1.43 would
not be a problem, except that it appears to have the same issue with
Boost ASIO and 64 bit machines (I'm running on Windows 7 64 bit). I
would just apply the same patch from

https://svn.boost.org/trac/boost/ticket/4782

*but* that code changed drastically from 1.43 to 1.44, and I'd have to
be very careful digging through it all.

So I'm wondering if you can direct me in either direction of patching
1.43 or fixing the 1.44 build. Ideally it would be great to get things
working with 1.44 as far as future development goes for LT. Here's the
boost command I'm building with:

c:\boost\tools\jam\src\bin.ntx86\bjam.exe -a -q
include=C:\OpenSSL\include debug toolset=msvc-10.0 threading=multi
link=static runtime-link=static boost=source logging=none
dht-support=off zlib=shipped geoip=off upnp-logging=on openssl=pe
variant=debug character-set=unicode invariant-checks=off define=NDEBUG

Thanks!

-Adam

************************************************************
(Continue reading)

Permalink | Reply | 2 comments |
headers
arvid | 6 Nov 2010 17:46
Picon
Picon
Favicon

Re: Compiling 0.15.4 on msvc-10.0 with Boost 1.44

Quoting Adam Fisk <a <at> littleshoot.org>:
> Hi Arvid- I've moved on to getting 0.15.4 working on Windows,
> compiling with msvc-10.0 and Boost 1.44.0. I unfortunately run into
> the compilation issue at the end of this e-mail.

I just checked in a fix in trunk and the RC_0_15 branch. This appears to work:

Index: branches/RC_0_15/include/libtorrent/torrent_handle.hpp
===================================================================
--- branches/RC_0_15/include/libtorrent/torrent_handle.hpp	(revision 4959)
+++ branches/RC_0_15/include/libtorrent/torrent_handle.hpp	(working copy)
 <at>  <at>  -41,6 +41,8  <at>  <at> 
 #endif

 #include <boost/date_time/posix_time/posix_time_types.hpp>
+#include <boost/shared_ptr.hpp>
+#include <boost/weak_ptr.hpp>

 #ifdef _MSC_VER
 #pragma warning(pop)

thanks for the report!

--

-- 
Arvid Norberg

------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a 
Billion" shares his insights and actions to help propel your
(Continue reading)

Permalink | Reply | 1 comment |
headers
Adam Fisk | 7 Nov 2010 17:54
Favicon

Re: Compiling 0.15.4 on msvc-10.0 with Boost 1.44

Works great, Arvid. Thanks a million. -Adam

On Sat, Nov 6, 2010 at 9:46 AM,  <arvid <at> cs.umu.se> wrote:
> Quoting Adam Fisk <a <at> littleshoot.org>:
>> Hi Arvid- I've moved on to getting 0.15.4 working on Windows,
>> compiling with msvc-10.0 and Boost 1.44.0. I unfortunately run into
>> the compilation issue at the end of this e-mail.
>
> I just checked in a fix in trunk and the RC_0_15 branch. This appears to work:
>
> Index: branches/RC_0_15/include/libtorrent/torrent_handle.hpp
> ===================================================================
> --- branches/RC_0_15/include/libtorrent/torrent_handle.hpp      (revision 4959)
> +++ branches/RC_0_15/include/libtorrent/torrent_handle.hpp      (working copy)
>  <at>  <at>  -41,6 +41,8  <at>  <at> 
>  #endif
>
>  #include <boost/date_time/posix_time/posix_time_types.hpp>
> +#include <boost/shared_ptr.hpp>
> +#include <boost/weak_ptr.hpp>
>
>  #ifdef _MSC_VER
>  #pragma warning(pop)
>
> thanks for the report!
>
> --
> Arvid Norberg
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
zhang peng | 8 Nov 2010 15:51
Picon

A proposal for saving memory

When I start a torrent with too many files, I found it consumed too
many memory. The torrent file which I used, has about 58,960 files in many
different folder, used the piece_size in 2M. The torrent files is about 7M,
and after started, it consumed about 48M memory.

I found the infomation through debugging;
1) torrent_info object cousumes about 28M memroy, which the m_info_section
uses around 7M, and the m_files uses more than 20 M.
    And there is one thing I'm puzzling: one file_entry seems only take
about 130bytes, so 58,960 files should be 58,960 * 130 = about
7M memory.  But in fact, after executing extract_files, the virtual memory
size has increased by more than 20M.

2) In the function torrent:: init (), After the sentence m_owning_storage =
new piece_manager has been executed, also increased 20M memory. It should
be, because piece_manager copy a "file_storage const & m_files" .  so there
are two m_files.

My proposal is:
1) Whether libtorrent can use a m_files pointer in piece_manager, rather
than copy it.  It can save 20M memory.
2) In addition, the option free_torrent_hashes in session_settings seems not
effect. If this effect, then the downloader download is complete, will
also save a lot of memory. And this is also benefit for the "seed_mode".
------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a 
Billion" shares his insights and actions to help propel your 
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
(Continue reading)

Permalink | Reply | 3 comments |
headers
zhang peng | 8 Nov 2010 20:54
Picon

Re: A proposal for saving memory

fix my description's error:
2) In the function torrent:: init (), After the sentence m_owning_storage =
new piece_manager has been executed, also increased 20M memory. It should
be, because piece_manager copy a "file_storage const & m_files" .  so there
are two m_files.

It's not right. the &m_files is a reference, so will not cause memory
consuming.
I have seen sometimes, when new piece_manager , the VM size increase too
many. But, I just did the same test many times, this phenomenon has not
occurred again, may be it's an accidental.

wrote：

> When I start a torrent with too many files, I found it consumed too
> many memory. The torrent file which I used, has about 58,960 files in many
> different folder, used the piece_size in 2M. The torrent files is about
> 7M, and after started, it consumed about 48M memory.
>
> I found the infomation through debugging;
> 1) torrent_info object cousumes about 28M memroy, which the m_info_section
> uses around 7M, and the m_files uses more than 20 M.
>     And there is one thing I'm puzzling: one file_entry seems only take
> about 130bytes, so 58,960 files should be 58,960 * 130 = about
> 7M memory.  But in fact, after executing extract_files, the virtual memory
> size has increased by more than 20M.
>
> 2) In the function torrent:: init (), After the sentence m_owning_storage =
> new piece_manager has been executed, also increased 20M memory. It should
> be, because piece_manager copy a "file_storage const & m_files" .  so
(Continue reading)

Permalink | Reply | 2 comments |
headers
arvid | 9 Nov 2010 02:24
Picon
Picon
Favicon

Re: A proposal for saving memory

Quoting zhang peng <hrybird <at> gmail.com>:

> fix my description's error:
> 2) In the function torrent:: init (), After the sentence m_owning_storage =
> new piece_manager has been executed, also increased 20M memory. It should
> be, because piece_manager copy a "file_storage const & m_files" .  so there
> are two m_files.
> 
> It's not right. the &m_files is a reference, so will not cause memory
> consuming.
> I have seen sometimes, when new piece_manager , the VM size increase too
> many. But, I just did the same test many times, this phenomenon has not
> occurred again, may be it's an accidental.

At least in some situations the whole file_storage is copied though, when files
are renamed for instance.

iirc, there might even be two copies, one for the disk thread and one for the
network thread.

> > When I start a torrent with too many files, I found it consumed too
> > many memory. The torrent file which I used, has about 58,960 files in many
> > different folder, used the piece_size in 2M. The torrent files is about
> > 7M, and after started, it consumed about 48M memory.

Do you think you could send the torrent file to me for testing so I can try
optimize?

> > [...]
> > My proposal is:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kharkov Alexander | 10 Nov 2010 09:37
Picon

Suggest slightly change storage_constructor_type to be more flexible

Existing libtorrent does not allow create custom storage
implementation which require custom parameters as
storage_constructor_type is pointer to function with predefined number
of arguments.
Suggest following changes in storage constructor which allow more
flexible way to create custom storage interface implementation.

 Index: include/libtorrent/storage.hpp
===================================================================
 <at>  <at>  -192,8 +194,8  <at>  <at> 
                session_settings* m_settings;
        };

-       typedef storage_interface* (*storage_constructor_type)(
-               file_storage const&, file_storage const*, fs::path
const&, file_pool&);
+       typedef boost::function<storage_interface*(
+               file_storage const&, file_storage const*, fs::path
const&, file_pool&)> storage_constructor_type;

As result all existing code will be compilable (default storage
implementation, etc.) and we have ability to create
storage_constructor_type which use object member function pointer like
this:

class CustomStorageInterface: public storage_interface {
...
};

class CustomStorageConstructor {
(Continue reading)

Permalink | Reply | 2 comments |

Gmane