client_test

[GoogleCodeExporter]

What steps will reproduce the problem?
1. ./client_test any.torrent
2.
3.

What is the expected output? What do you see instead?
Expected: working program
Instead: 
failed to listen on  on ports 6881-6882: Bad file descriptor
./client_test: metadata too large
assertion failed. Please file a bugreport at 
http://code.google.com/p/libtorrent/issues
Please include the following information:

version: 0.16.10.0
$Rev: 8403 $
file: 'src/udp_socket.cpp'
line: 185
function: void libtorrent::udp_socket::send(const endpoint&, const char*, int, 
boost::system::error_code&, int)
expression: is_open()

What version of the product are you using? On what operating system?
libtorrent 0.16.10.0 built with latest Boost 
armv5tel GNU/Linux
Linux version 2.6.31.8 (root@Neo) (gcc version 4.3.2 (sdk3.3-ct-ng-1.4.1) ) 
with: uClib 0.9.33
IPV6 enabled 
Please provide any additional information below.
Attached gdb bt full

Original issue reported on code.google.com by mic...@janiszewski.org on 31 May 2013 at 7:30

Attachments:

• bt-full.txt

[GoogleCodeExporter]

could you try with this patch applied? It expands a bit on the error reporting, 
and it removes that assert and handles the error gracefully at runtime instead.

Original comment by arvid.no...@gmail.com on 1 Jun 2013 at 2:22

Attachments:

• error_reporting.diff

[GoogleCodeExporter]

did the build with slightly changed b2 command:
b2 boost=source boost-link=static asserts=on geoip=static encryption=tommath 
link=static debug-symbols=on iconv=on ipv6=off toolset=gcc
previously geoip,iconv and encryption was off and there was no ipv6=off. 
The base.torrent from examples did not fire up any coredump but did not 
download anything. There was also information after starting client_test:
Error Opening file GeoIPASNum.dat
Error Opening file GeoIP.dat
failed to listen on  on ports 6990-6991: Bad file descriptor

as for Geoip I understand but whats with "bad file descriptor"? 

then Ive tried with two random, downloaded, regular torrents - result:
terminate called after throwing an instance of 'std::bad_cast'
  what():  std::bad_cast
Aborted (core dumped)

In attachement you will find gdb info.

Original comment by mic...@janiszewski.org on 1 Jun 2013 at 11:41

Attachments:

• gdb_dump_2.txt

[GoogleCodeExporter]

additional question - as I understand python bindings code is almost the same 
as the libtorrent base. So, does your pathes also update the bindings code? 

Original comment by mic...@janiszewski.org on 1 Jun 2013 at 12:30

[GoogleCodeExporter]

yes, the python bindings only provide a python interface to the underlying 
library. The patch to improve error reporting would also affect python.

Another way to get more information about what fails would be to run strace(), 
and look at which socket operation fails.

However, I am interested in knowing if this patch helps. I would like to commit 
it, at least to trunk.

Original comment by arvid.no...@gmail.com on 1 Jun 2013 at 3:44

[GoogleCodeExporter]

the comment no. 2 is after building PATHED version

Original comment by mic...@janiszewski.org on 1 Jun 2013 at 5:50

[GoogleCodeExporter]

the patch is supposed to have updated the error message for: "listen failed". 
Also, are you sure you're copying the output correctly? This error message 
looks suspicious since there's an extra "on" in it, and an extra space as well: 
"failed to listen on  on ports 6990-6991: Bad file descriptor"

Original comment by arvid.no...@gmail.com on 1 Jun 2013 at 6:34

[GoogleCodeExporter]

hmm are you sugesting that the build was with no patch ?
I;m pretty sure that I patched the src - in other case there wouldnot be any 
change in gdb output would it ? 

As for extra "on" take a look at the first gdb dump - it also have double "on"

Original comment by mic...@janiszewski.org on 1 Jun 2013 at 6:50

[GoogleCodeExporter]

it was patched:
patch -p5 < error_reporting.diff
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: include/libtorrent/alert_types.hpp
|===================================================================
|--- include/libtorrent/alert_types.hpp (revision 8437)
|+++ include/libtorrent/alert_types.hpp (working copy)
--------------------------
File to patch: include/libtorrent/alert_types.hpp
patching file include/libtorrent/alert_types.hpp
Reversed (or previously applied) patch detected!  Assume -R? [n]

