Description: I have to say I have no idea what I am doing with the Data Provider (the help page in LibreOffice Help does not... help much), but I thought it is worth reporting this crash even if I am misusing the tool. Using the data provider, adding a URL, selecting a provider and clicking "Apply Changes" crashes the whole of LibreOffice. Steps to Reproduce: 1. Open Calc 2. Use Data > Data Provider... 3. Choose a HTML Data Provider in the drop down 4. paste a URL in the URL text box, for example https://en.wikipedia.org/wiki/QS_World_University_Rankings 5. Click the yellow button to "Apply Change" Actual Results: LibreOffice crashes (Calc and Writer closed), Data Provider Dialogue stays up but does not respond, closing the dialogue asks if we want to force to force quit because LibreOffice is not responding. Expected Results: Not sure... :) Reproducible: Always User Profile Reset: No Additional Info: Tested with: Version: 6.3.1.2 Build ID: 1:6.3.1~rc2-0ubuntu0.18.04.1~lo1 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: en-AU (en_AU.UTF-8); UI-Language: en-GB Calc: threaded Not sure if OpenGL is activated as the wording in the wiki does not match the wording in the LibreOffice options: https://wiki.documentfoundation.org/OpenGL#How_to_enable.2Fdisable_OpenGL
Created attachment 154065 [details] bt Windows (windbg) On Win10 with master sources updated yesterday, I could reproduce this. I noticed this log on console: warn:ucb.ucp.webdav:4788:10192:ucb/source/ucp/webdav-neon/NeonSession.cxx:1870: Neon returned NE_ERROR, http response status code was: 405 '405 Method not allowed' warn:ucb.ucp.webdav:4788:10192:ucb/source/ucp/webdav-neon/webdavcontent.cxx:4069: OPTIONS - SC_NOT_IMPLEMENTED or SC_METHOD_NOT_ALLOWED for URL <https://en.wikipedia.org/wiki/QS_World_University_Rankings>, HTTP error: 405, '405 Method not allowed' HTML parser error : Tag wbr invalid "nofollow" class="external text" href="https://www.topuniversities.com">www<wbr ^ HTML parser error : Tag wbr invalid nal text" href="https://www.topuniversities.com">www<wbr />.topuniversities<wbr ^ XPath error : Invalid expression
This patch prevents from crashing: diff --git a/sc/source/ui/dataprovider/htmldataprovider.cxx b/sc/source/ui/dataprovider/htmldataprovider.cxx index bbe6dd3c514b..30ae31bc3759 100644 --- a/sc/source/ui/dataprovider/htmldataprovider.cxx +++ b/sc/source/ui/dataprovider/htmldataprovider.cxx @@ -192,6 +192,13 @@ void HTMLFetchThread::execute() OString aID = OUStringToOString(maID, RTL_TEXTENCODING_UTF8); xmlXPathContextPtr pXmlXpathCtx = xmlXPathNewContext(pHtmlPtr); xmlXPathObjectPtr pXmlXpathObj = xmlXPathEvalExpression(BAD_CAST(aID.getStr()), pXmlXpathCtx); + + if (!pXmlXpathObj) + { + xmlXPathFreeContext(pXmlXpathCtx); + return; + } + xmlNodeSetPtr pXmlNodes = pXmlXpathObj->nodesetval; if (pXmlNodes->nodeNr == 0) However, there's no error message or something.
I can't reproduce it in Version: 6.4.0.0.alpha0+ Build ID: f4f8bccbd4e2c3979a83d5b2f49e16a99a3a2016 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: x11; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded
On pc Debian x86-64 with master sources updated today + gtk3, gen or kf5 rendering, the droplist to select a provider is empty! I noticed this on console: warn:vcl:989:989:vcl/source/window/menu.cxx:423: Menu::InsertItem(): ItemId == 0 I'll check if this log is there on Windows tomorrow.
(In reply to Julien Nabet from comment #4) > On pc Debian x86-64 with master sources updated today + gtk3, gen or kf5 > rendering, the droplist to select a provider is empty! > I noticed this on console: > warn:vcl:989:989:vcl/source/window/menu.cxx:423: Menu::InsertItem(): ItemId > == 0 > I'll check if this log is there on Windows tomorrow. Forget my last comment.
On pc Debian x86-64 with master sources updated today, I could reproduce the crash too. Here's the short bt: [Switching to Thread 0x7fffe07bd700 (LWP 3912)] 0x00007fffddab3e26 in sc::HTMLFetchThread::execute (this=0x555559290dc0) at /home/julien/lo/libreoffice/sc/source/ui/dataprovider/htmldataprovider.cxx:195 195 xmlNodeSetPtr pXmlNodes = pXmlXpathObj->nodesetval; (gdb) p pXmlXpathObj $1 = (xmlXPathObjectPtr) 0x0 (gdb) bt #0 0x00007fffddab3e26 in sc::HTMLFetchThread::execute() (this=0x555559290dc0) at /home/julien/lo/libreoffice/sc/source/ui/dataprovider/htmldataprovider.cxx:195 #1 0x00007ffff649f58e in salhelper::Thread::run() (this=0x555559290dc0) at /home/julien/lo/libreoffice/salhelper/source/thread.cxx:40 #2 0x00007ffff649f8e2 in osl::threadFunc(void*) (param=0x555559290dd0) at /home/julien/lo/libreoffice/include/osl/thread.hxx:185 #3 0x00007ffff7f835f9 in osl_thread_start_Impl(void*) (pData=0x555559290e70) at /home/julien/lo/libreoffice/sal/osl/unx/thread.cxx:235 #4 0x00007ffff7723fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486 #5 0x00007ffff7bbc4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
If I type an id, here's another bt: 0x00007fffddab3e38 in sc::HTMLFetchThread::execute (this=0x555559296b30) at /home/julien/lo/libreoffice/sc/source/ui/dataprovider/htmldataprovider.cxx:197 197 if (pXmlNodes->nodeNr == 0) (gdb) bt #0 0x00007fffddab3e38 in sc::HTMLFetchThread::execute() (this=0x555559296b30) at /home/julien/lo/libreoffice/sc/source/ui/dataprovider/htmldataprovider.cxx:197 #1 0x00007ffff649f58e in salhelper::Thread::run() (this=0x555559296b30) at /home/julien/lo/libreoffice/salhelper/source/thread.cxx:40 #2 0x00007ffff649f8e2 in osl::threadFunc(void*) (param=0x555559296b40) at /home/julien/lo/libreoffice/include/osl/thread.hxx:185 #3 0x00007ffff7f835f9 in osl_thread_start_Impl(void*) (pData=0x555559296be0) at /home/julien/lo/libreoffice/sal/osl/unx/thread.cxx:235 #4 0x00007ffff7723fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486 #5 0x00007ffff7bbc4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
I submitted this patch to review: https://gerrit.libreoffice.org/#/c/78803/
Julien Nabet committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/ec57f6eca37192ada29cda1d37ec192472c0d9ef%5E%21 tdf#127461: fix data provider crashes It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Backport for 6.3 on review here: https://gerrit.libreoffice.org/#/c/78803/
Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-6-3": https://git.libreoffice.org/core/+/07e1ad042f2dacff441129b1adbb1ed58dd6b16e%5E%21 tdf#127461: fix data provider crashes It will be available in 6.3.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.