libtorrent icon indicating copy to clipboard operation
libtorrent copied to clipboard

Caught internal_error: priority_queue_insert(...) called on an already queued item

Open Zumochi opened this issue 9 years ago • 10 comments

Error source

I more or less understands what throws it, but how would I solve it? Is there a way to figure out which torrent causes this error to be thrown so I can remove/re-add it? rTorrent now simply terminates when it gets this error.

Related issue: rtorrent/#13

Zumochi avatar Jan 27 '16 13:01 Zumochi

i all of a sudden started getting this error, i disabled rutorrent and i can run rtorrent now.. maybe once rtorrent has gotten going i can use rutorrent again...

i checked in rutorrent/share/users/{username}/torrents/ and there was a bunch of torrents i imagine it was trying to add that some must have already been in there, thus the error, after deleting them all rutorrent works with rtorrent again without crashing it

hayden-t avatar Apr 06 '16 12:04 hayden-t

i get this error on a daily bases .. my only observation this happen when i have many huge torrent files like 15g + .. a year has been passed any one :) ..

=======4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:04:33 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux==============

1502973001 N rtorrent main: Starting thread. 1502973001 N worker_rtorrent: Starting thread. 1502973002 C Caught internal_error: 'priority_queue_insert(...) called on an already queued item.'. ---DUMP--- /usr/lib/libtorrent.so.19(_ZN7torrent14internal_error10initializeERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x227) [0x7f5d9dc9d507] rtorrent(_ZN7torrent14internal_errorC2EPKc+0x87) [0x44fd67] /usr/lib/libtorrent.so.19(+0xe1f36) [0x7f5d9dd50f36] /usr/lib/libtorrent.so.19(+0x2b5ff) [0x7f5d9dc9a5ff] /usr/lib/libtorrent.so.19(+0x2bd26) [0x7f5d9dc9ad26] /usr/lib/libtorrent.so.19(+0xe284c) [0x7f5d9dd5184c] /usr/lib/libtorrent.so.19(_ZN7torrent11TrackerList10send_stateEPNS_7TrackerEi+0x74) [0x7f5d9dcba9a4] /usr/lib/libtorrent.so.19(_ZN7torrent17TrackerController16send_start_eventEv+0xe3) [0x7f5d9dcb92d3] rtorrent() [0x4c8621] rtorrent() [0x4cf642] /usr/lib/libtorrent.so.19(+0xb532e) [0x7f5d9dd2432e] /usr/lib/libtorrent.so.19(+0x2a6b3) [0x7f5d9dc996b3] /usr/lib/libtorrent.so.19(ZN7torrent11thread_base10event_loopEPS0+0x170) [0x7f5d9dcecf50] rtorrent() [0x412064] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x7f5d9c7dd830] rtorrent() [0x415329]

---END---

mids33 avatar Aug 17 '17 12:08 mids33

Hello, i have a some problem. how can solve this ?

---END--- 1544713731 C Caught internal_error: 'priority_queue_insert(...) called on an already queued item.'. ---DUMP--- /usr/lib/libtorrent.so.20(_ZN7torrent14internal_error10initializeERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x214) [0x7f9443699324] rtorrent(_ZN7torrent14internal_errorC1EPKc+0xa0) [0x5640cf3e0510] /usr/lib/libtorrent.so.20(+0xf9788) [0x7f9443761788] /usr/lib/libtorrent.so.20(+0x2df9d) [0x7f9443695f9d] /usr/lib/libtorrent.so.20(+0x2e780) [0x7f9443696780] /usr/lib/libtorrent.so.20(+0xf7a77) [0x7f944375fa77] /usr/lib/libtorrent.so.20(+0xfa035) [0x7f9443762035] /usr/lib/libtorrent.so.20(_ZN7torrent11TrackerList10send_stateEPNS_7TrackerEi+0x74) [0x7f94436b7d14] /usr/lib/libtorrent.so.20(_ZN7torrent17TrackerController16send_start_eventEv+0xe3) [0x7f94436b6883] rtorrent(+0xcf2c6) [0x5640cf44c2c6] rtorrent(+0xd4a67) [0x5640cf451a67] /usr/lib/libtorrent.so.20(+0xc6bfe) [0x7f944372ebfe] /usr/lib/libtorrent.so.20(+0x2cffe) [0x7f9443694ffe] /usr/lib/libtorrent.so.20(ZN7torrent11thread_base10event_loopEPS0+0x180) [0x7f94436f6000] rtorrent(+0x1efa3) [0x5640cf39bfa3] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7f9441dd62e1] rtorrent(+0x2052a) [0x5640cf39d52a]

