Bug 145391 - Segfault importing Basic macros
Summary: Segfault importing Basic macros
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: BASIC (show other bugs)
Version:
(earliest affected)
6.4.7.2 release
Hardware: All Linux (All)
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard: target:7.3.0 target:7.2.3
Keywords: regression
Depends on:
Blocks:
 
Reported: 2021-10-30 00:39 UTC by Jim Avera
Modified: 2021-11-02 10:42 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
backtrace (pre-built executable, no symbols) (20.00 KB, text/plain)
2021-10-30 00:40 UTC, Jim Avera
Details
backtrace (local build from git, with symbols) (30.50 KB, text/plain)
2021-10-30 00:41 UTC, Jim Avera
Details
AndrewPersonalLibs.odt (271.95 KB, application/vnd.oasis.opendocument.text)
2021-10-30 00:42 UTC, Jim Avera
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jim Avera 2021-10-30 00:39:09 UTC
Description:
In master.  A SIGSEGV abort occurs when importing macros from another document.  The abort occurs after selecting the document but before anything is displayed.

The Segfault is in strcmp, called from libgtk3 stuff... ugh.

I'll attach two backtraces, one from the pre-built master build (no symbols), the other from my locally-built-from-git with symbols:

Here are the juicy bits:

Thread 1 "soffice.bin" received signal SIGSEGV, Segmentation fault.
__strcmp_avx2 () at ../sysdeps/x86_64/multiarch/strcmp-avx2.S:101
101 ../sysdeps/x86_64/multiarch/strcmp-avx2.S: No such file or directory.
#0  __strcmp_avx2 () at ../sysdeps/x86_64/multiarch/strcmp-avx2.S:101
#1  0x00007fffe4362369 in (anonymous namespace)::foreach_find(GtkTreeModel*, GtkTreePath*, GtkTreeIter*, gpointer) (model=0x555558e9f9e0, path=0x555558f7b080, iter=0x7fffffff9cd0, data=0x7fffffff9d40) at /home/jima/src/libreoffice/vcl/unx/gtk3/gtkinst.cxx:12691
#2  0x00007fffe3d6005a in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#3  0x00007fffe3d6148a in gtk_tree_model_foreach () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#4  0x00007fffe4369154 in (anonymous namespace)::GtkInstanceTreeView::find_text(rtl::OUString const&) const (this=0x55555921ba10, rText=...) at /home/jima/src/libreoffice/vcl/unx/gtk3/gtkinst.cxx:14128
#5  0x00007fffd3c7ca25 in basctl::LibPage::InsertLib() (this=0x555558b92960) at /home/jima/src/libreoffice/basctl/source/basicide/moduldl2.cxx:645
#6  0x00007fffd3c79465 in basctl::LibPage::ButtonHdl(weld::Button&) (this=0x555558b92960, rButton=...) at /home/jima/src/libreoffice/basctl/source/basicide/moduldl2.cxx:446
#7  0x00007fffd3c790bd in basctl::LibPage::LinkStubButtonHdl(void*, weld::Button&) (instance=0x555558b92960, data=...) at /home/jima/src/libreoffice/basctl/source/basicide/moduldl2.cxx:422
#8  0x00007fffe43b4627 in Link<weld::Button&, void>::Call(weld::Button&) const (this=0x555558bdcdf0, data=...) at /home/jima/src/libreoffice/include/tools/link.hxx:111
#9  0x00007fffe43aa6df in weld::Button::signal_clicked() (this=0x555558bdcde8) at /home/jima/src/libreoffice/include/vcl/weld.hxx:1406
#10 0x00007fffe4354d66 in (anonymous namespace)::GtkInstanceButton::signalClicked(GtkButton*, gpointer) (widget=0x555558bdcb30) at /home/jima/src/libreoffice/vcl/unx/gtk3/gtkinst.cxx:9197


Steps to Reproduce:
1. wget https://www.pitonyak.org/oo.php (or use copy attached to this bug)
2. /path/to/soffice --backtrace --calc

3. Tools->Macros->Organize Macros->Basic
   Select "My Macros" with mouse
   Click "Organizer..."
   Click "Libraries" tab at top
   Click "Import..."
   Select the file AndrewPersonalLibs.odt downloaded above

Actual Results:
SIGSEGV in soffice.bin (see backtrace)


Expected Results:
Not that


Reproducible: Always


User Profile Reset: No



