Historical bug tracker for the Pacman package manager.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
FS#66522 - SEGFAULT in libalpm.so.12
Attached to Project:
Pacman
Opened by Jonas Große Sundrup (cherti) - Sunday, 03 May 2020, 12:31 GMT
Last edited by Andrew Gregory (andrewgregory) - Tuesday, 19 May 2020, 19:57 GMT
Opened by Jonas Große Sundrup (cherti) - Sunday, 03 May 2020, 12:31 GMT
Last edited by Andrew Gregory (andrewgregory) - Tuesday, 19 May 2020, 19:57 GMT
|
Details# Summary and Info:
pacman-version: 5.2.1-4 pyalpm-version: 0.9.1-2 I am regularly, but not really reproducably unfortunately, running into a segfault within libalpm.so.12 when used via pyalpm. I have been running into this issue while writing blinky [0] and at least once this happened when this function [1] was called with 'python-mastodon' as an argument, see the trimmed down example below in the Steps to Reproduce. [0] https://github.com/cherti/blinky [1] https://github.com/cherti/blinky/blob/master/blinky/pacman.py#L25 Steps to Reproduce: This is a little difficult, in *theory*, the following code should trigger the issue (trimmed down blinky-logic to where it triggered in blinky), but doesn't: #!/usr/bin/env python3 import pyalpm, pycman handle = pycman.config.init_with_config('/etc/pacman.conf') ldb = handle.get_localdb() #sdbs.handle.get_syncdb() s = pyalpm.find_satisfier(ldb.pkgcache, 'python-mastodon') I haven't even been able to reliably reproduce the issue with blinky, in subsequent repetitions of the same command the segfault sometimes triggers and sometimes does not. Attached is everything I extracted from coredumpctl so far, in the hope that it might be useful. If there is anything you need or I could try to investigate the issue further, feel free to get back to me. Any directions of how to pin down the issue further are also greatly appreciated! |
This task depends upon
Closed by Andrew Gregory (andrewgregory)
Tuesday, 19 May 2020, 19:57 GMT
Reason for closing: Not a bug
Additional comments about closing: Reopen this if you can replicate in a single-threaded environment.
Tuesday, 19 May 2020, 19:57 GMT
Reason for closing: Not a bug
Additional comments about closing: Reopen this if you can replicate in a single-threaded environment.
blinkycoredump.txt
The backtrace is again attached, furthermore, I uploaded the complete coredump here:
https://share.cherti.org/398dfecbc3c180d08f5e/blinky.coredump
As I wasn't so far able to reproduce the issue in a slimmed down code, it's unfortunately the entirity of blinky still around it.
It again crashed in the same line in the blinky code as denoted in the report above, with a different package however, whereas the one noted in the Report above did not cause any problems.
If there is anything else I can do to help getting to the core of this, feel free to reach out!
I haven't observed the issue so far with the sync-DBs so far, only with the local one. Pure luck or is find_satisfier called on the sync-DBs in pyalpm (potentially accidentially) thread-safe because the sync-DBs are structured differently on disk?
Thanks a lot for taking a look into it!