---END---

vsystech avatar Dec 13 '18 15:12 vsystech

don't know what your setting is .. but try first this: backup your .session folder on /rtorrent/.session type this rm *resume then start rtorrent if it keep crashing .. remove all content of .session .. and 1 other thing the completed file not exceed 4000 files ..

good luck probably there is a better solution than that :)

mids33 avatar Dec 14 '18 16:12 mids33

this started happening every rtorrent restart. mids33 solution does work but is there no way of identifying which torrent is the problem ?

SmokeyBR avatar Feb 08 '19 05:02 SmokeyBR

Still having this issue after restarting rtorrent sometimes when I have more than, say 80, torrents open.

Using mids33 solution works most of the time.

Zumochi avatar Oct 08 '19 18:10 Zumochi

This ticket has been open without a clear solution in a while and it has stumped me that over many installations I've only ever seen this persistent issue a single time. I dug into this yesterday and was able to find a solid workaround that doesn't involve clearing and re-hashing the resume data each and every time you restart rTorrent.

By every indication, this problem is caused directly by ruTorrent when plugins are initialized when rTorrent starts up.

If you have ruTorrent installed, there's a solid chance you have a line very similar to this in your .rtorrent.rc

execute2 = {sh,-c,/usr/bin/php /srv/rutorrent/php/initplugins.php liara &}

I discovered through trial and error that if this line is commented out of the configuration, rTorrent starts without any errors and continues to function properly if you load ruTorrent and let plugins initialize after the initial startup.

So, there appears to be a problem initializing plugins directly on start. Workaround? Delay the initialization:

Change the execute line into a schedule:

schedule2 = init_plugins, 10, 0, "execute2 = {sh,-c, /usr/bin/php /srv/rutorrent/php/initplugins.php liara &}"

Now, rTorrent will wait 10 seconds after starting the application and then init plugins a single time. The crash seems to be gone now.

Hope this helps someone else.

liaralabs avatar Mar 22 '20 18:03 liaralabs

This ticket has been open without a clear solution in a while and it has stumped me that over many installations I've only ever seen this persistent issue a single time. I dug into this yesterday and was able to find a solid workaround that doesn't involve clearing and re-hashing the resume data each and every time you restart rTorrent.

By every indication, this problem is caused directly by ruTorrent when plugins are initialized when rTorrent starts up.

If you have ruTorrent installed, there's a solid chance you have a line very similar to this in your .rtorrent.rc

execute2 = {sh,-c,/usr/bin/php /srv/rutorrent/php/initplugins.php liara &}

I discovered through trial and error that if this line is commented out of the configuration, rTorrent starts without any errors and continues to function properly if you load ruTorrent and let plugins initialize after the initial startup.

So, there appears to be a problem initializing plugins directly on start. Workaround? Delay the initialization:

Change the execute line into a schedule:

schedule2 = init_plugins, 10, 0, "execute2 = {sh,-c, /usr/bin/php /srv/rutorrent/php/initplugins.php liara &}"

Now, rTorrent will wait 10 seconds after starting the application and then init plugins a single time. The crash seems to be gone now.

Hope this helps someone else.

Thank you for this, I'll give this a shot. Is there a difference between execute and execute2 and schedule and schedule2?

Fuzzydroid avatar Mar 23 '20 19:03 Fuzzydroid

execute is deprecated and the command may be fully removed in a future version:

https://github.com/rakshasa/rtorrent/wiki/rTorrent-0.9-Comprehensive-Command-list-(WIP)#execution

liaralabs avatar Mar 23 '20 19:03 liaralabs

execute is deprecated and the command may be fully removed in a future version:

https://github.com/rakshasa/rtorrent/wiki/rTorrent-0.9-Comprehensive-Command-list-(WIP)#execution

Thank you for your help.

Fuzzydroid avatar Mar 23 '20 19:03 Fuzzydroid