Additional Info:
.
Comment 1 Jim Avera 2021-10-30 00:40:16 UTC
Created attachment 176013 [details]
backtrace (pre-built executable, no symbols)
Comment 2 Jim Avera 2021-10-30 00:41:11 UTC
Created attachment 176014 [details]
backtrace (local build from git, with symbols)
Comment 3 Jim Avera 2021-10-30 00:42:35 UTC
Created attachment 176015 [details]
AndrewPersonalLibs.odt
Comment 4 Jim Avera 2021-10-30 00:51:40 UTC
REGRESSION some time between 4.5.7.2 (which works) and 6.4.0.0.0+ (which faults)
Comment 5 Julien Nabet 2021-10-31 14:10:53 UTC
With gtk3 rendering, I don't reproduce the crash if I use this patch:
diff --git a/vcl/unx/gtk3/gtkinst.cxx b/vcl/unx/gtk3/gtkinst.cxx
index 504172208e74..8a032171c438 100644
--- a/vcl/unx/gtk3/gtkinst.cxx
+++ b/vcl/unx/gtk3/gtkinst.cxx
@@ -12698,6 +12698,8 @@ namespace
         Search* search = static_cast<Search*>(data);
         gchar *pStr = nullptr;
         gtk_tree_model_get(model, iter, search->col, &pStr, -1);
+        if (!pStr)
+            return false;
         bool found = strcmp(pStr, search->str.getStr()) == 0;
         if (found)
         {

BUT the file seems to contain all these libs:
AndrewBase
AndrewTestLib
ChangeStyles
DBUtil
MacroFormatterADP
OOoAuthorFormat
Pitonyak
PitonyakDatabase
PitonyakDialogs
PitonyakUtil
RemoveFormatting
Standard
TestLibrary
xyzzylib

and when using this patch, I see only the last one after 13 blank entries.

Caolán: thought you might be interested in this one.
Comment 6 Julien Nabet 2021-10-31 17:32:54 UTC
With this patch:
diff --git a/basctl/source/basicide/moduldl2.cxx b/basctl/source/basicide/moduldl2.cxx
index 42bcccebd67b..8c3cf5028d94 100644
--- a/basctl/source/basicide/moduldl2.cxx
+++ b/basctl/source/basicide/moduldl2.cxx
@@ -638,10 +638,9 @@ void LibPage::InsertLib()
                 ( xDlgLibContImport.is() && xDlgLibContImport->hasByName( aLibName ) && xDlgLibContImport->isLibraryLink( aLibName ) ) ) )
         {
             weld::TreeView& rView = xLibDlg->GetLibBox();
-            rView.append();
+            rView.append_text(aLibName);
             const int nRow = rView.n_children() - 1;
             rView.set_toggle(nRow, TRISTATE_TRUE);
-            rView.set_text(nRow, aLibName, 0);
             rView.set_cursor(rView.find_text(aLibName));
         }
     }

I don't reproduce the crash and all the checkboxes are present and enabled on gtk3.
But with gen rendering, only the last checkbox is present and enabled.
I must recognize I don't know why.
Comment 7 Caolán McNamara 2021-11-01 10:03:07 UTC
I think the problem began at 

commit e8b3df5b9b0eb0a93c25b6dc2e445ae44a7e3f78
Date:   Fri Aug 2 14:57:49 2019 +0200

    tdf#93476 Sort Macro library list after creating/importing a macro
    
    Only set the widget as sorted in the ctor, it remains sorted

where now the list set sorted in the LibBox ctor, so the line the text is inserted at is not a simple index based one where the line was just inserted at (the number of rows) - 1
Comment 8 Caolán McNamara 2021-11-01 10:42:14 UTC
https://gerrit.libreoffice.org/c/core/+/124542 should solve it
Comment 9 Commit Notification 2021-11-01 11:45:40 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/2ed921b0a56961c6937661258b44e1690c5f98d1

Resolves: tdf#145391 insertion code assumes unsorted treeview

It will be available in 7.3.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.
Comment 10 Caolán McNamara 2021-11-01 12:09:32 UTC
fixed in trunk, backport to 7-2 in gerrit
Comment 11 Julien Nabet 2021-11-01 12:14:23 UTC
and let's put this one to VERIFIED since I had tested the patch and everything was ok.
Comment 12 Commit Notification 2021-11-02 10:42:30 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-7-2":

https://git.libreoffice.org/core/commit/2dc90967977617f58a9d47e6ae89175919eef4b2

Resolves: tdf#145391 insertion code assumes unsorted treeview

It will be available in 7.2.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.