[Bug 1181471] New: libcurl hangs in a __poll below curl_easy_cleanup
https://bugzilla.suse.com/show_bug.cgi?id=1181471 Bug ID: 1181471 Summary: libcurl hangs in a __poll below curl_easy_cleanup Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: aarch64 OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Network Assignee: screening-team-bugs@suse.de Reporter: ma@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- Hi Predro, a puzzle for the curl maintainers. I'm lost how to further investigate it. Maybe you've got an idea: [https://github.com/openSUSE/zypper/issues/364] - 'Proot' is used to chroot into an openSUSE TW system. This might be the reason, at least ZYPP never received a similar issue report, neither on aarch64 nor on any other architecture. From within the system, libzypp (via libcurl) is able to connect to e.g. download. opensuse.org (the log shows a successful head request). But when closing the connection libcurl reproducible hangs below a call to curl_easy_cleanup (for 20+ minutes before killing zypper). A stacktrace created by libzypp shows curl_easy_cleanup staying in a call to poll:
[bt]: (0) /lib64/libc.so.6 : __poll+0xec [0x7f8a71618c] [bt]: (1) /usr/lib64/libcurl.so.4 : +0x5e088 [0x7f8a54f088] [bt]: (2) /usr/lib64/libcurl.so.4 : +0x6024c [0x7f8a55124c] [bt]: (3) /usr/lib64/libcurl.so.4 : +0x47240 [0x7f8a538240] [bt]: (4) /usr/lib64/libcurl.so.4 : +0x4740c [0x7f8a53840c] [bt]: (5) /usr/lib64/libcurl.so.4 : +0x1a3c4 [0x7f8a50b3c4] [bt]: (6) /usr/lib64/libcurl.so.4 : +0x6e7d0 [0x7f8a55f7d0] [bt]: (7) /usr/lib64/libcurl.so.4 : curl_easy_cleanup+0x40 [0x7f8a506db0] [bt]: (8) /usr/lib64/libzypp.so.1722 : zypp::media::MediaCurl::disconnectFrom()+0x2c [0x7f8ada0bdc] [bt]: (9) /usr/lib64/libzypp.so.1722 : zypp::media::MediaHandler::disconnect()+0x34 [0x7f8ad8bab4]
The same is seen in the strace log:
https://github.com/openSUSE/zypper/files/5856500/zypper.strace.log.zip (search for 'Releasing media http<http://download.opensuse.org'
After writing the log line libzypp calls curl_easy_cleanup. Then you see just an endless loop of ppoll calls. Any idea/hint how to circumvent this is welcome. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1181471 Michael Andres <ma@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |zypp-maintainers@suse.de Assignee|screening-team-bugs@suse.de |pmonrealgonzalez@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1181471 https://bugzilla.suse.com/show_bug.cgi?id=1181471#c1 Pedro Monreal Gonzalez <pmonrealgonzalez@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pmonrealgonzalez@suse.com --- Comment #1 from Pedro Monreal Gonzalez <pmonrealgonzalez@suse.com> --- Hi Michael. It seems its waiting for some fd to be available. What is ejectDev in MediaHandler::release() ? Maybe this is transitional. In any case, how can I reproduce this to gdb it? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1181471 https://bugzilla.suse.com/show_bug.cgi?id=1181471#c2 --- Comment #2 from Michael Andres <ma@suse.com> --- (In reply to Pedro Monreal Gonzalez from comment #1)
Hi Michael. It seems its waiting for some fd to be available.
The strace shows that poll is called without any FDs to watch: ppoll(NULL, 0, {tv_sec=0, tv_nsec=1000000}, NULL, 0) = 0 (Timeout) Might be used as a mini-timer.
What is ejectDev in MediaHandler::release() ?
The MediaHandler API is abstract. ejectDev is not evaluated by MediaCurl (MediaCD would eject this device after disconnect/umount). For MediaCurl MediaHandler::release is MediaCurl::disconnectFrom: if ( _customHeaders ) { curl_slist_free_all(_customHeaders); _customHeaders = 0L; } if ( _curl ) { curl_easy_cleanup( _curl ); _curl = NULL; }
Maybe this is transitional.
@radumamy (reporter of zypper/issues/364) waited for more than 20 Min. In fact I never ever saw a behavior like this on disconnecting.
In any case, how can I reproduce this to gdb it?
That's the question (I asked @radumamy to joint his bug). He wrote that TW is running inside chroot environment via proot (https://proot-me.github.io). If I find proot for my Leap I'll give it a try. But I've got no aarch64 in case it's arch/host specific. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1181471 https://bugzilla.suse.com/show_bug.cgi?id=1181471#c5 Sebastian Parschauer <sebastian.parschauer@instana.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #5 from Sebastian Parschauer <sebastian.parschauer@instana.com> --- Closing as WONTFIX as nobody dares to apply the fix. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com