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.
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
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.
Still not reproducible. Could you please get a backtrace -> https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg ?
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.
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.
@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.
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?
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.
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.
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
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)
Bibisected using repo bibisect-win32-5.0. 5855bd616a2d1dd8d1daec66de97396312f41b76 is the first bad commit commit 5855bd616a2d1dd8d1daec66de97396312f41b76 Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Sat Jun 6 11:44:56 2015 -0500 source bec67f339b9b000628e2b82e2b38cd1cae37f94a # bad: [b7988d11e5d3751a4b366b2bfc9048f7a30e8526] source 87ac0b1e75a880a68ecb748bd4b34ae5a3d2ae98 # good: [a4f23b3ec86e92f49da9de4ccacd6ffcd8b343f8] source 0db96caf0fcce09b87621c11b584a6d81cc7df86 git bisect start 'b7988d11e5d3751a4b366b2bfc9048f7a30e8526' 'a4f23b3ec86e92f49da9de4ccacd6ffcd8b343f8' # good: [aecec0adaaadcf485210ad65fbf9bc6207714ebf] source c718f637a6db3fc7c1a548bfc7a1d15d83ffdc81 git bisect good aecec0adaaadcf485210ad65fbf9bc6207714ebf # bad: [715b9248bc9c6dc54a676ecd16b8a15ed696fa71] source 63314e5114ecd32246e0dbcd3054d37f612fb407 git bisect bad 715b9248bc9c6dc54a676ecd16b8a15ed696fa71 # bad: [6a3c5b9297d617deb06ca29045cc6e645c90b58a] source b265ddb9232f1c76e8c0aa5db9f117525bd4d4a7 git bisect bad 6a3c5b9297d617deb06ca29045cc6e645c90b58a # bad: [054c00aef57673b891013e65ad1ddf73705968a6] source 72d308703cdbaeb39835cc16256faf2710b48c5c git bisect bad 054c00aef57673b891013e65ad1ddf73705968a6 # bad: [ba1bd983ae7da4c2cc6e1097b67e6b2f243701a7] source bf8e37c12dc0b705d0b5ae5ccf3a137514d35825 git bisect bad ba1bd983ae7da4c2cc6e1097b67e6b2f243701a7 # good: [f2845385a9f5b2a64fdceb94c59a2db1f8c28e43] source 5c85974066306137907534c0473e17c56844876d git bisect good f2845385a9f5b2a64fdceb94c59a2db1f8c28e43 # good: [9be68c4f3a467d68faad2ea032c9889e38b414fa] source e9bb7c9e69999467a8dd5aa1683563228c619edc git bisect good 9be68c4f3a467d68faad2ea032c9889e38b414fa # bad: [5855bd616a2d1dd8d1daec66de97396312f41b76] source bec67f339b9b000628e2b82e2b38cd1cae37f94a git bisect bad 5855bd616a2d1dd8d1daec66de97396312f41b76 # good: [59d7123874405d6d6df4321f62e6b535e1636ed6] source e008e587ce556fa7567914c5953e4706089ca413 git bisect good 59d7123874405d6d6df4321f62e6b535e1636ed6 # first bad commit: [5855bd616a2d1dd8d1daec66de97396312f41b76] source bec67f339b9b000628e2b82e2b38cd1cae37f94a
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"
Created attachment 135003 [details] bt with debug symbols On pc Debian x86-64 with master sources updated yesterday, I could reproduce this.
Let's increase importance since: - it's a crash - it's a regression - it happens on several envs
(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.
(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)
(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.
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.
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.