'boost::python::error_already_set'

[GoogleCodeExporter]

What steps will reproduce the problem?
1. use freebsd, install /usr/ports/net-p2p/deluge
2. start deluged
3. start deluge client
4. add torrent to client

What is the expected output? What do you see instead?
Expect it to add the torrent and work.  Instead program crashes with:
terminate called after throwing an instance of
'boost::python::error_already_set'
Abort trap

What version of the product are you using? On what operating system?
latest ports version that is installed by deluge
/usr/ports/net-p2p/rblibtorrent libtorrent-0.13.tar.gz is it i believe.

Please provide any additional information below.
Everything worked prior to that update.

Original issue reported on code.google.com by trah...@gmail.com on 27 Jan 2010 at 9:11

[GoogleCodeExporter]

who said it was libtorrent?

what was the callstack at the time of the exception being thrown? (you can find 
this by running it in gdb and 
saying: "catch throw" before you run it)

Are you sure this is libtorrent 0.13? That's an ancient version.

Original comment by arvid.no...@gmail.com on 31 Jan 2010 at 9:53

[GoogleCodeExporter]

Issue 26 has been merged into this issue.

Original comment by arvid.no...@gmail.com on 16 Mar 2010 at 7:12

[GoogleCodeExporter]

Can you provide any more information?

Do you have a debug log from deluge?
Do you have a python call stack?
Does this only happen with a specific torrent? If so, could you provide the 
torrent file?

Original comment by arvid.no...@gmail.com on 16 Mar 2010 at 7:14

• Changed title: 'boost::python::error_already_set'

[GoogleCodeExporter]

Hi any update on this same error... no solution still :-| Any luck running 
deluge trahloc

Thanks for answer 

Jan Marek

Original comment by janmarek...@gmail.com on 22 May 2010 at 6:26

[GoogleCodeExporter]

I should add.. some details:
FreeBSD 8.0 RELEASE
deluge 1.1.9
python2.6
boost 1.41
error:
terminate called after throwing an instance of
'boost::python::error_already_set'
Abort trap

Original comment by janmarek...@gmail.com on 22 May 2010 at 7:52

[GoogleCodeExporter]

please run python in gdb like this:

gdb --args python deluge.py <any arguments you normally pass in>

deluge.py is probably called something else. iirc, deluge is a shell script 
that then invokes python, look in 
there to see what python script is run.

Once on the gdb command line, do:

(gdb) catch throw
(gdb) run

Deluge should start running, and instead of getting that error, you should see 
something along the lines of:

Exception caught ...

(gdb)

On the gdb command line, call:

(gdb) bt full

and post the output here.

Original comment by arvid.no...@gmail.com on 23 May 2010 at 7:27

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hi,
in the attachment You'll find the gdb log - first time i missed the beginning.

Hope this will help to clear  this out

Thanks for Your help

Kind Regards
Jan

Original comment by janmarek...@gmail.com on 24 May 2010 at 7:13

Attachments:

• gdb_deluge_full.txt

[GoogleCodeExporter]

Hi,
I have a very similar issue with recent libtorrent and deluge versions:
libtorent-rasterbar 1.0.3
deluge 1.3.11
boost 1.57.0
Python 2.7.3
python beaker 1.6.4
python chardet 2.3.0
python mako 1.0.1
python openssl 0.13
python setuptools 12.0.1
python twisted 14.0.2
python xdg 0.25
python zope-interface 4.1.2

http://pastebin.com/U9ZDhZ4Q

The same happens with Python 2.6.9

Original comment by opotape...@gmail.com on 23 Jan 2015 at 6:53

[GoogleCodeExporter]

Sorry, I forgot to mention that this happens after adding any torrent I tried 
so far

Original comment by opotape...@gmail.com on 23 Jan 2015 at 6:59

[GoogleCodeExporter]

Hi again.
This is gdb log with unstripped libtorrent binding:
http://pastebin.com/RqreeqFQ

