Bug 146765 - Base Form - crash when scrolling in dual form & "data as table" display (macOS Arm)
Summary: Base Form - crash when scrolling in dual form & "data as table" display (macO...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
7.2.5.2 release
Hardware: ARM macOS (All)
: medium normal
Assignee: Patrick Luby
URL:
Whiteboard: target:7.6.0 target:7.5.0.0.beta2 tar...
Keywords: haveBacktrace, notBibisectable, regression
: 149717 (view as bug list)
Depends on:
Blocks: macOS-UI-polish
  Show dependency treegraph
 
Reported: 2022-01-14 15:53 UTC by Alex Thurgood
Modified: 2023-01-24 10:36 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
LLDB backtrace on crash (1.69 MB, text/plain)
2022-01-14 16:08 UTC, Alex Thurgood
Details
Test ODB File - embedded Firebird (19.68 KB, application/vnd.oasis.opendocument.database)
2022-01-20 19:47 UTC, Alex Thurgood
Details
Crash on scrolling within data source browser from database form (11.68 MB, video/quicktime)
2022-09-06 13:20 UTC, Alex Thurgood
Details
Crash dump with 7.5 beta (118.16 KB, text/plain)
2022-12-14 11:09 UTC, Alex Thurgood
Details
LLDB backtrace with 7.5 beta (5.05 MB, text/plain)
2022-12-15 14:37 UTC, Alex Thurgood
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Thurgood 2022-01-14 15:53:59 UTC
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
Comment 1 Alex Thurgood 2022-01-14 16:04:19 UTC
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.
Comment 2 Alex Thurgood 2022-01-14 16:08:50 UTC
Created attachment 177548 [details]
LLDB backtrace on crash

That's a lot of NSViewGetVisibleRect frames to be processing...
Comment 3 Telesto 2022-01-19 10:56:46 UTC Comment hidden (obsolete)
Comment 4 Alex Thurgood 2022-01-20 19:47:08 UTC Comment hidden (obsolete)
Comment 5 Alex Thurgood 2022-01-20 19:47:46 UTC
Created attachment 177679 [details]
Test ODB File - embedded Firebird
Comment 6 psidiumcode 2022-03-13 17:18:22 UTC Comment hidden (obsolete)
Comment 7 Robert Großkopf 2022-03-13 17:40:20 UTC
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.
Comment 8 Alex Thurgood 2022-03-22 12:25:59 UTC
(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.
Comment 9 Alex Thurgood 2022-03-23 09:47:20 UTC
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
Comment 10 Alex Thurgood 2022-03-23 09:59:24 UTC
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.
Comment 11 Alex Thurgood 2022-09-06 13:12:01 UTC
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
Comment 12 Alex Thurgood 2022-09-06 13:20:31 UTC
Created attachment 182260 [details]
Crash on scrolling within data source browser from database form
Comment 13 Michael Warner 2022-09-21 01:42:22 UTC
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.
Comment 14 Alex Thurgood 2022-09-21 07:44:37 UTC
(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.
Comment 15 Alex Thurgood 2022-12-14 11:08:30 UTC
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.
Comment 16 Alex Thurgood 2022-12-14 11:09:21 UTC
Created attachment 184144 [details]
Crash dump with 7.5 beta
Comment 17 Alex Thurgood 2022-12-14 11:10:54 UTC
Looks related/identical to bug 149717
Comment 18 Telesto 2022-12-14 14:48:39 UTC
@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
Comment 19 Patrick Luby 2022-12-15 01:25:26 UTC
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?
Comment 20 Alex Thurgood 2022-12-15 05:47:24 UTC
(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.
Comment 21 Telesto 2022-12-15 09:15:40 UTC
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
Comment 22 Alex Thurgood 2022-12-15 14:37:37 UTC
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.
Comment 23 Patrick Luby 2022-12-15 16:46:42 UTC
(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.
Comment 24 Patrick Luby 2022-12-16 14:48:29 UTC
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?
Comment 25 Alex Thurgood 2022-12-16 15:47:37 UTC
(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.
Comment 26 Commit Notification 2022-12-16 16:20:10 UTC
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.
Comment 27 Commit Notification 2022-12-16 19:43:35 UTC
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.
Comment 28 Patrick Luby 2022-12-16 20:13:57 UTC
(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.
Comment 29 Commit Notification 2022-12-18 15:13:02 UTC
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.
Comment 30 Alex Thurgood 2022-12-20 10:05:15 UTC
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
Comment 31 Alex Thurgood 2022-12-20 10:06:00 UTC
@Patrick : much thanks for this !
Comment 32 Alex Thurgood 2022-12-20 10:08:24 UTC
*** Bug 149717 has been marked as a duplicate of this bug. ***
Comment 33 Xisco Faulí 2023-01-24 10:36:21 UTC
7.4.5 was a hotfix release, updating target in status-whiteboard