Bug 108802 - Crash in: SfxBindings::GetSlotPos(unsigned short,unsigned short) Editing. ( steps in comment 10 )
Summary: Crash in: SfxBindings::GetSlotPos(unsigned short,unsigned short) Editing. ( s...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
5.2.0.0.alpha1
Hardware: All All
: highest critical
Assignee: Dennis Francis
QA Contact:
URL:
Whiteboard: target:6.0.0 target:5.4.1
Keywords: bibisected, bisected, haveBacktrace, regression
Depends on:
Blocks:
 
Reported: 2017-06-26 23:15 UTC by John Jackson
Modified: 2017-08-09 07:11 UTC (History)
5 users (show)

See Also:
Crash report or crash signature: ["SfxBindings::GetSlotPos(unsigned short,unsigned short)"]


Attachments
Simple database with form, command button and macro. (12.73 KB, application/vnd.sun.xml.base)
2017-06-26 23:15 UTC, John Jackson
Details
Backtrace of crash when right click on form to select "edit" (16.50 KB, text/plain)
2017-06-27 15:15 UTC, John Jackson
Details
bt with debug symbols (4.34 KB, text/plain)
2017-07-30 16:29 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description John Jackson 2017-06-26 23:15:58 UTC
Created attachment 134303 [details]
Simple database with form, command button and macro.

This bug was filed from the crash reporting server and is br-9f9b05c4-328e-4823-a9d8-7173cf84272c..
=========================================

Libre Office crashes when I try to assign a macro to a button execute action in Base. It also crashes assigning macros to other controls. I first learned of the bug in version 5.2.4, where I got this error, "Libre Office 5.2 Fatal Error SEH Exception: Access Violation." I tried updating today to 5.3.4.2, and this error message doesn't appear but it still crashes.

To recreate the bug, simply create a new database. Add a form with a button. Add a macro. Try to assign the macro to the button. Save the form. Close the form. It crashes every time. (In the attached file, the macro is "Main.")

It looks as if Base has lost the simple functionality to assign macros to controls, rendering it largely useless.
Comment 1 Xisco Faulí 2017-06-26 23:57:46 UTC
I can't reproduce it in

Versión: 5.3.3.2
Id. de compilación: 3d9a8b4b4e538a85e0782bd6c2d430bafe583448
Subproc. CPU: 1; SO: Windows 6.1; Repr. de IU: predet.; Motor de trazado: HarfBuzz; 
Configuración regional: es-ES (es_ES); Calc: group

nor

Version: 6.0.0.0.alpha0+
Build ID: 08f6f9dded1b142b858c455da03319abac691655
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk2; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group

I guess you follow these steps,right ?
1. Open the file
2. Enable macro
3. Right Click on Form1 -> Edit
4. Right Click on the button -> Control
5. Events -> Execute Action
Comment 2 John Jackson 2017-06-27 12:43:52 UTC
In my sample file the macro had already been assigned. I did this fooling around, clicking on save form, then save database, but then when the form closed it still crashes. The crash also happens if you remove a macro. Let me complete the steps here:

1. Open the file
2. Enable macro
3. Right Click on Form1 -> Edit
4. Right Click on the button -> Control
5. Events -> Execute Action
6. Click on ellipses (...)
7. If there is a macro, click "remove."
8. If no macro, click "macro" and navigate to TestDatabase.Standard.Module1.Main 
9. Click "OK."
10. Click on form's save button.
11. Close the form.

I've also tried renaming my user profile, but the problem still occurred with the new user profile.
Comment 3 Xisco Faulí 2017-06-27 13:22:42 UTC
Still not reproducible.
Could you please get a backtrace -> https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg ?
Comment 4 John Jackson 2017-06-27 15:13:40 UTC
With the debugger running, the crash occurs as I right-click on the form and try to select "edit." I verified this several times. It's only after I attach to soffice.bin that the crash occurs when trying to edit the form.

Also I noticed the symbols files weren't downloaded, but I did paste in the paths shown on the webpage and verify they were saved correctly.
Comment 5 John Jackson 2017-06-27 15:15:16 UTC
Created attachment 134314 [details]
Backtrace of crash when right click on form to select "edit"

With the debugger running, the crash occurs as I right-click on the form and try to select "edit." I verified this several times. It's only after I attach to soffice.bin that the crash occurs when trying to edit the form.

Also I noticed the symbols files weren't downloaded, but I did paste in the paths shown on the webpage and verify they were saved correctly.
Comment 6 Alex Thurgood 2017-06-28 12:45:03 UTC
@John : thanks for the trace.

No repro on macOS 10.12.5 with

Version: 5.3.4.2
Build ID: f82d347ccc0be322489bf7da61d7e4ad13fe2ff3
Threads CPU : 4; Version de l'OS :Mac OS X 10.12.5; UI Render : par défaut; Moteur de mise en page : nouveau; 
Locale : fr-FR (fr_FR.UTF-8); Calc: group

Seems to be Win only.

@John : my (admittedly limited) understanding of your trace indicates a memory corruption where two threads (from different apps I assume one of which is LO) are trying to write to an overlapping memory space allocation.

Could it be that you have changed/upgraded your RAM recently, or perhaps one of the RAM chips has developed a fault ? 

If we can at least eliminate that possibility that would rule out hardware issues.
Comment 7 John Jackson 2017-06-28 13:03:52 UTC
I tried the debugger again with only LO and the debugger running. It still crashed when I selected "Edit" after right-clicking on the form. It sounds like the memory conflict might be between windbg and the LO Base component?

No RAM changes. No other symptoms on the computer, and I've seen a few reports of this problem in Libre Office on a Google search for "Libre Office SEH Exception Access Violation Macro". 

This one is in bugzilla and sounds exactly like my problem, but it ended in a way that made no sense to me, where Ramon said version 3.3 worked, and yet it appears no changes were made to LO:

https://bugs.documentfoundation.org/show_bug.cgi?id=103599

Should I try uninstalling 5.3.4.2 and installing the version you used, 5.3.3.2?
Comment 8 John Jackson 2017-07-13 21:12:38 UTC
I tried uninstalling 5.3.4.2 and installing 5.3.3.2, and it still crashes. However the macro has been assigned. I guess any time I want to add a macro there'll be a crash. I won't be able to use Libre Office for new database projects.
Comment 9 John Jackson 2017-07-17 14:51:46 UTC
I think I found a more specific cause of the crash. With LO 5.3.3.2, if the control properties dialog is closed before closing the form, I'm able to assign or take away macros without causing a crash. I had been leaving the properties dialog open before.
Comment 10 Xisco Faulí 2017-07-17 15:36:40 UTC
Ok, I can reproduce it now:

Steps:
1. Open the file
2. no need to enable the macros
3. Right Click on Form1 -> Edit
4. Right Click on the button -> Control
5. Events -> Execute Action
6. Click on ellipses (...)
7. If there is a macro, click "remove." If no macro, click "macro" and navigate to TestDatabase.Standard.Module1.Main 
9. Click "OK."
10. DO NOT CLOSE THE PROPERTIES DIALOG
11. Close the form dialog
12. CRASH
Comment 11 Xisco Faulí 2017-07-17 15:53:01 UTC
I can reproduce it in

Version: 5.2.0.0.alpha1+
Build ID: 5b168b3fa568e48e795234dc5fa454bf24c9805e
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; 
Locale: ca-ES (ca_ES.UTF-8)

but not in

Version: 5.0.0.0.alpha1+
Build ID: 0db96caf0fcce09b87621c11b584a6d81cc7df86
Locale: ca-ES (ca_ES.UTF-8)
Comment 12 Aron Budea 2017-07-17 21:21:14 UTC Comment hidden (bibisection)
Comment 13 Aron Budea 2017-07-17 21:21:31 UTC
Bibisected to the commit referenced below. Note that at this point the crash is not a SEH Exception, but I assume that doesn't matter.

https://cgit.freedesktop.org/libreoffice/core/commit/?id=bec67f339b9b000628e2b82e2b38cd1cae37f94a
author		László Németh <laszlo.nemeth@collabora.com>	2015-05-29 14:50:50 (GMT)
committer	László Németh <laszlo.nemeth@collabora.com>	2015-05-29 15:01:10 (GMT)

"dispose SfxControllerItem objects correctly"
Comment 14 Julien Nabet 2017-07-30 16:29:25 UTC
Created attachment 135003 [details]
bt with debug symbols

On pc Debian x86-64 with master sources updated yesterday, I could reproduce this.
Comment 15 Julien Nabet 2017-07-30 16:37:56 UTC
Let's increase importance since:
- it's a crash
- it's a regression
- it happens on several envs
Comment 16 Dennis Francis 2017-08-08 08:20:53 UTC
(In reply to Julien Nabet from comment #14)
> Created attachment 135003 [details]
> bt with debug symbols
> 
> On pc Debian x86-64 with master sources updated yesterday, I could reproduce
> this.

Hi Julian,

I am able to see the crash in Fedora 25 x86-64, in master updated today(built with debug symbols enabled) following the steps in comment 10. But when I try to get the backtrace in gdb using "make debugrun", when I get to the point of clicking on Edit on the form1, it crashes with the following trace :

Thread 1 "soffice.bin" received signal SIGSEGV, Segmentation fault.
0x00007fffa95002b4 in ?? ()

(gdb) bt
#0  0x00007fffa95002b4 in  ()
#1  0x0000000000000246 in  ()
#2  0x00007fffa9500160 in  ()
#3  0x00007ffffffed520 in  ()
#4  0x00007ffffffed4c0 in  ()
#5  0x00007fffb966f865 in VM_Version::get_processor_features() () at /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-1.b16.fc25.x86_64/jre/lib/amd64/server/libjvm.so

This does not happen when I run without gdb.
As a result I'm not able to get the trace of the actual crash. Did you have to do anything special to get the backtrace ?
Thanks.
Comment 17 Julien Nabet 2017-08-08 08:29:57 UTC
(In reply to Dennis Francis from comment #16)
> ...
> (gdb) bt
> #0  0x00007fffa95002b4 in  ()
> #1  0x0000000000000246 in  ()
> #2  0x00007fffa9500160 in  ()
> #3  0x00007ffffffed520 in  ()
> #4  0x00007ffffffed4c0 in  ()
> #5  0x00007fffb966f865 in VM_Version::get_processor_features() () at
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-1.b16.fc25.x86_64/jre/lib/amd64/
> server/libjvm.so
> ...
It's just Java here. (
In this case, just type "c" for continue and wait for the next bt.
You may have more than one "Java bt".

I'm not sure but I think it's related to Java signal handling (see http://nabble.documentfoundation.org/Signal-handling-in-Java-td4216904.html)
Comment 18 Dennis Francis 2017-08-08 08:46:06 UTC
(In reply to Julien Nabet from comment #17)
> It's just Java here. (
> In this case, just type "c" for continue and wait for the next bt.
> You may have more than one "Java bt".
> 
> I'm not sure but I think it's related to Java signal handling (see
> http://nabble.documentfoundation.org/Signal-handling-in-Java-td4216904.html)

Thanks Julien for the hint. I'm now able to get the relevant trace.
Comment 19 Commit Notification 2017-08-09 05:44:31 UTC
Dennis Francis committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=2585eb9d15f5c047d846ccb4b4d606d9ac89e518

tdf#108802 : In SfxControllerItem::dispose do not directly...

It will be available in 6.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 20 Commit Notification 2017-08-09 07:11:10 UTC
Dennis Francis committed a patch related to this issue.
It has been pushed to "libreoffice-5-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=1571964b4f7c38f47e47973fb06a0589d11d17b5&h=libreoffice-5-4

tdf#108802 : In SfxControllerItem::dispose do not directly...

It will be available in 5.4.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.