Segfault with dependency cycle #7
Labels
Comments
|
Ah IteratePackages doesn't seem to protect against loops. |
|
Err no... it's the InMemoryRepo which doesn't properly protect against loops... Easily fixed. |
|
I'd also suggest to add an error or warning message, since as it is the build chain is not buildable. Granted, this is a very edgy case. |
falconindy
added a commit
that referenced
this issue
Sep 4, 2020
Originally, I wanted to address the following problem:
When a user callback indicates failure, calling CancelAll() means that
we end up (re)invoking a curl socket callback from a socket callback,
leading to a double free (either in sd-event or curl). One possible
backtrace looks like:
(gdb) bt
-> #0 aur::AurImpl::DispatchSocketCallback (this=0x618000000480, s=<optimized out>, action=4, io=<optimized out>) at ../src/aur/aur.cc:330
#1 0x00007ffff74fa4e1 in singlesocket () from /usr/lib/libcurl.so.4
#2 0x00007ffff74fe622 in curl_multi_remove_handle () from /usr/lib/libcurl.so.4
#3 0x000055555570e833 in aur::AurImpl::FinishRequest (this=<optimized out>, curl=0x623000005500, result=<optimized out>, dispatch_callback=<optimized out>) at ../src/aur/aur.cc:462
#4 0x0000555555708cc1 in std::__do_visit<std::__detail::__variant::__deduce_visit_result<void>, aur::AurImpl::Cancel(const value_type&)::Visitor, const std::variant<void*, sd_event_source*>&> (__visitor=...) at /usr/include/c++/10.2.0/variant:869
#5 std::visit<aur::AurImpl::Cancel(const value_type&)::Visitor, const std::variant<void*, sd_event_source*>&> (__visitor=...) at /usr/include/c++/10.2.0/variant:1710
#6 aur::AurImpl::Cancel (this=0x618000000480, request=...) at ../src/aur/aur.cc:291
#7 0x00005555557090f6 in aur::AurImpl::CancelAll (this=0x618000000480) at ../subprojects/abseil-cpp-20200225.2/absl/container/internal/raw_hash_set.h:311
#8 0x000055555570f08d in aur::AurImpl::CheckFinished (this=0x618000000480) at ../src/aur/aur.cc:485
-> #9 0x000055555570f341 in aur::AurImpl::DispatchSocketCallback (this=0x618000000480, s=<optimized out>, action=4, io=<optimized out>) at ../src/aur/aur.cc:332
#10 0x00007ffff74fb092 in Curl_multi_closed () from /usr/lib/libcurl.so.4
#11 0x00007ffff74cc631 in Curl_closesocket () from /usr/lib/libcurl.so.4
#12 0x00007ffff74df551 in Curl_disconnect () from /usr/lib/libcurl.so.4
#13 0x00007ffff74fc354 in multi_done () from /usr/lib/libcurl.so.4
#14 0x00007ffff74fcc91 in multi_runsingle () from /usr/lib/libcurl.so.4
#15 0x00007ffff74fe1d1 in multi_socket () from /usr/lib/libcurl.so.4
#16 0x00007ffff74fe354 in curl_multi_socket_action () from /usr/lib/libcurl.so.4
#17 0x000055555570f60d in aur::AurImpl::OnCurlTimer (userdata=0x618000000480) at ../src/aur/aur.cc:401
#18 0x00007ffff7466b3e in ?? () from /usr/lib/libsystemd.so.0
#19 0x00007ffff746821e in sd_event_dispatch () from /usr/lib/libsystemd.so.0
#20 0x00007ffff746a6a9 in sd_event_run () from /usr/lib/libsystemd.so.0
#21 0x0000555555704bd3 in aur::AurImpl::Wait (this=0x618000000480) at ../src/aur/aur.cc:495
#22 0x000055555563ee8a in auracle::Auracle::GetOutdatedPackages (this=<optimized out>, args=std::vector of length 0, capacity 0, packages=<optimized out>) at /usr/include/c++/10.2.0/bits/unique_ptr.h:421
#23 0x0000555555656816 in auracle::Auracle::Outdated (this=<optimized out>, args=..., options=...) at ../src/auracle/auracle.cc:564
#24 0x0000555555596c7f in main (argc=<optimized out>, argv=<optimized out>) at ../subprojects/abseil-cpp-20200225.2/absl/container/internal/raw_hash_set.h:311
We could do that by making CancelAll() merely schedule another event
that performs the actual cancellation at a later point in order to avoid
the recursion. However, our cancellation logic is all sorts of weird and
makes assumptions about how events are dispatched (i.e. there might be
multiple at a time). Let's just get rid of all of this and use the
sd-event mechanism of sd_event_exit instead.
This does, however (as did the original proposed solution), have the
side effect of logging multiple times because we potentially open up to
5 connections to the AUR at once, e.g.
$ build/auracle --baseurl http://129.168.255.1 outdated
error: UNKNOWN: Connection timed out after 10000 milliseconds
error: UNKNOWN: Connection timed out after 10000 milliseconds
I suppose one way to fix this would be to do response merging on the
backend to match the request splitting. That way, the frontend only gets
one response. I think that comes with a lot of weird potential behaviors
though (handling of partial failures, to mention one). Would be nicer if
the AUR didn't have the crap behavior and could take POST requests in
order to extend the arg limit.
Whatever, this is a weird edge case.
Fixes #82.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Installing the
mingw-w64-freetype2package results in a dependency cycle, which produces a segfault instead of a nicer error message.Note the dependency cycle is
mingw-w64-freetype2 -> mingw-w64-harfbuzz -> mingw-w64-freetype2, but isn't exacly a PKGBUILD error, as the chain is supposed to be bootstrapped with themingw-w64-freetype2-bootstrappackage.The text was updated successfully, but these errors were encountered: