core dump report location ?

[beadon]

I am currently experiencing hard drive issues in my machine. I have coredumps showing that rtorrent is crashing - I suspect during a checksum validation.

How should these be reported ?

[kannibalox]

If it's all the same issue, identifying a single good representative dump is really all that's needed, and that should be small enough to embed directly in a comment. If the problem looks like "Non-existent physical address" though, that usually means something is going wrong at the storage layer, and the dump is really just whatever rTorrent happened to be doing when it received the signal.

[stickz]

Core dump is not a good solution. You're better off to install gdb.

Step 1: gdb rtorrent Step 2: type run in gdb shell. Step 3: When program crashes, exit and type bt.

The purpose is to display a back trace to see why torrent is crashing.

[beadon]

Got it. I have a gdb capture of startup that appears to be related to a memcopy.

Reading symbols from rtorrent... (No debugging symbols found in rtorrent) [New LWP 2034525] [New LWP 2034594] [New LWP 2034858] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `/usr/bin/rtorrent'. Program terminated with signal SIGBUS, Bus error.

0 __memcpy_sse2_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:385

385 ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No such file or directory. [Current thread is 1 (Thread 0x7ffff7452980 (LWP 2034525))] (gdb) quit

version is distributed to ubuntu 22.10 , rtorrent v0.9.8

thoughts ?

[beadon]

The crash appears to be triggered when the disk has been completely filled.

I suspect this occurred when there was a change in the file location, from one drive to another. Removing the partial(?) file from the drive frees up enough space, and rtorrent recovers and starts again.