Description: VB macro using RegEx matches. Calc crashes on second access of regex matches without VBA support option Steps to Reproduce: 1.Run the attached macro 2. 3. Actual Results: Calc application crashes Expected Results: Work properly Reproducible: Always User Profile Reset: No Additional Info: REM ***** BASIC ***** ' Crashes on second access of regex matches (line 19) without VBA support option. Private Function RegEx_Matches_Calc_Crash() Dim regEx As Object Set regEx = CreateObject("VBScript.RegExp") regEx.Global = True regEx.IgnoreCase = True html = "<span>10:35 AM EDT</span>" regEx.Pattern = "<span>([0-9]{2}):([0-9]{2}) (AM|PM) (EST|EDT)</span>" Set Matches = regEx.Execute(html) If Matches.Count > 0 Then TimeHour = Matches.Item(0).SubMatches.Item(0) TimeHour = Matches.Item(0).SubMatches.Item(0) TimeMinute = Matches.Item(0).SubMatches.Item(1) TimeAMPM = Matches.Item(0).SubMatches.Item(2) TimeTZ = Matches.Item(0).SubMatches.Item(3) End If End Function ' Version: 7.6.6.3 (X86_64) / LibreOffice Community ' Build ID: d97b2716a9a4a2ce1391dee1765565ea469b0ae7 ' CPU threads: 8; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win ' Locale: en-US (en_US); UI: en-US ' Calc: threaded
Repro. This is a two-stage regression (with a brief intermediate breakage). In OOo 3.2.0 and OOo 3.3.0, it run just fine (and adding a MsgBox to show all four submatches shown them all). In LO 3.3.0, it started showing an error, no matter how many attempts to run the function: "BASIC runtime error. An exception occurred Type: com.sun.star.uno.RuntimeException Message: [automation bridge] unexpected exception in IUnknownWrapper_Impl::getValue ! Message : ." In Version 3.4.0, it shown a run-time error on the problematic second TimeHour assignment line on the first function call: "General Error". Then it crashed on a second function run. In 3.5.0, it restored the behavior of 3.3.0; and worked like that till 7.5.0 (inclusive). In 7.6.0, it started crashing. The last regression (crash since 7.6) needs bisection.
This is some reference error. The call in [1] has the corresponding address and the call in [2] returns a null pointer leading to the crash. [1] https://opengrok.libreoffice.org/xref/core/basic/source/runtime/runtime.cxx?r=56f3dbff&mo=124132&fi=3991#3987 [2] https://opengrok.libreoffice.org/xref/core/basic/source/runtime/runtime.cxx?r=56f3dbff&mo=124132&fi=3991#3991
bibisected with win64-7.6 first bad commit source 6028e9fda96d0ed5da266b1c54a7755f7ba3408c
Stephan, can you take a look? commit 6028e9fda96d0ed5da266b1c54a7755f7ba3408c [log] author Stephan Bergmann <sbergman@redhat.com> Wed Feb 01 09:24:01 2023 +0100 committer Stephan Bergmann <sbergman@redhat.com> Wed Feb 01 09:51:15 2023 +0000 tree 3004c26ffa55c2793077ad1528247953b4dbe0a7 parent d8de2dc3c55a9013a71167c8058a333e7221a6a0 [diff] Finally drop undocumented rtl_[u]String_newFromStr null argument support ...executing on the TODO left by 4f0c70fb5554325e0cc2129741175bf07de22029 "Avoid calling OString ctor with null pointer" in late 2020. Change-Id: I3db6e2df61ca290948affc5e02ae74757441471d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146428 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
No repro using Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 5c17744e6debb06f295410714e34b0778183753c CPU threads: 24; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-GB Calc: CL threaded
Crash report: https://crashreport.libreoffice.org/stats/crash_details/834afec3-5c01-4567-a9ec-4ae63a06ff0f https://gerrit.libreoffice.org/c/core/+/180743 It would be interesting to understand why it's not reproducible in my dbgutil master build...
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1c763a6b88c2efd425e764778fc8c709387cf2ff tdf#160770: use OUString ctor that takes length, which allows nullptr 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.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/1090506502d07a42b2aa9a98c037c9a492263830 tdf#160770: use OUString ctor that takes length, which allows nullptr It will be available in 24.8.5. 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.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/da51ab330d0f1ed249ee73b5abedbcb3f31bbde5 tdf#160770: use OUString ctor that takes length, which allows nullptr It will be available in 25.2.1. 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.
Ok, so I have tested now with a release build having the fix from comment 7, and I can see that there's no more crash, so this bug is resolved fixed; however, the code still fails (now in an appropriate way, generating a run-time error), so there is a difference in how debug builds work compared to release ones (explaining why I fail to see the underlying problem in comment 6). Closing this one; the remaining error needs an own bug report.
Tested with 25.8.0.0.beta1 Still fails. Also still fails on 25.2.4.3 BASIC runtime error. An exception occurred Type: com.sun.star.lang.WrappedTargetRuntimeException Message: [automation bridge] unexpected exception in IUnknownWrapper::getValue ! Message : . Version: 25.8.0.0.beta1 (X86_64) / LibreOffice Community Build ID: 1b25e37a63c5a6f16bdcb365ed3da80ac419e6e4 CPU threads: 8; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded Version: 25.2.4.3 (X86_64) / LibreOffice Community Build ID: 33e196637044ead23f5c3226cde09b47731f7e27 CPU threads: 8; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
(In reply to NOYB from comment #11) > Tested with 25.8.0.0.beta1 > Still fails. Did you read comment 10? It doesn't crash. It fails. That needs an own bug report.
Yes I read comment 10. If it doesn't work it's not fixed.
(In reply to NOYB from comment #13) > Yes I read comment 10. > If it doesn't work it's not fixed. You have incorrect expectations. We use bugs for convenience of tracking problems in code, and for making it easy to check which change fixed which specific problem. But you are free do do whatever you like. I already could have fixed it, if there was a bug for that; but you seem interested more in arguing what workflow is correct. Shrug.
If you need another bug report for your workflow you have all the info needed to create one. Go for it. You seem more interested in bureaucracy than functionality.