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

[Morgan Adamiec]

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().

> 2. I am so far not using breakpoints, I would only like to have the complete call graph, including those of the created threads. Is this a reasonable approach when trying to address a not-yet-narrowed-down bug, especially with shared libraries? Do I need some other tools, modifying LD_PRELOAD, etc?

Just build and run pacman from git. ALPM is part of the repo so there's
no need to worry about libraries.

> 3. What is the recommended way of handling symbols from several symbols tables?

Just run gdb and it should figure everything out.

> 4. Is there already some sanitizer such as TSAN in use for pacman development? If not, is this something planned, or are they reasons against using such tools?
> 5. Last but not least, many tests used in the PKGBUILD check function unexpectedly fail when I build pacman locally. Is this normal? If not, I can attach the log in another email, even though I guess it should be quite reproducible.

Works for me!

> Any piece of advice about how to do such things, what is your usual workflow with gdb (and perhaps other debuggers), more generally what is your workflow to find the cause of bugs, would be of great help.
> Thank you very much for all of the pacman development.
> 
> Best regards,
> atn19
>