Description: 1) Open a Firebird embedded form (e.g. attached example) in LO 2) Click on Forms 3) Double-click on the Timetable form 4) Click on "Data Source in grid" button (last icon on lower toolbar). 5) The form now contains two windows, an upper one with a grid view of all records of the data in the underlying data table, and a lower one with the form and form controls showing only the currently selected record. The top window should be smaller than the total number of records in the table, i.e. it should not display all of the records. 6) Now try scrolling up with the mouse or touchpad in the top window to move the grid view downwards to show the hidden records - instant crash. Steps to Reproduce: See above Actual Results: Crash on trying to scroll down to show undisplayed records Expected Results: No crash, scroll should allow the records to be displayed Reproducible: Always User Profile Reset: Yes Additional Info: Version: 7.2.5.2 / LibreOffice Community Build ID: 499f9727c189e6ef3471021d6132d4c694f357e5 CPU threads: 8; OS: Mac OS X 12.1; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded
Running the test in a lldb debug session in LO master daily, the output below is displayed when the soffice process crashes : Process 38807 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x3038bef68) frame #0: 0x00007ff8070207b7 AppKit`NSViewGetVisibleRect + 210 AppKit`NSViewGetVisibleRect: -> 0x7ff8070207b7 <+210>: callq 0x7ff8070206e5 ; <+0> 0x7ff8070207bc <+215>: movups (%r12), %xmm0 0x7ff8070207c1 <+220>: movups 0x10(%r12), %xmm1 0x7ff8070207c7 <+226>: movaps %xmm1, -0xd0(%rbp) Target 0: (soffice) stopped. Will try and get a bt.
Created attachment 177548 [details] LLDB backtrace on crash That's a lot of NSViewGetVisibleRect frames to be processing...
@Alex, You didn't attach a Firebird database
(In reply to Telesto from comment #3) > @Alex, > You didn't attach a Firebird database Ah, cr*p, sorry Telesto, here you go.
Created attachment 177679 [details] Test ODB File - embedded Firebird
I could not reproduce it in ver: Version: 7.2.6.2 / LibreOffice Community Build ID: b0ec3a565991f7569a5a7f5d24fed7f52653d754 CPU threads: 12; OS: Mac OS X 10.16; UI render: default; VCL: osx Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded
Tested with LO 7.2.5.2 and also LO 7.3.1.3 on OpenSUSE 15.3. Couldn't reproduce it in this configuration.
(In reply to psidiumcode from comment #6) > I could not reproduce it in ver: > > Version: 7.2.6.2 / LibreOffice Community > Build ID: b0ec3a565991f7569a5a7f5d24fed7f52653d754 > CPU threads: 12; OS: Mac OS X 10.16; UI render: default; VCL: osx > Locale: en-GB (en_GB.UTF-8); UI: en-US > Calc: threaded Was your test on an Intel Mac with an Intel build of LO ? I'll need to test with 7.2.6.2 Intel, but crash still happens in Arm build 7.3.1.3.
Still instant crash for me when I try and scroll with mouse on DataNavigator pane using Version: 7.2.6.2 / LibreOffice Community Build ID: b0ec3a565991f7569a5a7f5d24fed7f52653d754 CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded MacbookPro Apple Silicon M1
Steps to reproduce: 1) Open Firebird ODB test file 2) Open the form Timetable 3) Click on the DataSourceAsTable icon to obtain the dual display of grid view data (top pane) above the form (lower pane). 4) Move the mouse pointer into the DataSourceAsTable area, but do not click on any of the cells of the grid. 5) Now try scrolling up or down with mouse.
Still reproducible in Version: 7.3.5.2 / LibreOffice Community Build ID: 184fe81b8c8c30d8b5082578aee2fed2ea847c01 CPU threads: 8; OS: Mac OS X 12.5.1; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded
Created attachment 182260 [details] Crash on scrolling within data source browser from database form
No repro for me in: Version: 7.3.1.3 / LibreOffice Community Build ID: a69ca51ded25f3eefd52d7bf9a5fad8c90b87951 CPU threads: 10; OS: Mac OS X 12.5; UI render: default; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded nor: Version: 7.4.0.2 / LibreOffice Community Build ID: 1512ce97d7ed39dce3121f7e15651fd8895f950e CPU threads: 10; OS: Mac OS X 12.5; UI render: default; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded I am using an M1.
(In reply to Michael Warner from comment #13) Hi Michael, > > I am using an M1. Are you using the aarch64 version of LO though ? Also, when you open the form, then display the DSB (data source browser) above the form, do you see all of the records, or are the bottom ones hidden ? From my testing, if you can see all of the records in the DSB, then no crash will occur. However, if some of the records are not displayed because the DSB window is too short to do so, then any scroll down mouse movement, e.g. down or up using the touchpad or the mouse wheel, will trigger the crash.
Still crashing with Version: 7.5.0.0.beta1 (AARCH64) / LibreOffice Community Build ID: 3aca23eec42e9d6fbe57071d7633ae1fc4bc5fcc CPU threads: 8; OS: Mac OS X 13.0.1; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded Attaching crash dump.
Created attachment 184144 [details] Crash dump with 7.5 beta
Looks related/identical to bug 149717
@Patrick Luby I don't expect you to solve all the unresolved macOS issue. However I do get slightly excited with macOS developer around. macOS bug don't get that much attention :-( It's only a poke, feel free to ignore
I can reproduce this bug with attachment 182260 [details] but only when I have activated macOS VoiceOver. In both Telesto's crash log and my local crash log, this infinite recursion of NSViewGetVisibleRect calls starts with a macOS NSAccessibility event (the magic function in the stack trace is "_NSAccessibilityChildrenInNavigationOrderAttributeValue"). My guess is that macOS is asking for all the accessible "child" objects for all of the rows in the table view and LibreOffice as in the process of returning a very large number of child objects. I see similar, but not the same, behavior when I open an empty Calc spreadsheet and enable VoiceOver: Calc does into a very, very long loop. @Alex Thurgood: Your last crash log has a truncated stack (due to infinite recursion of NSViewGetVisibleRect calls no doubt) so can do you only see this crash when VoiceOver or other accessible tool is activated?
(In reply to Patrick Luby from comment #19) > @Alex Thurgood: > > Your last crash log has a truncated stack (due to infinite recursion of > NSViewGetVisibleRect calls no doubt) so can do you only see this crash when > VoiceOver or other accessible tool is activated? @Patrick: the only tool running that might be considered an accessible tool is Rectangle. No Voiceover or any other Apple assistive technology functions are active.
FWIW, no crash with Intel CPU Version: 7.5.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: da3dd48eaf9086f8ab28d6a6655f9a638e51433a CPU threads: 8; OS: Mac OS X 12.3.1; UI render: default; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
Created attachment 184158 [details] LLDB backtrace with 7.5 beta @Patrick: I tested this in 7.5 beta from a lldb session and am attaching the bt obtained when it crashes.
(In reply to Alex Thurgood from comment #22) > Created attachment 184158 [details] > LLDB backtrace with 7.5 beta > > @Patrick: I tested this in 7.5 beta from a lldb session and am attaching the > bt obtained when it crashes. Your backtrace definitely shows NSAccessibility is active. If you scroll to the bottom of your backtrace and then scroll up to the bottom-most NSViewGetVisibleRect call, you will see that the crash occurs within some AquaA11y* calls so LibreOffice's accessibility code has been activated. For every LibreOffice accessible object (text, image, button, etc.), a matching native NSView is added to the native NSWindow to connect LibreOffice's C++ objects to macOS's native accessibility events so adding NSViews is normal. But what is strange is that in all of our crash logs, adding a new, empty NSView triggers the infinite recursive NSViewGetVisibleRect calls. I put some printf's in the code and only about 20 - 25 NSViews are added before the crash occurs. That isn't very many views (I seen Calc add tens of thousands) so I suspect that there is something unusually about the relative position or relationship between those NSViews. I'll see if I can find anything odd about the NSViews that may be triggering this crash.
I have found a fix for this bug and I have posted a patch at: https://gerrit.libreoffice.org/c/core/+/144329 The patch needs still needs to be reviewed and tested before it appears in a nightly build. Are there any people who have a macOS LibreOffice build that can test the patch?
(In reply to Patrick Luby from comment #24) > I have found a fix for this bug and I have posted a patch at: > > https://gerrit.libreoffice.org/c/core/+/144329 > > The patch needs still needs to be reviewed and tested before it appears in a > nightly build. Are there any people who have a macOS LibreOffice build that > can test the patch? @Patrick : unfortunately, I haven't managed to build LO on my Mac, due to autotool's insistence on setting a path in /usr/local/lib in my build config for some of the External stuff we pull into the build. The more external libraries get added to the code repo, the more difficult it becomes to build LO on Mac without falling foul of this problem. As I was only ever a casual builder of LO on Mac anyway, fixing build scripts and make files is well out of my league.
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/07f9f22e68a3caebe67d89c0b209059ba40be482 tdf#146765 Fix infinite recursion in -[NSView visibleRect] It will be available in 7.6.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.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/8c6b2b507a98c325bf0d0990e160d8e520a90671 tdf#146765 Fix infinite recursion in -[NSView visibleRect] It will be available in 7.5.0.0.beta2. 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.
(In reply to Alex Thurgood from comment #25) > @Patrick : unfortunately, I haven't managed to build LO on my Mac, due to > autotool's insistence on setting a path in /usr/local/lib in my build config > for some of the External stuff we pull into the build. > > The more external libraries get added to the code repo, the more difficult > it becomes to build LO on Mac without falling foul of this problem. As I was > only ever a casual builder of LO on Mac anyway, fixing build scripts and > make files is well out of my league. No worries. The patch got reviewed and merged really fast so my fix will hopefully be in tonight's night build. If you ever want to build LibreOffice, I have had very good luck with using LODE on both my MacBook Pros: https://wiki.documentfoundation.org/Development/lode I found LODE is a pretty slick way to setup a LibreOffice build environment. If you already have Xcode and a JDK installed, it downloads all of the prerequisites for building LibreOffice into whatever folder you git clone'd LODE into so it doesn't require any third-party packages to be installed in /opt, /usr, or other system folders. For me, my entire LODE environment is in a folder in my home folder. Pretty nice for me as I can still use the same machine for both LibreOffice and NeoOffice builds (NeoOffice still uses the fussy old "install this package on your machine" approach) so it is really nice that LODE keeps everything contained in its own folder.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/b4719f2e4c2acd87d547e8a13884f8ac18078463 tdf#146765 Fix infinite recursion in -[NSView visibleRect] It will be available in 7.4.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.
Confirmed as fixed on Version: 7.6.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: ad387d5b984c6666906505d25685065f710ed55d CPU threads: 8; OS: Mac OS X 13.0.1; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded
@Patrick : much thanks for this !
*** Bug 149717 has been marked as a duplicate of this bug. ***
7.4.5 was a hotfix release, updating target in status-whiteboard