Bug 1610542 - [hawkey/libsolv integration] dnf crashes when rpm-extension-full and -less arguments are combined
Summary: [hawkey/libsolv integration] dnf crashes when rpm-extension-full and -less ar...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: libdnf
Version: 29
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Marek Blaha
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-07-31 21:32 UTC by Jan Pokorný [poki]
Modified: 2018-12-14 17:24 UTC (History)
5 users (show)

Fixed In Version: libdnf-0.20.0
Clone Of:
Environment:
Last Closed: 2018-11-22 18:35:32 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1610456 0 unspecified CLOSED [hawkey] occasional segfault when interrupting (SIGINT) dnf process (may be caused by particular plugins in use, e.g. "l... 2021-02-22 00:41:40 UTC

Internal Links: 1610456

Description Jan Pokorný [poki] 2018-07-31 21:32:04 UTC
Example:
# dnf update foo.rpm bar
> Last metadata expiration check: 0:44:12 ago on Tue 31 Jul 2018 10:26:17 PM CEST.
> Can not load RPM file: foo.rpm.
> Segmentation fault (core dumped)

The most low-level explanation is a NULL pointer dereference
(most recent frames go first):

- brief stack trace (somewhat sifted by coredumpctl compared to
  58 frames shown in gdb; there was just a single thread):

> #0  0x00007f8d916f1f79 pool_whatprovides (libdnf.so.2)
> #1  0x00007f8d916f4d77 _ZN6libdnf5Query4Impl5applyEv (libdnf.so.2)
> #2  0x00007f8d916f5662 _ZN6libdnf5Query5emptyEv (libdnf.so.2)
> #3  0x00007f8d916f91d0 _ZN6libdnf8Solution15getBestSolutionEPKcP8_DnfSackP7_HyFormbbbbb (libdnf.so.2)
> #4  0x00007f8d91661203 hy_subject_get_best_solution (libdnf.so.2)
> #5  0x00007f8d8b0c93f6 get_best_parser (_hawkey.so)
> #6  0x00007f8d8b0c95cb get_best_solution (_hawkey.so)
> #7  0x00007f8d92936084 _PyMethodDef_RawFastCallKeywords (libpython3.7m.so.1.0)
> #8  0x00007f8d9295f69d _PyMethodDescr_FastCallKeywords (libpython3.7m.so.1.0)
> #9  0x00007f8d9299881b call_function (libpython3.7m.so.1.0)
> #10 0x00007f8d928ef8e6 _PyEval_EvalCodeWithName (libpython3.7m.so.1.0)
> #11 0x00007f8d92935971 _PyFunction_FastCallKeywords (libpython3.7m.so.1.0)
> #12 0x00007f8d92993ab4 call_function (libpython3.7m.so.1.0)
> #13 0x00007f8d929357ca function_code_fastcall (libpython3.7m.so.1.0)
> #14 0x00007f8d92993ab4 call_function (libpython3.7m.so.1.0)
> #15 0x00007f8d929357ca function_code_fastcall (libpython3.7m.so.1.0)
> #16 0x00007f8d92993ab4 call_function (libpython3.7m.so.1.0)
> #17 0x00007f8d929357ca function_code_fastcall (libpython3.7m.so.1.0)
> #18 0x00007f8d92993ab4 call_function (libpython3.7m.so.1.0)
> #19 0x00007f8d929357ca function_code_fastcall (libpython3.7m.so.1.0)
> #20 0x00007f8d92993c69 call_function (libpython3.7m.so.1.0)
> #21 0x00007f8d929357ca function_code_fastcall (libpython3.7m.so.1.0)
> #22 0x00007f8d92993c69 call_function (libpython3.7m.so.1.0)
> #23 0x00007f8d928ef8e6 _PyEval_EvalCodeWithName (libpython3.7m.so.1.0)
> #24 0x00007f8d92935971 _PyFunction_FastCallKeywords (libpython3.7m.so.1.0)
> #25 0x00007f8d92993c69 call_function (libpython3.7m.so.1.0)
> #26 0x00007f8d928ef8e6 _PyEval_EvalCodeWithName (libpython3.7m.so.1.0)
> #27 0x00007f8d92935971 _PyFunction_FastCallKeywords (libpython3.7m.so.1.0)
> #28 0x00007f8d92994a85 call_function (libpython3.7m.so.1.0)
> #29 0x00007f8d928ef8e6 _PyEval_EvalCodeWithName (libpython3.7m.so.1.0)
> #30 0x00007f8d928f08a3 PyEval_EvalCodeEx (libpython3.7m.so.1.0)
> #31 0x00007f8d928f08cb PyEval_EvalCode (libpython3.7m.so.1.0)
> #32 0x00007f8d92a199ae run_mod (libpython3.7m.so.1.0)
> #33 0x00007f8d92a19d46 PyRun_FileExFlags (libpython3.7m.so.1.0)
> #34 0x00007f8d92a1be08 PyRun_SimpleFileExFlags (libpython3.7m.so.1.0)
> #35 0x00007f8d92a1d7a2 pymain_run_file (libpython3.7m.so.1.0)
> #36 0x00007f8d92a1e0e0 _Py_UnixMain (libpython3.7m.so.1.0)
> #37 0x00007f8d9248f0e3 __libc_start_main (libc.so.6)
> #38 0x00005605f7e3d08a _start (python3.7)

- detailed trace of the 4 most recent frames:
> #0  0x00007f8d916f1f79 in pool_whatprovides (d=18721, pool=0x5605f9e75ea0) at /usr/include/solv/pool.h:327
>           r_id = 18721
>           match_in = {
>           num = 18721,
>           pset = <optimized out>,
>           reldep = 18721,
>           str = <optimized out>
>           }
>           __for_range = <optimized out>
>           pool = 0x5605f9e75ea0
>           p = <optimized out>
>           pp = <optimized out>

> 323│ static inline Id pool_whatprovides(Pool *pool, Id d)
> 324│ {
> 325│   if (!ISRELDEP(d))
> 326│     {
> 327├>      if (pool->whatprovides[d])
> 328│         return pool->whatprovides[d];
> 329│     }

> (gdb) p *pool
>> $1 = {
>>   appdata = 0x0,
>>   [...]
>>   whatprovides = 0x0,
>>   [...]
>> }
> (gdb) p d
>> $2 = 18721

> #1  0x00007f8d916f1f79 in libdnf::Query::Impl::filterProvidesReldep(libdnf::Filter const&, _Map*) (this=this@entry=0x5605f9ebd710, f=..., m=m@entry=0x7fffda91bd20) at /usr/src/debug/libdnf-0.16.1-2.fc29.x86_64/libdnf/sack/query.cpp:1407
>           r_id = 18721
>           match_in = {
>           num = 18721,
>           pset = <optimized out
>,
>           reldep = 18721,
>           str = <optimized out>
>           }
>           __for_range = <optimized out>
>           pool = 0x5605f9e75ea0
>           p = <optimized out>
>           pp = <optimized out>

> 1398│ void
> 1399│ Query::Impl::filterProvidesReldep(const Filter & f, Map *m)
> 1400│ {
> 1401│     Pool *pool = dnf_sack_get_pool(sack);
> 1402│     Id p, pp;
> 1403│
> 1404│     dnf_sack_make_provides_ready(sack);
> 1405│     for (auto match_in : f.getMatches()) {
> 1406│         Id r_id = match_in.reldep;
> 1407├>        FOR_PROVIDES(p, pp, r_id)
> 1408│             MAPSET(m, p);
> 1409│     }
> 1410│ }

> #2  0x00007f8d916f4d77 in libdnf::Query::Impl::apply() (this=0x5605f9ebd710) at /usr/src/debug/libdnf-0.16.1-2.fc29.x86_64/libdnf/sack/query.cpp:1800
>           f = {
>           pImpl = std::shared_ptr<libdnf::Filter::Impl
> (use count 2, weak count 0) = {
>             get() = 0x5605f9e5c7c0
>           }
>        	}
>        	__for_range = std::vector of length 1, capacity 1 = {{
>             pImpl = std::shared_ptr<libdnf::Filter::Impl
> (use count 2, weak count 0) = {
>               get() = 0x5605f9e5c7c0
>             }
>           }} 
>           pool = <optimized out>
>           m = {
>           map = 0x5605fa1a6f90 "",
>        	  size = 7595
>           }
>           __PRETTY_FUNCTION__ = "void libdnf::Query::Impl::apply()"

> 1798│             case HY_PKG_PROVIDES:
> 1799│                 assert(f.getMatchType() == _HY_RELDEP);
> 1800├>                filterProvidesReldep(f, &m);
> 1801│                 break;

> #3  0x00007f8d916f54ec in libdnf::Query::apply() (this=this@entry=0x5605f9e795d0) at /usr/include/c++/8/bits/unique_ptr.h:342

> 340│	   /// Return the stored pointer.
> 341│	   pointer
> 342├>      get() const noexcept
> 343│	   { return _M_t._M_ptr(); }

Note the other hawkey-related issue (_hawkey.so present in the trace
as well): [bug 1610456]

Comment 2 Jan Kurik 2018-08-14 11:13:18 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle.
Changing version to '29'.


Note You need to log in before you can comment on or make changes to this bug.