Original comment by mic...@janiszewski.org on 1 Jun 2013 at 6:54

[GoogleCodeExporter]

Hello,
anything I can do to support the topic ?

Original comment by mic...@janiszewski.org on 3 Jun 2013 at 7:27

[GoogleCodeExporter]

could you set a breakpoint in libtorrent::listen_failed_alert::message() to see 
it print out that message?

The message you get still suggests you're running without my patch. The new 
message will pin-point which operations that fails. Running under strace would 
probably also help pin-pointing where exactly it fails, and what's being passed 
in to the system call. It may take some more digging through logs though.

Original comment by arvid.no...@gmail.com on 4 Jun 2013 at 12:18

[GoogleCodeExporter]

I'm doing rebuild of libtorrent with the patch to see if there will be any 
chage. As for breakpoint - can you describe how to do that ?

Rgds,
MJ

Original comment by mic...@janiszewski.org on 8 Jun 2013 at 10:50

[GoogleCodeExporter]

ok so strace and gdb outputs in attachement.As for breakpoint - can you 
describe how to do that

Original comment by mic...@janiszewski.org on 8 Jun 2013 at 5:15

Attachments:

• btfull-client-test.txt
• strace.log

[GoogleCodeExporter]

gdb --args <path-to-client-test> <arguments>

(gdb) break libtorrent::listen_failed_alert::message
(gdb) run

Original comment by arvid.no...@gmail.com on 8 Jun 2013 at 7:31

[GoogleCodeExporter]

here you are

Original comment by mic...@janiszewski.org on 8 Jun 2013 at 7:42

Attachments:

• bt_full_breakpoint.txt

[GoogleCodeExporter]

I see. that error message comes from client_test itself. I assumed it was the 
listen_failed_alert that printed it.

Looking at the strace, the error seems to come from a call to epoll. It's not 
clear what's failing at a higher level though.

If you invoke client_test with "-f alerts.log" you will get some more error 
messages in there. You could also build libtorrent with verbose logging enabled 
(add logging=verbose to the bjam command line) which will give you more error 
messages as well.

Original comment by arvid.no...@gmail.com on 8 Jun 2013 at 7:56

[GoogleCodeExporter]

the backtrace of where listen_failed_alert is constructed would be more useful:

(gdb) break libtorrent::listen_failed_alert::listen_failed_alert

The patched version is supposed to include that in the error message though. 

Original comment by arvid.no...@gmail.com on 8 Jun 2013 at 7:58

[GoogleCodeExporter]

well, the weird thing is that the -f alert.log option gives alert.log with 0b 
size.
Done the new breakpoint gdb dump, please see the attachement

Original comment by mic...@janiszewski.org on 8 Jun 2013 at 8:03

Attachments:

• bt_full_breakpoint2.txt

[GoogleCodeExporter]

also, don't know if its significant but as I wrote in 484 the src code was 
modified with the implementation of epoll_create1 as the uClib did not had one. 
So added code was:
#include <sys/syscall.h>
#include <sys/epoll.h>

extern "C" {
#ifdef __NR_epoll_create1
_syscall1(int, epoll_create1, int, flags)
#else
int epoll_create1(int flags)
{
    return ENOSYS;
}
#endif
}

Original comment by mic...@janiszewski.org on 8 Jun 2013 at 8:07

[GoogleCodeExporter]

ok. So, for some reason opening the socket fails for you.

Given that you had to hack in epoll, you may want to try building using 
select() instead.

You do this by disabling epoll by building with 
"cxxflags=-DBOOST_ASIO_DISABLE_EPOLL" on the bjam command line. Since this 
isn't a proper bjam feature, you need to rebuild all as well. You do that by 
passing in -a

Original comment by arvid.no...@gmail.com on 8 Jun 2013 at 8:23

[GoogleCodeExporter]

ok, will try and write tommorow about the outcomes

Original comment by mic...@janiszewski.org on 8 Jun 2013 at 8:26

[GoogleCodeExporter]

well... it works :)

Original comment by mic...@janiszewski.org on 8 Jun 2013 at 11:39

[GoogleCodeExporter]

Original comment by arvid.no...@gmail.com on 9 Jun 2013 at 5:36

• Changed state: WontFix