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
Created attachment 153428 [details] Consecutive steps provoking the crash
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
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
(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.
@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.
(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.
@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 ?
(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
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
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
*** Bug 132745 has been marked as a duplicate of this bug. ***
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
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.
(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.
*** Bug 131458 has been marked as a duplicate of this bug. ***
*** Bug 133516 has been marked as a duplicate of this bug. ***
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.
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.
(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.
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 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.
Created attachment 161576 [details] Backtrace from lldb debug session
(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
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
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.
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
<a href="https://www.google.com/">:l</a> Following this topic around, and hoping your include more source to be more convincing and broad
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.
Hi Alex, Would it be possible you test https://gerrit.libreoffice.org/c/core/+/120287 on your end ?
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
(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.
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.
(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
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.
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 ?
Patch is present in master and 7.2 branch. Closing as RESOLVED FIXED for now
I tried 7.2.1 on MacOS Beta 12.0, last build, and the wizard immediately crashes after selecting the Mac OS address book.
(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
The profile was deleted. There is no opportunity to produce a backtrace. I immediately get the document recovery dialog.
(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
Created attachment 174421 [details] About Box Information Please see the attachment as requested.
(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 :-(
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)
I just tried 7.2.0.4 and it crashed. The same for 7.2.1
(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.
(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
(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.
Created attachment 174511 [details] Apple Stack Trace with nightly build after indefinite hang on attempted save of ODB file
(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.
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.
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.
(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)?
(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.
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.
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."
(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 :-(
Yup, see my comment at : bug 138715#c23
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
Bug seems to be worksforme in Version: 7.2.6.2 / LibreOffice Community - Intel version on Arm M1 processor 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 I can create an ODB file that connects to the Mac addressbook, and will display the basic addressbook table in the list of tables. I can open that table view and see the entries (read only as ever, but still an improvement on the previous crashing).
Also works on Version: 7.3.1.3 / LibreOffice Community - Arm build for M1 processor Build ID: a69ca51ded25f3eefd52d7bf9a5fad8c90b87951 CPU threads: 8; OS: Mac OS X 12.2.1; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded
Christian Lohmaier committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d1739c8c735bcf890167c63b5559f2610e5a017a tdf#126961 fix access to the macOS address book It will be available in 7.5.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.
Christian Lohmaier committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5ebbb4e2b27d3fda6af410a553a196376d92034c related tdf#126961 don't crash when access to the macOS address book is denied It will be available in 7.5.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.
Christian Lohmaier committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/83b65152c9a6547c47aabccdba6b66c0a749076b tdf#126961 fix access to the macOS address book It will be available in 7.4.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.
Christian Lohmaier committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/6782748ca5ffa036de58cf9ad63d568703180390 tdf#126961 fix access to the macOS address book It will be available in 7.3.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.
Christian Lohmaier committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/3bb757446bd6bacacfc97f02936801d8f2275b87 related tdf#126961 don't crash when access to the macOS address book is denied It will be available in 7.4.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.
Christian Lohmaier committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/d4b9f5219fa9aa9426f9815f1844c178a934205f related tdf#126961 don't crash when access to the macOS address book is denied It will be available in 7.3.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.