Original comment by opotape...@gmail.com on 24 Jan 2015 at 3:16

[GoogleCodeExporter]

as far as I can tell, this is an issue in the python binding. apparently the 
binding for prioritize_files() has a problem causing boost python's check to 
fail:

expect_non_null<_object> (x=0x0)

in

return_from_python.hpp:156

Original comment by ar...@bittorrent.com on 24 Jan 2015 at 6:10

[GoogleCodeExporter]

it doesn't look like you're running the latest version of the python binding. 
Are you sure there isn't another installation that might override you 1.0.3 
build?

the 1.0.3 python bindings specifically has try-catch blocks for that specific 
exception in that place.

Original comment by ar...@bittorrent.com on 24 Jan 2015 at 6:20

[GoogleCodeExporter]

I'm pretty sure it is 1.0.3. I cross-compiled it myself, along with everything 
else. I'm trying to get deluge to work on my arm router, and I use optware 
build system for that purpose. Added and upgraded many packages (as well as a 
new optware target) to satisfy deluge core and web dependencies.
I was looking at that portion of code and wondering how that exception could 
escape that "catch( error_already_set )" block. I looked at boost::python 
sourcecode and noticed that they use "catch( const error_already_set& )", and 
tried that, but it didn't help. Finally, I tried "catch (boost::function0<void> 
f)", and still no luck. I'm hesitant to use "catch (...)", but I can try that 
as well.
Something else I could try?
Thank you!

Original comment by opotape...@gmail.com on 24 Jan 2015 at 7:31

[GoogleCodeExporter]

testing catch (...) would at least tell if the error is in the catch block or 
not. If that works, perhaps you have to catch something else too

Original comment by arvid.no...@gmail.com on 24 Jan 2015 at 7:46

[GoogleCodeExporter]

I "tried catch (...)", it didn't help. Probably, the problem lies elsewhere

Original comment by opotape...@gmail.com on 24 Jan 2015 at 8:40

[GoogleCodeExporter]

I installed unstriped versions of libpython and libboost_python, and now have a 
much more informative output from gdb:
http://pastebin.com/UvN6c8KR
I'll try to look into it myself, but it is a little beyond me, so I'd be very 
grateful if you could help me out here!

P.S. please tell me if I can do anything else to provide more info, e.g. 
installing more unstripped libs, etc..

Original comment by opotape...@gmail.com on 24 Jan 2015 at 9:07

[GoogleCodeExporter]

should probably note that I slightly edited src/torrent_handle.cpp. In terms of 
functionality it differs only in the catch portion, but I added some comments, 
so at src/torrent_handle.cpp:150 there's actually:
142:void prioritize_files(torrent_handle& info, object o)
143:{
144:   std::vector<int> result;
145:   try
146:   {
...
150:         object obj = extract<object>( iter_obj.attr( "next" )() );

So, it looks, the problem lies in the try-catch block. But how can an exception 
escape "catch (...)"? Is it possible that my router's libstdc++/libc 
throw-catch mechanism is flawed? In case this might help, here's gdb log with 
all loaded libraries unstripped (got the list from gdb: info sharedlibrary):
http://pastebin.com/ziqvQCRS
It looks like the log only different in the final phase, where libstdc++ kicks 
in to terminate on unhandled exception

Original comment by opotape...@gmail.com on 24 Jan 2015 at 10:21

[GoogleCodeExporter]

I have solved my issue, and it was not a libtorrent issue. Due to some uClibc 
peculiarities, python has to be explicitly linked with libgcc_s on build, 
otherwise all C++ exceptions in C++ extensions modules are not being caught at 
all — hence my problem with libtorrent. Now deluge works perfectly fine, so 
many thanks for your work and sorry for the bother!

Original comment by opotape...@gmail.com on 29 Jan 2015 at 12:52

[GoogleCodeExporter]

Original comment by arvid.no...@gmail.com on 29 Jan 2015 at 1:05

• Changed state: Fixed