Bug 126961 - Cannot link to macOS address book - crashes and restarts
Summary: Cannot link to macOS address book - crashes and restarts
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
6.3.0.4 release
Hardware: x86-64 (AMD64) macOS (All)
: high major
Assignee: Not Assigned
URL:
Whiteboard: target:7.3.0 target:7.2.1
Keywords: bibisectRequest, haveBacktrace, regression
: 131458 132745 133516 (view as bug list)
Depends on:
Blocks: 50626 64641 111634 Address-Source Crash
  Show dependency treegraph
 
Reported: 2019-08-16 07:54 UTC by EB
Modified: 2021-10-13 07:47 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
Consecutive steps provoking the crash (569.05 KB, application/vnd.oasis.opendocument.graphics)
2019-08-16 07:56 UTC, EB
Details
Backtrace from lldb debug session (3.57 KB, text/plain)
2020-06-03 14:19 UTC, Alex Thurgood
Details
About Box Information (345.71 KB, image/jpeg)
2021-08-19 16:22 UTC, John Kopcke
Details
Apple Stack Trace with nightly build after indefinite hang on attempted save of ODB file (2.74 MB, text/plain)
2021-08-24 08:51 UTC, Alex Thurgood
Details
LLDB outputwith LO73 nightly (6.07 KB, text/plain)
2021-08-24 09:06 UTC, Alex Thurgood
Details

Note You need to log in before you can comment on or make changes to this bug.
Description EB 2019-08-16 07:54:26 UTC
Description:
Impossible to link to the macOS address book either with the assistant or manually

Steps to Reproduce:
1.Select Assistants for address data
2.Select address book source
3.select macOS X

Actual Results:
LO reports an error, closes and reopens after a few seconds
see attachment


Expected Results:
Link to the macOS address book and continue to build database


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 6.3.0.4
Build-ID: 057fc023c990d676a43019934386b85b21a9ee99
CPU-Threads: 8; BS: Mac OS X 10.14.6; UI-Render: Standard; VCL: osx; 
Gebietsschema: de-DE (de_DE.UTF-8); UI-Sprache: de-DE
Calc: threaded
Comment 1 EB 2019-08-16 07:56:47 UTC
Created attachment 153428 [details]
Consecutive steps provoking the crash
Comment 2 Alex Thurgood 2019-08-19 09:10:22 UTC
No repro for me I'm afraid with

Version: 6.2.5.2
Build ID: 1ec314fa52f458adc18c4f025c545a4e8b22c159
Threads CPU : 4; OS : Mac OS X 10.14.6; UI Render : par défaut; VCL: osx; 
Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR
Calc: threaded
Comment 3 Alex Thurgood 2019-08-19 09:30:53 UTC
No repro with 

