-
-
Notifications
You must be signed in to change notification settings - Fork 413
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rtorrent 0.9.0 crashing #39
Comments
Does this happen on the latest version from github? Also, what distro and gcc version are you using? |
On 03/09/2012 02:22 PM, Jari Sundell wrote:
No, I compiled it from the 0.9.0 tarball. Should I try from the current Distro: Slackware64-current
|
Try the latest from github, use './configure --enable-debug' and compile with 'make check && make install'. If the crash keeps happening, add these to your config file;
Just replace the dir with something else, tar them up and send them to my mail address. sundell.software@gmail.com |
Not enough information provided, closing. |
autogen doesn't run: configure.ac:5: error: possibly undefined macro: AM_PATH_CPPUNIT |
I'm also unable to reopen the ticket.... |
You need to install cppunit to create the config scripts. |
First results: The torrent file that crashed instantly 0.9.0 seems to work now. At least it doesn't crash on open. I will refer back in 1-2 days after a more thorough test period. |
Update: No crashes since. One anomaly I found that might or might not be related is that sometimes, when starting a torrent, it complains about accessing/creating the directories and files. Sometimes I have to manually create them and reload the torrent. |
I got the same error: Signal code '2': Non-existent physical address. today with rTorrent version 0.9.2/0.13.2. I believe I have some more info on this matter. As my torrent box has no hard drive (for silence reasons), I boot it from a pendrive and also download to another pendrive. Unfortunately pendrive tended to get very slow at times (it might be because of ntfs-3g or it is just too slow). Therefore I've changed the rtorrent directory to /dev/shm. I have got 4GB of RAM, so it makes for a default 2GB /dev/shm. I had forgotten that it is almost full when I ordered another file to download. It started normally, but halfway, I guess when /dev/shm got full, I got the error. Afterwords rtorrent would start normally with all torrents closed and would crash, with the same message, after starting any torrent. Everything was back to normal after I've deleted the unnecessary files from /dev/shm, at which point downloads resumed like nothing happened. |
I've gotten the same error when the filesystem I write logs to fills up. |
For anybody else experiencing this problem, the git repo should fix it, as stated above. However, you may need to remove legacy libtorrent and restart your machine. After compiling libtorrent and rtorrent (latest), I was still getting these errors. It wasn't until I removed rtorrent and libtorrent-dev and rebooted my machine that I saw rtorrent working correctly. Sorry to ping you about an old bug, but I thought it would be worth mentioning to future googlers. |
Hey guys, Caught SIGBUS, dumping stack Error: Success I've got the logs suggested by rakshasa here (slightly edited to hide my private ids) any help would be appreciated, let me know if you need any more information |
Did you see my post above yours? Has that helped? Also, why not pastebin your logs? |
yeah, probably could have done pastebin, but i hit file size limits on some of the logs. As i said, I did a fresh install on my system (backing up my rtorrent configs/torrents first) and only installed the latest git repos, so there shouldn't be any existing rtorrent/libtorrent on the system messing things up. |
I can confirm that this happens with the latest pull on Oracle Linux. But not immediately, it runs for a while then stops. -sh-4.1$ rtorrent Caught SIGBUS, dumping stack: rtorrent() [0x41386b] /lib64/libpthread.so.0(+0xf500) [0x7ffe7249e500] /lib64/libc.so.6(memcpy+0xa3) [0x7ffe72185903] /usr/lib/libtorrent.so.17(+0x73b74) [0x7ffe730c5b74] /usr/lib/libtorrent.so.17(+0xb3e21) [0x7ffe73105e21] /usr/lib/libtorrent.so.17(+0xb43fd) [0x7ffe731063fd] /usr/lib/libtorrent.so.17(+0xb75a6) [0x7ffe731095a6] /usr/lib/libtorrent.so.17(+0xb76f8) [0x7ffe731096f8] /usr/lib/libtorrent.so.17(_ZN7torrent9PollEPoll7performEv+0xe0) [0x7ffe7308d3c0] /usr/lib/libtorrent.so.17(_ZN7torrent9PollEPoll7do_pollEli+0x5e) [0x7ffe7308d8ee] /usr/lib/libtorrent.so.17(_ZN7torrent11thread_base10event_loopEPS0_+0xdc) [0x7ffe730c42bc] rtorrent() [0x412b1f] /lib64/libc.so.6(__libc_start_main+0xfd) [0x7ffe7211acdd] rtorrent() [0x40ecf9] Error: Success Signal code '2': Non-existent physical address. Fault address: 0x7ffe50e58000 The fault address is not part of any chunk. Aborted |
I faced the same issue and apparently my disk was full. As soon as I freed some space rtorrent started normally. |
My issue seems to have been that my hard drive was dying.. Bought a new drive and its working fine. |
If you have this problem with external drives, look into |
I also have this issue. I compiled rtorrent and libtorrent from git, but it still crashes often (from 2 hours to 2 days after start). What else can I do to troubleshoot ? Edit: Faulty drive... I had bad blocks. To check the drive /dev/sda, you can do a "sudo smartctl -a /dev/sda" and look up the errors. |
My drives are also fine, checked smart status and ran a fsck. Not full either. rtorrent instantly crashes upon attempting to start it (I had 2 active torrents).
I am running |
|
I am also experiencing this. I just tried upgrading to latest rtorrent, and still getting the seg faults. I have run smartctl and checked the drive has no problems, the drive is not full. At this point I have no idea what could be wrong. Can we re-open this? Do you want me to post debug logs? |
Well, it should be reponed :) |
I deleted my session folder and the seg faults went away. Then I loaded some of the torrents that had previously been in the session (from newly-downloaded torrent files) and they came back. I have narrowed it down to relating to one of seven torrent files. Would these be of interest to the developer? |
Narrow it to one :) and then developer will look at the torrent file |
I have the same problem as @benkloester. Problem is related to exact torrents. |
Hello, I'm having the same problem I fixed it by deleting rtorrent.dht_cache. If you want the offending torrent I can send it to you. It happened between 0 and 2% through the download. Error: Success I'm using gentoo lnux. |
Could you send both the torrent + torrent.rtorrent + torrent.libtorrent_resume file and dht cache file (when confirmed to be crashing the client). Also, try alternatively to delete torrent.rtorrent and torrent.libtorrent_resume to see if either causes the crashes to disappear. It might be a specific peer address stored in resume that is causing the issue. |
I said earlier that I deleted the dht_cache file as in permenently (sorry). But I'd be happy to send you the other stuff plus the new dht cache file. I tried to wgetpaste it but no-one will take it, sugestions? |
Just send it to sundell.software@gmail.com. |
Please say something if you got it I just sent it. |
Yeah, got it. |
I had several segfaults from time to time with specific torrents. I've switched to transmission to check whether this is client issue. Transmission worked like a charm, but after changing my hdd to ssd I've given rtorrent one more chance - eveyrything works perfect till now. May rtorrent be far more sensitive about hdd errors? |
Absolutely |
And kernel bugs, mmap is not as well tested as normal read/write file sockets. |
Is there a place to improve or rather we have to accept this fact? |
Well, there's no reason to believe that I have hardware errors, my hdd is fine and it's less then 6 months old. |
I got a similar error (SIGBUG) today, but it was due to my hard disk being full. After freeing up some space everything went back to the normal. So I don't think my issue was serious, just reporting it here to let you guys know. |
@rakshasa I am also having a similar SIGBUS issue that @alcohol had:
I think I have isolated it to a particular torrent though. Should I send the I've done a couple of experiments, and it seems as though every time it's failing I'm getting similar info in the storage logs, down to the final indices it is processing before the SIGBUS occurs. Good thing the logs are timestamped or you'd not be able to tell the difference =P
vs
|
Got the same error.
rtorrent 0.9.2, debian 8, kernel 3.16.0-4 |
Same here
|
I'm on 0.9.6 and haven't seen any errors anymore in a long time. |
a015c33675a6ed93c19c87a79122188de567c039 It was likely fixed in the above commit. |
I'm experiencing this issue with rtorrent 0.9.6/0.13.6. Fresh install of Debian.
|
This issue is closed – open a new issue and refer to #39 if you want a better chance af any fix. |
Thank you, @earthmeLon . Of course my hard drive had idled and that caused rtorrent the problems. :) |
While starting torrents, I get the following output and rtorrent crashes:
0 rtorrent(_Z13handle_sigbusiP7siginfoPv+0x41) [0x444af1]
1 /lib64/libc.so.6(+0x362c0) [0x7f267e9b62c0]
2 /lib64/libc.so.6(+0x8a9a3) [0x7f267ea0a9a3]
3 /usr/lib64/libtorrent.so.14(+0x80140) [0x7f267fcd0140]
4 /usr/lib64/libtorrent.so.14(+0xd60ed) [0x7f267fd260ed]
5 /usr/lib64/libtorrent.so.14(+0xd61dd) [0x7f267fd261dd]
6 /usr/lib64/libtorrent.so.14(+0xe0fc6) [0x7f267fd30fc6]
7 /usr/lib64/libtorrent.so.14(_ZN7torrent9PollEPoll7performEv+0xd8) [0x7f267fc923b8]
8 rtorrent() [0x51e6c4]
9 rtorrent() [0x4497b4]
10 /lib64/libc.so.6(__libc_start_main+0xed) [0x7f267e9a14cd]
11 rtorrent() [0x4437e9]
Error: Success
Signal code '2': Non-existent physical address.
Fault address: 0x7f267d430000.
The fault address is not part of any chunk.
I used 0.8.3 and 0.8.4 for a very long time without issues.
Additional info:
libtorrent 0.13.0
libsigc++ 2.2.3
glibc 2.14.1
kernel 2.6.39.1
Need more info?
The text was updated successfully, but these errors were encountered: