On Sat, 12 Jun 2021 at 20:52, Morgan Adamiec <[email protected]> wrote:
> > > On 12/06/2021 16:45, atn19 via pacman-dev wrote: > > Hi all, > > Using an up-to-date system, I have an issue since I have been using > pacman 6 parallel downloads feature. When retrieving a large number of > quite small files with a quite good bandwidth, it interrupts the downloads, > fails, and I get the following error message: "failed to commit transaction > (download library error)". > > Are there any other messages before this? Usually there will be, if not > you can try with --debug. > > > As a computer science student, I would like to find the root cause of > this issue. I guess this is due to some critical race, as the issue > disappears when parallel downloads are disabled. > > As a first try, I have been following some wiki indications, building > pacman with debug symbols. However, I was unable to pinpoint the bug with > gdb, the log is very short with only creation and exits of the created > threads. > > Then, I have been building pacman-static, hoping to avoid some shared > libraries issues. This did not work either. > > This is likely due to the fact that I am not very experienced with gdb, > especially with the use of shared libraries and/or threads. > > > > I guess many people on this mailing-list could fix this bug, the only > reason I did not report it yet is because I do not have any precise log. > > In order to report it in a more precise way, I would like to have some > indications. > > Moreover, this could turn out to be quite instructive for me, and > perhaps for others as I would like to add some indications to the wiki > and/or other places. > > If you have online resources to recommend, please do. > > > > 1. How should I use gdb to get complete traces, including those of the > created threads? > > Parallel doesn't actually mean multi threaded. All the downloads are > done in one thread so you don't need to worry about that aspect. > > Generally to get a trace with gdb you run the program until it crashes > and then use bt to get a backtrace. However in this instance there is no > crash, instead the error is handled within pacman so you cant just > easily grab a backtrace. > > So instead you'd want to use breakpoints. I'd start by looking at > curl_download_internal(). > > Another tool that has helped me many times when debugging programs is `strace`. It shows the syscalls that a program is making. See `man strace` for more details :) Looking at syscalls doesn't help to debug logic errors, but it could show you if a connection issue (like a failed send or recv) triggers the bug. So it may or may not help you with this specific issue, but it is a very useful debugging tool to know about anyway. Kind regards, Maarte de Vries
