[pacman-dev] Seeking help to report and resolve a pacman bug with parallel downloads

[Maarten de Vries]

On Sat, 12 Jun 2021 at 20:52, Morgan Adamiec <morganamilo at archlinux.org>
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