You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@openoffice.apache.org by bu...@apache.org on 2024/02/11 12:13:06 UTC
[Issue 128591] New: After WebDAV provider was changed to Curl+OpenSSL, automatic updates crash shortly after startup
https://bz.apache.org/ooo/show_bug.cgi?id=128591
Issue ID: 128591
Issue Type: DEFECT
Summary: After WebDAV provider was changed to Curl+OpenSSL,
automatic updates crash shortly after startup
Product: General
Version: 4.5.0-dev
Hardware: All
OS: All
Status: CONFIRMED
Severity: Normal
Priority: P5 (lowest)
Component: code
Assignee: issues@openoffice.apache.org
Reporter: damjan@apache.org
Target Milestone: ---
Multiple users report how after our WebDAV content provider was changed from
Serf+APR to Curl+OpenSSL, OpenOffice started crashing shortly after startup,
either when automatically checking for updates, or when they clicked "Help" ->
"Check for Updates".
In my dev@ email, I outlined a possible cause:
https://lists.apache.org/thread/4p6fqlhmwbjnr97hn4t96rz3566bbq19
which is Curl using a wrong CA certificate path auto-detected at compile time,
which we should override.
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 128591] After WebDAV provider was changed to Curl+OpenSSL, automatic updates crash shortly after startup
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=128591
--- Comment #3 from damjan@apache.org ---
This was a stack trace posted by a user long ago, note how Curl calls OpenSSL
before our custom verification callback, and crashes by invalid memory access
(address 0x1 at the top):
#0 0x0000000000000001 in ()
#1 0x00007fffd7a13d38 in () at
/lib64/libssl.so.1.1
#2 0x00007fffd7a142b1 in () at
/lib64/libssl.so.1.1
#3 0x00007fffd7a48437 in () at
/lib64/libssl.so.1.1
#4 0x00007fffd7a3f8d6 in () at
/lib64/libssl.so.1.1
#5 0x00007fffd7be5206 in () at
/usr/lib64/libcurl.so.4
#6 0x00007fffd7be9bda in () at
/usr/lib64/libcurl.so.4
#7 0x00007fffd7beace5 in () at
/usr/lib64/libcurl.so.4
#8 0x00007fffd7ba4396 in () at
/usr/lib64/libcurl.so.4
#9 0x00007fffd7bbbcec in () at
/usr/lib64/libcurl.so.4
#10 0x00007fffd7bbcd3e in curl_multi_perform ()
at /usr/lib64/libcurl.so.4
#11 0x00007fffd7b9515b in curl_easy_perform ()
at /usr/lib64/libcurl.so.4
#12 0x00007fffd5c9ef92 in
http_dav_ucp::CurlRequest::perform()
(this=this@entry=0x7fffed7d3610)
at
/d/home/ty/c/+ooo/aoo45/main/ucb/source/ucp/webdav/CurlRequest.cxx:266
#13 0x00007fffd5c9f222 in
http_dav_ucp::CurlRequest::get(http_dav_ucp::CurlUri,
rtl::OUString)
(this=this@entry=0x7fffed7d3610, uri=...,
path=...) at
/d/home/ty/c/+ooo/aoo45/main/ucb/source/ucp/webdav/CurlRequest.cxx:189
#14 0x00007fffd5c9c2db in
http_dav_ucp::CurlSession::GET(rtl::OUString
const&, std::vector<rtl::OUString,
std::allocator<rtl::OUString> > const&,
http_dav_ucp::DAVResource&,
http_dav_ucp::DAVRequestEnvironment const&)
(this=this@entry=0x7fffd7e505b0,
inPath=<optimized out>,
inHeaderNames=std::vector of length 0, capacity
0, ioResource=..., rEnv=...) at
/d/home/ty/c/+ooo/aoo45/main/ucb/source/ucp/webdav/CurlSession.cxx:1128
#15 0x00007fffd5c8a608 in
http_dav_ucp::DAVResourceAccess::GET(std::vector<rtl::OUString,
std::allocator<rtl::OUString> > const&,
http_dav_ucp::DAVResource&,
com::sun::star::uno::Reference<com::sun::star::ucb::XCommandEnvironment>
const&)
(this=0x7fffd5fa2ec0,
rHeaderNames=std::vector of length 0, capacity
0, rResource=..., xEnv=...)
at
/d/home/ty/c/+ooo/aoo45/main/ucb/source/ucp/webdav/DAVResourceAccess.cxx:443
#16 0x00007fffd5c76358 in
http_dav_ucp::Content::open(com::sun::star::ucb::OpenCommandArgument2
const&,
com::sun::star::uno::Reference<com::sun::star::ucb::XCommandEnvironment>
const&) (this=this@entry=0x7fffd7e504b0,
rArg=..., xEnv=...)
at
/d/home/ty/c/+ooo/aoo45/main/ucb/source/ucp/webdav/webdavcontent.cxx:2282
#17 0x00007fffd5c7950d in
http_dav_ucp::Content::execute(com::sun::star::ucb::Command
const&, int,
com::sun::star::uno::Reference<com::sun::star::ucb::XCommandEnvironment>
const&) (this=0x7fffd7e504b0,
aCommand=<optimized out>, Environment=...)
at
/d/home/ty/c/+ooo/aoo45/main/ucb/source/ucp/webdav/webdavcontent.cxx:621
#18 0x00007fffd5f547d0 in (anonymous
namespace)::UpdateInformationProvider::load(rtl::OUString
const&)
(this=0x7fffd5f8ce50, rURL=<optimized out>)
at
/d/home/ty/c/+ooo/aoo45/main/extensions/source/update/feed/updatefeed.cxx:516
#19 0x00007fffd5f553e4 in (anonymous
namespace)::UpdateInformationProvider::getUpdateInformationEnumeration(com::sun::star::uno::Sequence<rtl::OUString>
const&, rtl::OUString const&)
(this=0x7fffd5f8ce50, repositories=<optimized
out>, extensionId=...)
at
/d/home/ty/c/+ooo/aoo45/main/extensions/source/update/feed/updatefeed.cxx:616
#20 0x00007fffd7cb9c4c in
checkForUpdates(UpdateInfo&,
com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext>
const&,
com::sun::star::uno::Reference<com::sun::star::task::XInteractionHandler>
const&,
com::sun::star::uno::Reference<com::sun::star::deployment::XUpdateInformationProvider>
const&) (o_rUpdateInfo=..., rxContext=...,
rxInteractionHandler=..., rUpdateInfoProvider=...)
at
/d/home/ty/c/+ooo/aoo45/main/extensions/source/update/check/updateprotocol.cxx:130
#21 0x00007fffd7cb0128 in (anonymous
namespace)::UpdateCheckThread::runCheck(bool&)
(this=0x7fffd6010a60,
rbExtensionsChecked=@0x7fffed7d3d4f: false)
at
/d/home/ty/c/+ooo/aoo45/main/extensions/source/update/check/updatecheck.cxx:458
#22 0x00007fffd7cb05c5 in (anonymous
namespace)::UpdateCheckThread::run()
(this=0x7fffd6010a60)
at
/d/home/ty/c/+ooo/aoo45/main/extensions/source/update/check/updatecheck.cxx:566
#23 0x00007fffd7cb098a in osl::threadFunc(void*)
(param=0x7fffd6010a60)
at
/d/home/ty/c/+ooo/aoo45/main/solver/450/unxlngx6.pro/inc/osl/thread.hxx:184
#24 0x00007ffff7df7219 in osl_thread_start_Impl
(pData=0x7fffd0005d10) at thread.c:266
#25 0x00007ffff7715fea in start_thread () at
/lib64/libc.so.6
#26 0x00007ffff77a09ec in clone3 () at
/lib64/libc.so.6
#24 0x00007ffff7df7219 in osl_thread_start_Impl
(pData=0x7fffd0005d10) at thread.c:266
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 128591] After WebDAV provider was changed to Curl+OpenSSL, automatic updates crash shortly after startup
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=128591
--- Comment #7 from damjan@apache.org ---
(In reply to Matthias Seidel from comment #6)
> Has this ever been backported into AOO42X?
Yes it was cherry-picked into AOO42X with commit
0ec0f743104c26d8c7b0517fbfa228daea0afc51.
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 128591] After WebDAV provider was changed to Curl+OpenSSL, automatic updates crash shortly after startup
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=128591
damjan@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |crash
--- Comment #5 from damjan@apache.org ---
Is this still an issue in the latest OpenOffice?
It should have been fixed by this patch:
commit f7b97bf7d9139c8b602d3da3aadbeef0631e39c1
Author: Damjan Jovanovic <da...@...>
Date: Sun Apr 21 17:07:24 2024 +0200
Override OpenSSL's certificate verification with our own, instead of
using its verification and selectively overriding the result.
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 128591] After WebDAV provider was changed to Curl+OpenSSL, automatic updates crash shortly after startup
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=128591
--- Comment #2 from damjan@apache.org ---
(In reply to sundialservices from comment #1)
> I agree that it is probably the same issue. (Problem #128535.)
>
> The real problem here is that OpenOffice allows an exception to percolate
> all the way to the top – to the operating system, which responds by killing
> the entire process. No matter what actually happens during the "automatic
> update" process, OO should "try" it, and "catch" anything that goes wrong.
> Right now it doesn't.
Access to invalid memory doesn't cause a friendly "exception", it is the
SIGSEGV signal, recovery from which is possible but very difficult (signal
handlers, custom stacks, changing CPU registers, machine code), and can still
leak memory or compromise security.
A better solution is to prevent the incorrect memory access in the first place.
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 128591] After WebDAV provider was changed to Curl+OpenSSL, automatic updates crash shortly after startup
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=128591
--- Comment #8 from Matthias Seidel <ms...@apache.org> ---
OK, thanks!
On Windows I never experienced hangs...
macOS was affected, but the available builds are too old to test.
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 128591] After WebDAV provider was changed to Curl+OpenSSL, automatic updates crash shortly after startup
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=128591
--- Comment #4 from sundialservices <mi...@sundialservices.com> ---
I yield without further comment to other people's greater knowledge of how to
keep issues like these from crashing the entire program.
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 128591] After WebDAV provider was changed to Curl+OpenSSL, automatic updates crash shortly after startup
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=128591
Matthias Seidel <ms...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bz.apache.org/ooo/s
| |how_bug.cgi?id=128535
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 128591] After WebDAV provider was changed to Curl+OpenSSL, automatic updates crash shortly after startup
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=128591
Matthias Seidel <ms...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mseidel@apache.org
--- Comment #6 from Matthias Seidel <ms...@apache.org> ---
Has this ever been backported into AOO42X?
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 128591] After WebDAV provider was changed to Curl+OpenSSL, automatic updates crash shortly after startup
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=128591
sundialservices <mi...@sundialservices.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |miker@sundialservices.com
--- Comment #1 from sundialservices <mi...@sundialservices.com> ---
I agree that it is probably the same issue. (Problem #128535.)
The real problem here is that OpenOffice allows an exception to percolate all
the way to the top – to the operating system, which responds by killing the
entire process. No matter what actually happens during the "automatic update"
process, OO should "try" it, and "catch" anything that goes wrong. Right now it
doesn't.
--
You are receiving this mail because:
You are the assignee for the issue.