Pacman

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.
Tasklist

FS#10873 - libalpm segfaul

Attached to Project: Pacman
Opened by Martin Sandsmark (sandsmark) - Wednesday, 09 July 2008, 12:47 GMT
Last edited by Dan McGee (toofishes) - Saturday, 09 August 2008, 15:17 GMT
Task Type Bug Report
Category General
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version 3.1.3
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Summary and Info:
Shaman segfaults while handling repositories. After hunting this bug with one of the Shaman developers (drf), we concluded that it must be in libalpm.

Steps to Reproduce:
Relevant parts from the backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f491b08a760 (LWP 8995)]
0x00007f4918847049 in readdir64 () from /lib/libc.so.6
(gdb) backtrace full
#0 0x00007f4918847049 in readdir64 () from /lib/libc.so.6
No symbol table info available.
#1 0x00007f49196e4e8d in _alpm_db_scan () from /usr/lib/libalpm.so.2
No symbol table info available.
#2 0x00007f49196e56f6 in _alpm_db_load_pkgcache () from /usr/lib/libalpm.so.2
No symbol table info available.
#3 0x00007f49196e5755 in _alpm_db_get_pkgcache () from /usr/lib/libalpm.so.2
No symbol table info available.
#4 0x00007f49196e578e in _alpm_db_get_pkgfromcache () from /usr/lib/libalpm.so.2
No symbol table info available.
#5 0x0000000000437a7b in AlpmHandler::isInstalled (this=0x1e69af0, pkg=<value optimized out>) at /root/tmp2/shaman/src/AlpmHandler.cpp:627
localpackage = <value optimized out>
In full: http://iskrembilen.com/sandsmark/gdb-shaman.log

Relevant part of the Shaman source:
QStringList AlpmHandler::getAvailableReposNames()
{
alpm_list_t *dbs = sync_databases; // Tried replacing with alpm_option_get_syncdbs()
QStringList retlist;

retlist.clear();
dbs = alpm_list_first(dbs);

while(dbs != NULL)
{
retlist.append(alpm_db_get_name((pmdb_t *) alpm_list_getdata(dbs))); // Goes forth and segfaults
dbs = alpm_list_next(dbs);
}

return retlist;
}

In full: http://shaman-arch.svn.sourceforge.net/viewvc/shaman-arch/trunk/shaman/src/AlpmHandler.cpp?revision=780&view=markup

I am on x86_64 with gcc 4.3.1, Pacman v3.1.4/libalpm v2.3.1.
This task depends upon

Closed by  Dan McGee (toofishes)
Saturday, 09 August 2008, 15:17 GMT
Reason for closing:  Deferred
Additional comments about closing:  No feedback. If this is still a bug with the 3.2.0 source, please open a new bug and provide a backtrace with line numbers if possible.
Comment by Nagy Gabor (combo) - Wednesday, 09 July 2008, 21:38 GMT
I can't see why that part is relevant.
From alpm side, alpm_db_get_name cannot cause a segfault (in 3.1.4, we used static treename), even if you call on wrong param.
Comment by Xavier (shining) - Thursday, 10 July 2008, 06:06 GMT
The part of the code he showed doesn't match the backtrace, if you look.
The function called is not getAvailableRepoName, but AlpmHandler::isInstalled, in the same AlpmHandler.cpp file, which does this :
618 pmpkg_t *localpackage = alpm_db_get_pkg(db_local, alpm_pkg_get_name(pkg));
So from that call, there are several alpm_db_* functions called, as you can see in the trace, and finally alpm_db_scan, which does a readdir of db->handle.
So if this value is null, readdir might cause a segfault.

It would probably help to use debug shaman and libalpm with debug symbols, so that the value of db and db->handle can be inspected.
Comment by Dan McGee (toofishes) - Thursday, 24 July 2008, 02:27 GMT
Any feedback here?

Loading...