I could reproduce this with the file Heiko Tietze provided.


Version: 24.8.3.2 (X86_64) / LibreOffice Community
Build ID: 48a6bac9e7e268aeb4c3483fcf825c94556d9f92
CPU threads: 2; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded


Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: ce4ae4f082d8fe80da242836c57d55a456eac5e0
CPU threads: 2; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded

Reproducible with
Version: 25.2.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 0f3f3710280d2476425bb86bc2e065e3e7a82952
CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 26100); UI render: default; VCL: win
Locale: es-ES (es_ES); UI: en-US
Calc: CL threaded


Latest version that works on the ones I have installed.
Version: 7.6.7.2 (X86_64) / LibreOffice Community
Build ID: dd47e4b30cb7dab30588d6c79c651f218165e3c5
CPU threads: 16; OS: Windows 10.0 Build 26100; UI render: Skia/Raster; VCL: win
Locale: es-ES (es_ES); UI: es-ES
Calc: CL threaded

Reproduced back to

Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 6f227b0dd912d4c70a01eb3872fff15d52de543a
CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: gtk3
Locale: it-IT (es_ES.UTF-8); UI: en-US
Calc: threaded

oldest commit in 24.2 bisect repo

It was odd, while bisecting the test document sometimes crashed on opening, but I would start a new document and create bibliography entries, then follow steps you mentioned. I was able to reproduce the bug and the result was:

source 7b99871635cd48c2a8a1d0afbd7afc60a45cc2ff

that sha was mentioned in the comments in Bug 156310 but that bug did not have to do with bibliography, the commit is about bibliography improvements.

I used bibisect-win64-7.6

Adding Cc: to Vojtěch Doležal

I don't seem to reproduce this. What do you mean by "double one of the bibliography entries" precisely?

Apologies, I opened it with an older version. I am able to reproduce it with 25.2.

It seems to me the crash is happening in the `IdentifierHdl` of the `SwCreateAuthEntryDlg_Impl`. I think the bug was probably introduced indirectly by the modification of the `ToxAuthorityField` enum. I'm not sure if I'm understanding the handler correctly, but could it be it's trying to call `set_text` on something that does not support this operation?

I'm not sure I understand the purpose of the ComboBox in this window, really. Wouldn't simple edit field make more sense here, given the fact there is already an entry selection dropdown list in the previous dialogue window?

Please check if this fixes the issue for you:

```
diff --git a/sw/source/ui/index/swuiidxmrk.cxx b/sw/source/ui/index/swuiidxmrk.cxx
index f8b1a2351aed..158ccd3803ee 100644
--- a/sw/source/ui/index/swuiidxmrk.cxx
+++ b/sw/source/ui/index/swuiidxmrk.cxx
@@ -1836,14 +1836,21 @@ IMPL_LINK(SwCreateAuthEntryDlg_Impl, IdentifierHdl, weld::ComboBox&, rBox, void)
     for(int i = 0; i < AUTH_FIELD_END; i++)
     {
         const TextInfo aCurInfo = aTextInfoArr[i];
-        if(AUTH_FIELD_IDENTIFIER == aCurInfo.nToxField)
-            continue;
-        if(AUTH_FIELD_AUTHORITY_TYPE == aCurInfo.nToxField)
-            m_xTypeListBox->set_active_text(
-                        pEntry->GetAuthorField(aCurInfo.nToxField));
-        else
+        switch (aCurInfo.nToxField)
+        {
+        case AUTH_FIELD_IDENTIFIER: continue;
+        case AUTH_FIELD_AUTHORITY_TYPE:
+            m_xTypeListBox->set_active(
+                    pEntry->GetAuthorField(aCurInfo.nToxField).toInt32());
+            break;
+        case AUTH_FIELD_TARGET_TYPE:
+            m_xTargetTypeListBox->set_active(
+                pEntry->GetAuthorField(aCurInfo.nToxField).toInt32());
+            break;
+        default:
             m_pEdits[i]->set_text(
-                        pEntry->GetAuthorField(aCurInfo.nToxField));
+                    pEntry->GetAuthorField(aCurInfo.nToxField));
+        }
     }
 }
```

At least it doesn't crash anymore. But I can change the shortname, and that creates a new entry rather than renaming the existing and the issue from bug 162858 becomes relevant. Not sure how it was in the past.

An alternative could be to block changing the shortname if started via Edit.

Just submitted a patch on Gerrit. I restructured the code a little so that the initial setup code and this ComboBox would call the same method for setting the fields, therefore if similar change happens in future, the crash will manifest immediately when opening the dialog and hopefully will not pass to production.

Vojtěch Doležal committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/b0299c4141f80dfd9989f1f376a960a9590f7a07

tdf#164179 - Fix crash on BibEntry ComboBox select

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