Version: 6.3.0.4
Build ID: 057fc023c990d676a43019934386b85b21a9ee99
Threads CPU : 4; OS : Mac OS X 10.14.6; UI Render : par défaut; VCL: osx; 
Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR
Calc: threaded
Comment 4 EB 2019-08-19 10:41:29 UTC
(In reply to Alex Thurgood from comment #3)
> No repro with 
> 
> Version: 6.3.0.4
> Build ID: 057fc023c990d676a43019934386b85b21a9ee99
> Threads CPU : 4; OS : Mac OS X 10.14.6; UI Render : par défaut; VCL: osx; 
> Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR
> Calc: 

Something is screwy : I can use and open the address book with Thunderbird and I can link LO to the Thunderbird address book. Unfortunately TB imports only the email infos. But this means that the MAC address book is ok.
Comment 5 Alex Thurgood 2019-08-19 11:19:40 UTC
@EB: the only thing I can think of at the moment:

 - possible unicode support issues with certain German letters in the character strings of data within address book or likewise field names ?

Don't get me wrong, I've had crashes in previous, older versions when trying to connect to the Apple address book, but usually this only occurs the first time, and then afterwards, the crash doesn't happen anymore. Currently, I'm not seeing any crashes though and I tried creating a new ODB file each time, just in case it was that same issue.
Comment 6 EB 2019-08-21 08:26:36 UTC
(In reply to Alex Thurgood from comment #5)
> @EB: the only thing I can think of at the moment:
> 
>  - possible unicode support issues with certain German letters in the
> character strings of data within address book or likewise field names ?

I don't know. Thunderbird has no problems. I'm actually trying out 'Exporter for Contacts' but as I'm not very data-handling-savvy it's hit'n'try game.
  
> 
> Don't get me wrong, I've had crashes in previous, older versions when trying
> to connect to the Apple address book, but usually this only occurs the first
> time, and then afterwards, the crash doesn't happen anymore. Currently, I'm
> not seeing any crashes though and I tried creating a new ODB file each time,
> just in case it was that same issue.
Comment 7 Alex Thurgood 2019-10-04 06:08:59 UTC
@EB : did you authorise the Contacts.app to access LO (or is it the other way around, I don't remember) ? 

I seem to recall that the first time you try to access the contacts you get a message asking the user to authorise this before it can access the data stored in the Contacts.app.

Perhaps there is a security setting somewhere that you can unset/reset ?
Comment 8 EB 2019-10-04 14:34:50 UTC
(In reply to Alex Thurgood from comment #7)
> @EB : did you authorise the Contacts.app to access LO (or is it the other
> way around, I don't remember) ? 
> 
> I seem to recall that the first time you try to access the contacts you get
> a message asking the user to authorise this before it can access the data
> stored in the Contacts.app.
> 
> Perhaps there is a security setting somewhere that you can unset/reset ?

There are no access links or hints. Since Catalina is about to be dispatched I propose to call it a day and wait how LO and Catalina will fare. OK ? 
Have a nice weekend.
EB
Comment 9 Alex Thurgood 2019-10-25 07:27:24 UTC
Just created a new ODB file connecting to my Mac Contacts address on Catalina - no crash.

Version: 6.3.1.2
Build ID: b79626edf0065ac373bd1df5c28bd630b4424273
Threads CPU : 4; OS : Mac OS X 10.15; UI Render : par défaut; VCL: osx; 
Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR
Calc: threaded
Comment 10 Xisco Faulí 2019-11-26 10:11:47 UTC
Hello EB,
To be certain the reported issue is not
related to corruption in the user profile, could you please reset your
Libreoffice profile ( https://wiki.documentfoundation.org/UserProfile ) and
re-test?

I have set the bug's status to 'NEEDINFO'. Please change it back to
'UNCONFIRMED' if the issue is still present
Comment 11 Alex Thurgood 2020-05-07 08:15:43 UTC
*** Bug 132745 has been marked as a duplicate of this bug. ***
Comment 12 Alex Thurgood 2020-05-07 08:19:39 UTC
I have set bug 132745 as a DUP of this bug report, as they both report a crash when attempting to connect to the macOS Address Book, albeit via different call mechanisms :

- this bug report - access via the Create DB wizard
- bug report 132745 - access via the Exchange Address datasource wizard
Comment 13 andrew@aehrlich.com 2020-05-07 16:06:08 UTC
Thank you Alex. I just tested the following:

1. System Preferences -> Security and Privacy -> Full Disk Access
2. Adding LibreOffice
3. Restart LibreOffice.

Libreoffice still crashes when trying to add the address book via the data source wizard.

Also, I see that in Security and Privacy, there is a Contacts category, where LibreOffice is NOT added.

When doing the address book data source wizard, there is no popup for a permissions request. 

If there is a way for me to grab a debug log from the crash, let me know and I would be happy to upload it.
Comment 14 Alex Thurgood 2020-05-07 16:39:03 UTC
(In reply to andrew@aehrlich.com from comment #13)


> If there is a way for me to grab a debug log from the crash, let me know and
> I would be happy to upload it.

The only way to get really useful debug information generally is by using a debug-enabled macOS build of LO. As these are not provided (at least I don't think they are) in the daily builds, the only other way is to build yourself from source code with the debug enabled switch.

Other than that, you might be able to find at least some kind of information via the Console.app, and searching through the log files. If LibreOffice crashes, there is usually some kind of log left behind in the system, which might contain information of use.
Comment 15 Alex Thurgood 2020-06-02 10:40:02 UTC
*** Bug 131458 has been marked as a duplicate of this bug. ***
Comment 16 Alex Thurgood 2020-06-02 10:40:17 UTC
*** Bug 133516 has been marked as a duplicate of this bug. ***
Comment 17 Alex Thurgood 2020-06-02 13:00:16 UTC
Confirming with 

Version : 6.4.4.2
Build ID : 3d775be2011f3886db32dfd395a6a6d1ca2630ff
Threads CPU : 4; OS : Mac OS X 10.15.4; UI Render : par défaut; VCL: osx; 
Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR
Calc: threaded

When LO Vanilla crashes, I get an error message :

"LibreOffice Vanilla must unfortunately be manually restarted after installation or update" - unfortunately, I have done neither, so not sure where this message is coming from.
Comment 18 Alex Thurgood 2020-06-02 13:15:48 UTC
Don't know whether the following has anything to do with this particular problem, but in the system.log, I am seeing a whole bunch of :

com.apple.xpc.launchd[1] (com.apple.xpc.launchd.domain.pid.soffice.33660): Failed to bootstrap path: path = /Applications/LibreOffice.app/Contents/Frameworks/libuno_cppu.dylib.3

and similar entries for:
libuno_sal.dylib.3
libicudata.dylib.63
libicui18n.dylib.63
libuno_salhelpergcc3.dylib.3
libicuuc.dylib.63
libuno_cppuhelpergcc3.dylib.3
libuno_sal.dylib.3
libicudata.dylib.63
libuno_cppu.dylib.3
libicui18n.dylib.63
libuno_salhelpergcc3.dylib.3
libicuuc.dylib.63
libuno_cppuhelpergcc3.dylib.3

The same list appears for LOVanilla.
Comment 19 John Kopcke 2020-06-03 12:29:25 UTC
(In reply to andrew@aehrlich.com from comment #13)
> Thank you Alex. I just tested the following:
> 
> 1. System Preferences -> Security and Privacy -> Full Disk Access
> 2. Adding LibreOffice
> 3. Restart LibreOffice.
> 
> Libreoffice still crashes when trying to add the address book via the data
> source wizard.
> 
> Also, I see that in Security and Privacy, there is a Contacts category,
> where LibreOffice is NOT added.
> 
> When doing the address book data source wizard, there is no popup for a
> permissions request. 
> 
> If there is a way for me to grab a debug log from the crash, let me know and
> I would be happy to upload it.

I have just upgraded to 6.4.4.2 and still receive the same crash.  I believe that the key is the Security & Privacy Contacts access permission.  I don't see how it could work if LibreOffice app is not granted permission.  I use a third party database product called Ninox which accesses the Contacts.  It appears in the Contacts permission list and is granted access.  So my question is, why doesn't LibreOffice appear in the list of apps requesting Contacts access?  And, for those who cannot reproduce the error, do you see LibreOffice as having been granted access to Contacts?  If so, try taking away that permission and see if you get the crash.
Comment 20 Rainer Schaefer 2020-06-03 12:58:58 UTC
Well, I assure you that there is no use in this. I tried open office. OO is listed in "Contacts access" - and crashes also, when trying to access the MacOS-contacts.app

Even the new beta of LO 7 is crashing - and not listed in "system preferences - security - contacts access"

This seems to be a weird thing.

I tried a workaround. Exported the contacts to an Excel-sheet and tried to access this one from LO. Initially, this works fine - except you cannot add any contacts. And when toggling around with this Excel-Sheet a lot, after a while LO crashed again.
Comment 21 John Kopcke 2020-06-03 14:16:25 UTC
(In reply to Rainer Schaefer from comment #20)
> Well, I assure you that there is no use in this. I tried open office. OO is
> listed in "Contacts access" - and crashes also, when trying to access the
> MacOS-contacts.app
> 
> Even the new beta of LO 7 is crashing - and not listed in "system
> preferences - security - contacts access"
> 
> This seems to be a weird thing.
> 
> I tried a workaround. Exported the contacts to an Excel-sheet and tried to
> access this one from LO. Initially, this works fine - except you cannot add
> any contacts. And when toggling around with this Excel-Sheet a lot, after a
> while LO crashed again.

In order for an app on Mac to access the Contacts it must have NSContactsUsageDescription in the info.plist file.  I could not find this key in the info.plist.  I have scanned the source code LO and could not find any reference to it. I believe this needs to be added to the info.plist.
Comment 22 Alex Thurgood 2020-06-03 14:19:43 UTC
Created attachment 161576 [details]
Backtrace from lldb debug session
Comment 23 eisa01 2021-01-23 22:10:18 UTC
(In reply to John Kopcke from comment #21)
> In order for an app on Mac to access the Contacts it must have
> NSContactsUsageDescription in the info.plist file.  I could not find this
> key in the info.plist.  I have scanned the source code LO and could not find
> any reference to it. I believe this needs to be added to the info.plist.

I tried adding that key, but that doesn't resolve the issue

I guess LO may be using the Address Book framework that has been deprecated since 10.11?

https://developer.apple.com/documentation/addressbook
https://developer.apple.com/documentation/contacts/cncontactstore
Comment 24 Alex Thurgood 2021-04-21 08:22:14 UTC
Bug also present in $$Version: 7.0.4.4

LibreOffice Vanilla from the AppStore

Build ID: 841d27ff4cd6850c43bdd7333f8373cae686520d
CPU threads: 8; OS: Mac OS X 11.2.3; UI render: default; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR
Calc: threaded
Comment 25 Alex Thurgood 2021-04-21 08:26:41 UTC
Also reproduced with

Version: 7.1.2.2 / LibreOffice Community
Build ID: 8a45595d069ef5570103caea1b71cc9d82b2aae4
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

At least with this version, I can click on any of the left hand side icons in the main Base window, however, as soon as I try to execute any function associated with the table (open, read, edit, etc), LO crashes again and launches the recovery module.
Comment 26 Alex Thurgood 2021-04-21 08:33:52 UTC
FWIW, attempting to access any function of the loaded MacAb.odb file also causes Collabora Office to crash in the same way.

Collabora Office
Version : 6.4-20
Build ID : 8f9231b97d06858b598c6fa819546ca3391d11c7
Threads CPU : 8; OS : Mac OS X 11.2.3; UI Render : par défaut; VCL: osx; 
Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR
Calc: threaded
Comment 27 Hugo First 2021-04-21 22:27:04 UTC Comment hidden (spam)
Comment 28 Alex Thurgood 2021-06-18 12:45:50 UTC
Repeat crashing, restart, crash, restart cycle still reproducible in 

Version: 7.1.4.2 / LibreOffice Community
Build ID: a529a4fab45b75fefc5b6226684193eb000654f6
CPU threads: 4; OS: Mac OS X 10.16; UI render: default; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
Calc: threaded

Nearly 2 years old, high major, and no love shown by any developers. This is a very sad state of affairs.

There are currently no application addressbooks available via LO.
Comment 29 Xisco Faulí 2021-08-10 18:18:06 UTC
Hi Alex,
Would it be possible you test https://gerrit.libreoffice.org/c/core/+/120287 on your end ?
Comment 30 Noel Grandin 2021-08-10 18:18:36 UTC
It is pretty obvious from the backtrace that the macOS address book API is returning null pointers.

The most likely cause is the lack of security entitlement, so a (completely untested) patch is here:
https://gerrit.libreoffice.org/c/core/+/120287
Comment 31 Alex Thurgood 2021-08-11 12:20:38 UTC
(In reply to Noel Grandin from comment #30)
> It is pretty obvious from the backtrace that the macOS address book API is
> returning null pointers.
> 
> The most likely cause is the lack of security entitlement, so a (completely
> untested) patch is here:
> https://gerrit.libreoffice.org/c/core/+/120287

Unfortunately, I no longer have a build environment since I switched to Apple M1, so can't help here I'm afraid.
Comment 32 Commit Notification 2021-08-12 07:45:17 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/c6a0fff5e8ef321767abd2012324e90b31660fdf

tdf#126961 link to macOS address book - crashes and restarts

It will be available in 7.3.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 33 Xisco Faulí 2021-08-12 09:50:28 UTC
(In reply to Commit Notification from comment #32)
> Noel Grandin committed a patch related to this issue.
> It has been pushed to "master":
> 
> https://git.libreoffice.org/core/commit/
> c6a0fff5e8ef321767abd2012324e90b31660fdf
> 
> tdf#126961 link to macOS address book - crashes and restarts
> 
> It will be available in 7.3.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.

For those who can reproduce this issue, could you please try with a daily build from https://dev-builds.libreoffice.org/daily/master/current.html? Since the commmit was submitted today, you will have to wait a couple of days until a new build is available including the commit
Comment 34 Commit Notification 2021-08-16 07:02:23 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "libreoffice-7-2":

https://git.libreoffice.org/core/commit/b6568c4d688d326a06c9250561f47dad0b7c697b

tdf#126961 link to macOS address book - crashes and restarts

It will be available in 7.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.
Comment 35 Julien Nabet 2021-08-19 07:19:57 UTC
Alex: following Noel's patch, I saw that there was a build here:
https://dev-builds.libreoffice.org/daily/master/MacOSX-x86_64@tb81-TDF/current/

Do you think you can give it a try on your new M1 Apple ?
Comment 36 Xisco Faulí 2021-08-19 09:08:38 UTC
Patch is present in master and 7.2 branch. Closing as RESOLVED FIXED for now
Comment 37 John Kopcke 2021-08-19 11:13:51 UTC
I tried 7.2.1 on MacOS Beta 12.0, last build, and the wizard immediately crashes after selecting the Mac OS address book.
Comment 38 Julien Nabet 2021-08-19 11:18:03 UTC
(In reply to John Kopcke from comment #37)
> I tried 7.2.1 on MacOS Beta 12.0, last build, and the wizard immediately
> crashes after selecting the Mac OS address book.

Did you try https://wiki.documentfoundation.org/QA/FirstSteps#Corrupted_user_profile ?
If you still reproduce this, would it be possible you attach a backtrace (to compare with the one which had been provided by Alex)?
See https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#macOS:_How_to_get_debug_information
Comment 39 John Kopcke 2021-08-19 11:35:11 UTC
The profile was deleted.  There is no opportunity to produce a backtrace.  I immediately get the document recovery dialog.
Comment 40 Xisco Faulí 2021-08-19 13:46:51 UTC
(In reply to John Kopcke from comment #37)
> I tried 7.2.1 on MacOS Beta 12.0, last build, and the wizard immediately
> crashes after selecting the Mac OS address book.

Please, provide the info from Help - About LibreOffice
Comment 41 John Kopcke 2021-08-19 16:22:41 UTC
Created attachment 174421 [details]
About Box Information

Please see the attachment as requested.
Comment 42 Julien Nabet 2021-08-19 16:30:41 UTC
(In reply to John Kopcke from comment #41)
> Created attachment 174421 [details]
> About Box Information
> 
> Please see the attachment as requested.

It seems it includes indeed the Noel's patch (see https://cgit.freedesktop.org/libreoffice/core/log/?h=libreoffice-7-2&qt=range&q=f9ce63df1bbbca83164d5730d) so the pb is still here badfully :-(
Comment 43 Alex Thurgood 2021-08-23 09:59:04 UTC
FWIW, I do not get a crash with

Version: 7.2.0.4 / LibreOffice Community
Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b
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

Was 7204 branched off before or after Noel's patch went in ?

Currently, this is WFM in the 7204 production release (x86_64 on M1)
Comment 44 John Kopcke 2021-08-23 10:48:55 UTC
I just tried 7.2.0.4 and it crashed.  The same for 7.2.1
Comment 45 Alex Thurgood 2021-08-23 12:53:31 UTC
(In reply to John Kopcke from comment #44)
> I just tried 7.2.0.4 and it crashed.  The same for 7.2.1

@John : you're using a MacOS beta, yes ?

I'm using 11.5.2 (20G95) and no crash.
Comment 46 Xisco Faulí 2021-08-23 16:13:17 UTC
(In reply to Alex Thurgood from comment #43)
> FWIW, I do not get a crash with
> 
> Version: 7.2.0.4 / LibreOffice Community
> Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b
> 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
> 
> Was 7204 branched off before or after Noel's patch went in ?
> 
> Currently, this is WFM in the 7204 production release (x86_64 on M1)

Noe'l fix is not in 7.2.0.4 but in 7.2.1.1
Comment 47 Alex Thurgood 2021-08-24 08:50:33 UTC
(In reply to Julien Nabet from comment #35)
> Alex: following Noel's patch, I saw that there was a build here:
> https://dev-builds.libreoffice.org/daily/master/MacOSX-x86_64@tb81-TDF/
> current/
> 
> Do you think you can give it a try on your new M1 Apple ?

With nightly 73, I get an indefinite hang, requiring force kill of the app, on attempting to save the ODB file being created ab initio.

Enclosing Apple provided stack trace.
Comment 48 Alex Thurgood 2021-08-24 08:51:27 UTC
Created attachment 174511 [details]
Apple Stack Trace with nightly build after indefinite hang on attempted save of ODB file
Comment 49 Alex Thurgood 2021-08-24 08:55:50 UTC
(In reply to Alex Thurgood from comment #48)
> Created attachment 174511 [details]
> Apple Stack Trace with nightly build after indefinite hang on attempted save
> of ODB file

The file does get saved nonetheless, and indicates on reloading that it does point to the Mac Address Book, however, any attempt to view a table (or any other activity requiring access to the db context, causes an indefinite hang once again, requiring force kill.
Comment 50 Alex Thurgood 2021-08-24 09:06:33 UTC
Created attachment 174512 [details]
LLDB outputwith LO73 nightly

This is the lldb output when starting LO73 nightly, loading the ODB file, and clicking on the Table button in the left hand Base application pane.

There seems to be a lot more security verification going on than was first surmised.
Comment 51 Julien Nabet 2021-08-24 15:50:29 UTC
Stephan: anything in the 2 last files Alex attached that may help here?
I mean, in comparison with a stacktrace from Linux, these seem less easy to use.
Comment 52 Stephan Bergmann 2021-08-25 06:49:48 UTC
(In reply to EB from comment #0)
> Steps to Reproduce:
> 1.Select Assistants for address data
> 2.Select address book source
> 3.select macOS X

What do I need to do exactly (starting from the LO start center)?
Comment 53 Alex Thurgood 2021-08-25 14:55:12 UTC
(In reply to Stephan Bergmann from comment #52)

> 
> What do I need to do exactly (starting from the LO start center)?

1) Click on the Database icon in the left hand pane of the StartCenter to start the database creation wizard

2) Click on "Connect to an existing database" and choose Mac OSX Address Book from the dropdown menu

3) Click on "Next", and in the following dialog, leave the default selections, then click on "Finish"

4) Accept the default file name proposed in the Finder Save dialog or type in one of your choice.
Comment 54 Alex Thurgood 2021-08-25 15:03:26 UTC
Stragely enough, I can create a functional ODB file with LO7152 without any crashes, and can then subsequently open the same file in LO7204, also without crashing.

If I try to create the ODB file directly with LO7204, I get the hanging and unusable ODB file for which I have provided lldb output and Apple StackTrace.

When I then load that useless ODB file into 7152, I don't get any crashes and can read the address data table.

If I then load the same file back into LO7204, it no longer hangs and is seemingly fully functional.

Go figure.
Comment 55 Stephan Bergmann 2021-08-25 15:16:05 UTC
Trying that out with a recent local master build on macOS 11.5.2, it crashes at

> * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSEGV
>     frame #0: 0x0000000193c4a4f0 CoreFoundation`CFArrayGetCount + 16
> CoreFoundation`CFArrayGetCount:
> ->  0x193c4a4f0 <+16>: ldr    x9, [x0]
>     0x193c4a4f4 <+20>: adrp   x10, 389043
>     0x193c4a4f8 <+24>: ldr    x10, [x10, #0x38]
>     0x193c4a4fc <+28>: bic    x8, x9, x10
> Target 0: (soffice) stopped.
> (lldb) bt
> error: common.a(keywords.o) failed to load objfile for ~/lo/core/workdir/UnpackedTarball/firebird/temp/Debug/common.a
> * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSEGV
>   * frame #0: 0x0000000193c4a4f0 CoreFoundation`CFArrayGetCount + 16
>     frame #1: 0x000000029ec857d0 libmacabdrv1.dylib`connectivity::macab::MacabRecords::initialize(this=0x00000002dc5c9ff0) at ~/lo/core/connectivity/source/drivers/macab/MacabRecords.cxx:146:42
>     frame #2: 0x000000029ec9044c libmacabdrv1.dylib`connectivity::macab::MacabAddressBook::getMacabRecords(this=0x00000002dff28ca0) at ~/lo/core/connectivity/source/drivers/macab/MacabAddressBook.cxx:123:26
>     frame #3: 0x000000029ec74378 libmacabdrv1.dylib`connectivity::macab::MacabDatabaseMetaData::getTables(this=0x000000016fdfa8d0)::$_2::operator()() const at ~/lo/core/connectivity/source/drivers/macab/MacabDatabaseMetaData.cxx:951:67
>     frame #4: 0x000000029ec741a0 libmacabdrv1.dylib`connectivity::macab::MacabDatabaseMetaData::getTables(this=0x000000012e25c3c0, (null)=0x000000016fdfaac0, (null)=0x000000016fdfaab8, (null)=0x000000016fdfaab0, types=0x000000016fdfaae8) at ~/lo/core/connectivity/source/drivers/macab/MacabDatabaseMetaData.cxx:946:54
>     frame #5: 0x00000002fae71afc libdbalo.dylib`dbaccess::OFilteredContainer::construct(this=0x0000000131eeca10, _rTableFilter=0x0000000131eda618, _rTableTypeFilter=0x0000000131eda620) at ~/lo/core/dbaccess/source/core/api/FilteredContainer.cxx:347:60
>     frame #6: 0x00000002fafad56c libdbalo.dylib`dbaccess::OConnection::refresh(this=0x0000000131eda4b0, _rToBeRefreshed=0x000000016fdface8) at ~/lo/core/dbaccess/source/core/dataaccess/connection.cxx:534:28
>     frame #7: 0x00000002fafad908 libdbalo.dylib`dbaccess::OConnection::getTables(this=0x0000000131eda4b0) at ~/lo/core/dbaccess/source/core/dataaccess/connection.cxx:560:5
>     frame #8: 0x000000012e706628 libgcc3_uno.dylib`callVirtualFunction(function=12800678340, gpr=0x000000016fdfb068, fpr=0x000000016fdfb028, stack=0x000000016fdfadd0, sp=0, ret=0x000000016fdfadd0) at ~/lo/core/bridges/source/cpp_uno/gcc3_linux_aarch64/callvirtualfunction.cxx:38:5
>     frame #9: 0x000000012e70f430 libgcc3_uno.dylib`(anonymous namespace)::call(proxy=0x00000002dc5e86b0, slot=(offset = 0, index = 3), returnType=0x00000001302390b0, count=0, parameters=0x0000000000000000, returnValue=0x000000016fdfb330, arguments=0x000000016fdfb330, exception=0x000000016fdfb488) at ~/lo/core/bridges/source/cpp_uno/gcc3_linux_aarch64/uno2cpp.cxx:293:13
>     frame #10: 0x000000012e70ec5c libgcc3_uno.dylib`::unoInterfaceProxyDispatch(pUnoI=0x00000002dc5e86b0, pMemberDescr=0x000000012e25d170, pReturn=0x000000016fdfb330, pArgs=0x000000016fdfb330, ppException=0x000000016fdfb488) at ~/lo/core/bridges/source/cpp_uno/gcc3_linux_aarch64/uno2cpp.cxx:505:17
>     frame #11: 0x000000029f171c34 libproxyfaclo.dylib`com::sun::star::uno::UnoInterfaceReference::dispatch(this=0x00000002dc5a84e8, pMemberType=0x000000012e25d170, pReturn=0x000000016fdfb330, pArgs=0x000000016fdfb330, ppException=0x000000016fdfb488) const at ~/lo/core/include/uno/dispatcher.hxx:177:5
>     frame #12: 0x000000029f172484 libproxyfaclo.dylib`(anonymous namespace)::binuno_proxy_dispatch(pUnoI=0x00000002dc5a84c0, pMemberType=0x000000012e25d170, pReturn=0x000000016fdfb330, pArgs=0x000000016fdfb330, ppException=0x000000016fdfb488) at ~/lo/core/stoc/source/proxy_factory/proxyfac.cxx:245:24
>     frame #13: 0x000000012e70de84 libgcc3_uno.dylib`(anonymous namespace)::call(proxy=0x00000002dc5ec3b0, description=0x000000016fdfb600, returnType=0x00000001302390b0, count=0, parameters=0x0000000000000000, gpr=0x000000016fdfb670, fpr=0x000000016fdfb6b0, stack=0x000000016fdfb6f0, indirectRet=0x000000016fdfb830) at ~/lo/core/bridges/source/cpp_uno/gcc3_linux_aarch64/cpp2uno.cxx:258:5
>     frame #14: 0x000000012e70d49c libgcc3_uno.dylib`::vtableCall(functionIndex=3, vtableOffset=0, gpr=0x000000016fdfb670, fpr=0x000000016fdfb6b0, stack=0x000000016fdfb6f0, indirectRet=0x000000016fdfb830) at ~/lo/core/bridges/source/cpp_uno/gcc3_linux_aarch64/cpp2uno.cxx:431:13
>     frame #15: 0x000000012e720f78 libgcc3_uno.dylib`vtableSlotCall + 96
>     frame #16: 0x00000002f671bc00 libdbulo.dylib`dbaui::OTableTreeListBox::UpdateTableList(this=0x00000002dc5cafc0, _rxConnection=0x000000016fdfbe10) at ~/lo/core/dbaccess/source/ui/control/tabletree.cxx:100:31
>     frame #17: 0x00000002f65d704c libdbulo.dylib`dbaui::OAppDetailPageHelper::createTablesPage(this=0x00000002dc185b98, _xConnection=0x000000016fdfbe10) at ~/lo/core/dbaccess/source/ui/app/AppDetailPageHelper.cxx:525:74
>     frame #18: 0x00000002f65f2878 libdbulo.dylib`dbaui::OApplicationDetailView::impl_createPage(this=0x00000002dd231a00, _eType=E_TABLE, _rxConnection=0x000000016fdfbe10, _rxNonTableElements=0x000000016fdfbc40) at ~/lo/core/dbaccess/source/ui/app/AppDetailView.cxx:257:29
>     frame #19: 0x00000002f65f26c8 libdbulo.dylib`dbaui::OApplicationDetailView::createTablesPage(this=0x00000002dd231a00, _xConnection=0x000000016fdfbe10) at ~/lo/core/dbaccess/source/ui/app/AppDetailView.cxx:233:5
>     frame #20: 0x00000002f658c5d8 libdbulo.dylib`dbaui::OApplicationController::onContainerSelect(this=0x0000000117095a00, _eType=E_TABLE) at ~/lo/core/dbaccess/source/ui/app/AppController.cxx:1627:54
>     frame #21: 0x00000002f660223c libdbulo.dylib`dbaui::OApplicationSwapWindow::onContainerSelected(this=0x00000002dd227a68, _eType=E_TABLE) at ~/lo/core/dbaccess/source/ui/app/AppSwapWindow.cxx:99:52
>     frame #22: 0x00000002f66024a8 libdbulo.dylib`dbaui::OApplicationSwapWindow::OnContainerSelectHdl(this=0x00000002dd227a68, pEntry=0x00000002dc1d5dc0) at ~/lo/core/dbaccess/source/ui/app/AppSwapWindow.cxx:117:9
>     frame #23: 0x00000002f6601eb4 libdbulo.dylib`dbaui::OApplicationSwapWindow::LinkStubOnContainerSelectHdl(instance=0x00000002dd227a68, data=0x00000002dc1d5dc0) at ~/lo/core/dbaccess/source/ui/app/AppSwapWindow.cxx:112:1
>     frame #24: 0x0000000103c87b34 libsfxlo.dylib`Link<ThumbnailViewItem const*, void>::Call(this=0x00000002dd2525f0, data=0x00000002dc1d5dc0) const at ~/lo/core/include/tools/link.hxx:111:45
>     frame #25: 0x0000000103cbfdc0 libsfxlo.dylib`ThumbnailView::SelectItem(this=0x00000002dd252520, nItemId=1) at ~/lo/core/sfx2/source/control/thumbnailview.cxx:1085:20
>     frame #26: 0x00000002f660252c libdbulo.dylib`dbaui::OApplicationSwapWindow::selectContainer(this=0x00000002dd227a68, eType=E_TABLE) at ~/lo/core/dbaccess/source/ui/app/AppSwapWindow.cxx:130:21
>     frame #27: 0x00000002f6606690 libdbulo.dylib`dbaui::OApplicationView::selectContainer(this=0x0000000145915660, _eType=E_TABLE) at ~/lo/core/dbaccess/source/ui/app/AppView.cxx:373:17
>     frame #28: 0x00000002f6594a88 libdbulo.dylib`dbaui::OApplicationController::select(this=0x0000000117095a00, _aSelection=0x000000016fdfc5b8) at ~/lo/core/dbaccess/source/ui/app/AppController.cxx:2800:21
>     frame #29: 0x00000002b0bd09ec libdbaxmllo.dylib`dbaxml::(anonymous namespace)::DBContentLoader::load(this=0x000000012e2534d0, rFrame=0x000000016fdfcb58, _rURL=0x000000016fdfcad0, rArgs=0x000000016fdfcad8, rListener=0x000000016fdfcaa8) at ~/lo/core/dbaccess/source/filter/xml/dbloader2.cxx:477:27
>     frame #30: 0x0000000102476a30 libfwklo.dylib`framework::LoadEnv::impl_loadContent(this=0x000000012e4776d8) at ~/lo/core/framework/source/loadenv/loadenv.cxx:1147:23
>     frame #31: 0x0000000102473bc4 libfwklo.dylib`framework::LoadEnv::start(this=0x000000012e4776d8) at ~/lo/core/framework/source/loadenv/loadenv.cxx:395:20
>     frame #32: 0x0000000102471b74 libfwklo.dylib`framework::LoadEnv::startLoading(this=0x000000012e4776d8, sURL=0x000000012e374ae8, lMediaDescriptor=0x000000012e374b40, xBaseFrame=0x000000016fdfd290, sTarget=0x000000012e4776c8, nSearchFlags=0, eFeature=WorkWithUI | AllowContentHandler) at ~/lo/core/framework/source/loadenv/loadenv.cxx:300:5
>     frame #33: 0x0000000102326f0c libfwklo.dylib`framework::LoadDispatcher::impl_dispatch(this=0x000000012e477680, rURL=0x000000012e374ae8, lArguments=0x000000012e374b40, xListener=0x000000016fdfd568) at ~/lo/core/framework/source/dispatch/loaddispatcher.cxx:106:19
>     frame #34: 0x00000001023279a8 libfwklo.dylib`framework::LoadDispatcher::dispatch(this=0x000000012e477680, aURL=0x000000012e374ae8, lArguments=0x000000012e374b40) at ~/lo/core/framework/source/dispatch/loaddispatcher.cxx:53:5
>     frame #35: 0x0000000108e7ac00 libsvtlo.dylib`svt::PopupMenuControllerBase::ExecuteHdl_Impl((null)=0x0000000000000000, p=0x000000012e374ae0) at ~/lo/core/svtools/source/uno/popupmenucontrollerbase.cxx:156:32
>     frame #36: 0x0000000108e7ab70 libsvtlo.dylib`svt::PopupMenuControllerBase::LinkStubExecuteHdl_Impl(instance=0x0000000000000000, data=0x000000012e374ae0) at ~/lo/core/svtools/source/uno/popupmenucontrollerbase.cxx:153:1
>     frame #37: 0x000000010ae81948 libvcllo.dylib`Link<void*, void>::Call(this=0x000000012e31b398, data=0x000000012e374ae0) const at ~/lo/core/include/tools/link.hxx:111:45
>     frame #38: 0x000000010ae7ea8c libvcllo.dylib`ImplHandleUserEvent(pSVEvent=0x000000012e31b390) at ~/lo/core/vcl/source/window/winproc.cxx:2014:30
>     frame #39: 0x000000010ae7bb9c libvcllo.dylib`ImplWindowFrameProc(_pWindow=0x00000001459adb60, nEvent=UserEvent, pEvent=0x000000012e31b390) at ~/lo/core/vcl/source/window/winproc.cxx:2584:13
>     frame #40: 0x000000012c03cb74 libvclplug_osxlo.dylib`SalFrame::CallCallback(this=0x00000001459ae2f0, nEvent=UserEvent, pEvent=0x000000012e31b390) const at ~/lo/core/vcl/inc/salframe.hxx:306:29
>     frame #41: 0x000000012c051574 libvclplug_osxlo.dylib`AquaSalInstance::ProcessEvent(this=0x0000000116d1bbd0, aEvent=<unavailable>) at ~/lo/core/vcl/osx/salinst.cxx:375:22
>     frame #42: 0x000000010b45b5c8 libvcllo.dylib`SalUserEventList::DispatchUserEvents(this=0x000000016fdfde70)::$_0::operator()() const at ~/lo/core/vcl/source/app/salusereventlist.cxx:119:58
>     frame #43: 0x000000010b45aea8 libvcllo.dylib`SalUserEventList::DispatchUserEvents(this=0x0000000116d1bbd0, bHandleAllCurrentEvents=false) at ~/lo/core/vcl/source/app/salusereventlist.cxx:120:13
>     frame #44: 0x000000012c051f98 libvclplug_osxlo.dylib`AquaSalInstance::DoYield(this=0x0000000116d1bbd0, bWait=true, bHandleAllCurrentEvents=false) at ~/lo/core/vcl/osx/salinst.cxx:513:22
>     frame #45: 0x000000010b50a37c libvcllo.dylib`ImplYield(i_bWait=true, i_bAllEvents=false) at ~/lo/core/vcl/source/app/svapp.cxx:465:48
>     frame #46: 0x000000010b50a094 libvcllo.dylib`Application::Yield() at ~/lo/core/vcl/source/app/svapp.cxx:532:5
>     frame #47: 0x000000010b50a004 libvcllo.dylib`Application::Execute() at ~/lo/core/vcl/source/app/svapp.cxx:444:9
>     frame #48: 0x00000001002d6b38 libsofficeapp.dylib`desktop::Desktop::Main(this=0x000000016fdff788) at ~/lo/core/desktop/source/app/app.cxx:1602:13
>     frame #49: 0x000000010b524880 libvcllo.dylib`ImplSVMain() at ~/lo/core/vcl/source/app/svmain.cxx:199:35
>     frame #50: 0x000000012c0516ac libvclplug_osxlo.dylib`AquaSalInstance::handleAppDefinedEvent(pEvent=0x0000000133aef780) at ~/lo/core/vcl/osx/salinst.cxx:396:20
>     frame #51: 0x000000012c0ce930 libvclplug_osxlo.dylib`-[VCL_NSApplication sendEvent:](self=0x0000000116eab590, _cmd="sendEvent:", pEvent=0x0000000133aef780) at ~/lo/core/vcl/osx/vclnsapp.mm:101:9
>     frame #52: 0x00000001968eb7a8 AppKit`-[NSApplication _handleEvent:] + 76
>     frame #53: 0x000000019648de74 AppKit`-[NSApplication run] + 636
>     frame #54: 0x000000019645f878 AppKit`NSApplicationMain + 1064
>     frame #55: 0x000000012c055854 libvclplug_osxlo.dylib`AquaSalInstance::SVMainHook(this=0x0000000116d1bbd0, pnInit=0x000000016fdff6b8) at ~/lo/core/vcl/osx/salinst.cxx:971:5
>     frame #56: 0x000000010b524840 libvcllo.dylib`ImplSVMain() at ~/lo/core/vcl/source/app/svmain.cxx:192:54
>     frame #57: 0x000000010b525f1c libvcllo.dylib`SVMain() at ~/lo/core/vcl/source/app/svmain.cxx:231:12
>     frame #58: 0x0000000100344f74 libsofficeapp.dylib`soffice_main at ~/lo/core/desktop/source/app/sofficemain.cxx:98:12
>     frame #59: 0x0000000100003f44 soffice`sal_main at ~/lo/core/desktop/source/app/main.c:49:15
>     frame #60: 0x0000000100003f1c soffice`main(argc=1, argv=0x000000016fdff8d0) at ~/lo/core/desktop/source/app/main.c:47:1
>     frame #61: 0x0000000193bcd430 libdyld.dylib`start + 4
> (lldb) f 1
> frame #1: 0x000000029ec857d0 libmacabdrv1.dylib`connectivity::macab::MacabRecords::initialize(this=0x00000002dc5c9ff0) at ~/lo/core/connectivity/source/drivers/macab/MacabRecords.cxx:146:42
>    143 	
>    144 	    ABRecordRef record;
>    145 	    sal_Int32 i;
> -> 146 	    recordsSize = static_cast<sal_Int32>(CFArrayGetCount(allRecords));
>    147 	    records = new MacabRecord *[recordsSize];
>    148 	
>    149 	    /* First, we create the header... */
> (lldb) p allRecords
> (CFArrayRef) $0 = nullptr
> (lldb) p recordType
> (CFStringRef) $1 = 0x00000002031a5108 "ABPerson"

so apparently the call of

>         allRecords = ABCopyArrayOfAllPeople(addressBook);

in MacabRecords::initialize (connectivity/source/drivers/macab/MacabRecords.cxx) returned null, which the code apparently does not expect.

I have no idea about the code in question or the relevant macOS APIs, but I notice that <https://developer.apple.com/documentation/addressbook?language=objc> states "Important:  Do not use the AddressBook framework in macOS 10.11 and later.  Use the APIs defined in the Contacts framework instead."
Comment 56 Julien Nabet 2021-08-25 19:40:07 UTC
(In reply to Stephan Bergmann from comment #55)
>>...
> 
> so apparently the call of
> 
> >         allRecords = ABCopyArrayOfAllPeople(addressBook);
> 
> in MacabRecords::initialize
> (connectivity/source/drivers/macab/MacabRecords.cxx) returned null, which
> the code apparently does not expect.
I had seen this but what I don't understand when reading https://developer.apple.com/documentation/addressbook/1430121-abcopyarrayofallpeople, is even if it doesn't find any address book, ABCopyArrayOfAllPeople is expected to return an empty array, so CFArrayGetCount could return 0.

> 
> I have no idea about the code in question or the relevant macOS APIs, but I
> notice that
> <https://developer.apple.com/documentation/addressbook?language=objc> states
> "Important:  Do not use the AddressBook framework in macOS 10.11 and later. 
> Use the APIs defined in the Contacts framework instead."
Argh, it's the main problem since it's not a 20 lines max patch which will fix this but a big chunk of code. Considering it's on Base part and more specifically on MacOs, unless you feel like working on it, there's slight chance it'll be implemented.
So after last versions of Thunderbird which need Sqlite implementation (that we don't have) to use addressbook instead of Mork, now we've got this, bad days for those who want to use address book with LO, hope there are not too much and find some workaround :-(
Comment 57 Alex Thurgood 2021-08-26 10:16:25 UTC
Yup, see my comment at :

bug 138715#c23
Comment 58 Alex Thurgood 2021-10-13 07:45:54 UTC
This bug is still present in 


Immediate crash on trying to access the Tables (click on Tables button in lefthand pane of main Base application window) with :

Collabora Productivity
Version: 21.06.4.1
Build ID: 5ad6bfb54ffec15fe311ed990aa1518979b8f086
CPU threads: 4; OS: Mac OS X 11.6; UI render: default; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
Calc: threaded

LibreOffice
Version: 7.1.6.2 / LibreOffice Community
Build ID: 0e133318fcee89abacd6a7d077e292f1145735c3
CPU threads: 4; OS: Mac OS X 10.16; UI render: default; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
Calc: threaded


Immediate hang requiring force kill trying to access the Tables (click on Tables button in lefthand pane of main Base application window) with:

Version: 7.2.1.2 / LibreOffice Community
Build ID: 87b77fad49947c1441b67c559c339af8f3517e22
CPU threads: 4; OS: Mac OS X 10.16; UI render: default; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
Calc: threaded