Created attachment 175889 [details] screen cap showing action attempted to cause crash Attempting to export a drawing. 1) Open Drawing 2) File-->Export 3) Dialogue opens. At top of window, click on directory name to change directory. 4) Get spinning pinwheel of death followed by a crash--including CRASH DUMP!! Annotated dialogue window attached here. Crash dumps attached in updates. Other specifics: macOS 10.14.6 (fully patched) LO has full disk access
Created attachment 175890 [details] Crash dump 1 First crash dump
Created attachment 175891 [details] Next crash dump next, but slightly different crash dump under identical circumstances
no problem in Big Sur Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: 273a25c796fca9afa0dfadac57dc3f336831221c CPU threads: 4; OS: Mac OS X 10.16; UI render: default; VCL: osx Locale: ru-RU (ru_RU.UTF-8); UI: en-US Calc: threaded Please try reset your LibreOffice's User Profile using Help->Restart in Safe mode dialog
I reset my profile. Actually, I reset it twice. The first time I simply ran in Safe Mode. It crashed after I was able to change directories, but before I was able to click the Export key. The second time, I did a Reset to Factory Setting, resetting both "settings and UI modes" and "entire user profile." It crashed this time while it was trying to do the export. Please let me know what else you need from me.
[Automated Action] NeedInfo-To-Unconfirmed
Version: 7.2.2.2 / LibreOffice Community Build ID: 02b2acce88a210515b4a5bb2e46cbfb63fe97d56 CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx Locale: de-DE (en_DE.UTF-8); UI: en-US Calc: threaded no repro Could you install LibreOffice nightly build and see if the problem persists using that build: https://dev-builds.libreoffice.org/daily/master Note: To open LibreOffice nightly on macOS please refer to: https://support.apple.com/guide/mac-help/open-a-mac-app-from-an-unidentified-developer-mh40616
macOS 10.16 aka macOS 11.6.1
Jon: do you reproduce this with a brand new odg file containing just "test"? If no, would it be possible you attach an example file? (of course don't forget to sanitize it if needed, see https://wiki.documentfoundation.org/QA/Bugzilla/Sanitizing_Files_Before_Submission) Anyway, both crash dumps show a lot of calls to FilterHelper::filenameMatchesFilter Taking a look at it, I see: 317 bool FilterHelper::filenameMatchesFilter(NSString* sFilename) 318 { ... 355 // might be an alias 356 NSString* pResolved = resolveAlias( sFilename ); 357 if( pResolved ) 358 { 359 bool bResult = filenameMatchesFilter( pResolved ); 360 [pResolved autorelease]; 361 if( bResult ) 362 return true; 363 } 364 365 return false; 366 } (https://opengrok.libreoffice.org/xref/core/fpicker/source/aqua/FilterHelper.mm?r=33d5c024&mo=8332&fi=317#317) So it seems this recursive function is never ending. So either it could be explained by the result of pResolved being identical to sFilename and we could avoid this situation with: diff --git a/fpicker/source/aqua/FilterHelper.mm b/fpicker/source/aqua/FilterHelper.mm index 58508c434191..43d598f5a320 100644 --- a/fpicker/source/aqua/FilterHelper.mm +++ b/fpicker/source/aqua/FilterHelper.mm @@ -356,6 +356,8 @@ bool FilterHelper::filenameMatchesFilter(NSString* sFilename) NSString* pResolved = resolveAlias( sFilename ); if( pResolved ) { + if (pResolved == sFilename) + return false; // or true ? bool bResult = filenameMatchesFilter( pResolved ); [pResolved autorelease]; if( bResult ) or it can be a bit less simple with resolveAlias(A) => B (not null) resolveAlias(B) => A etc. or with more values. (I don't know if it could be possible) so in this case we may put a kind of guard to limit the number of recursions. Remark: I noticed that the only caller of "filenameMatchesFilter" was: 43 #pragma mark NSSavePanel delegate methods 44 45 - (BOOL)panel:(id)sender shouldShowFilename:(NSString *)filename 46 { 47 (void)sender; 48 if( filterHelper == nullptr ) 49 return true; 50 if( filename == nil ) 51 return false; 52 return filterHelper->filenameMatchesFilter(filename); 53 } (see https://opengrok.libreoffice.org/xref/core/fpicker/source/aqua/AquaFilePickerDelegate.mm?r=cd3c315e#45) Searching about "shouldShowFilename", it's indicated as deprecated (as some other MacOs methods used by LO) and should be replaced by panel:shouldEnableURL: (NSOpenSavePanelDelegate).(see https://developer.apple.com/documentation/objectivec/nsobject/1539030-panel) Now perhaps it doesn't change anything but just wonder if we really need to override by default behaviour. If we don't need to override, we may just remove this part. Since I don't have a Mac, I'm just trying to understand the code without the possibility to test anything here. Tor/Stephan: any thoughts here? (of course, if no time/not interested/whatever, don't hesitate to uncc yourself! :-))
Created attachment 175965 [details] Export crashes trying to export the 3rd page as JPEG The file causing the crash doesn't have anything confidential--it is for a science presentation I am writing. The export crashes when trying to export the third page. I have not had a chance to try the nightly build and probably won't before the weekend. Please let me know if you have any other questions or need more information. On a related but slightly different topic... this is one of several crashes I have experienced in LO recently when reading or writing files on a Mac. But, it is the only one which as produced a dump. What I am wondering is if maybe deprecated APIs are behind all the crashes. My other related bug ids are: 145167 145168 145189 I've had other problems, but didn't file bug reports, as no one was even acknowledging that the reports had been received... so, I figured they were not wanted! Thanks for investigating. Please let me know if you require more information. I will let you know results of latest nightly build when I have a chance to test it.
No trouble exporting with 7.3 nightly build. Retested 7.2.2.2 with sample file: - open Export crashes trying to export the 3rd page as JPEG - select page 3 - select file > export - switch `File type` to jpeg and press enter to save - confirm default export options no trouble at all, jpg exported as expected. Do you have access to a second mac at a friends or neighbours? Would be curious if it works there, but it does not seem to be a general problem in LibreOffice or your file, as export here works fine in both versions of LO. So it is something profile or machine specific with your setup. Lets wait how the nightly behaves for you.
@Steve: Sorry for the delayed response, but it has taken me a LONG time to troubleshoot this problem. I have found the ultimate cause: Use of the Mac OS Extended Journaled FS. When I use APFS or HFS+ I do not get crashes on the same files which cause CONSISTENT crashes on the Mac OS Extended J FS. I have opened a new bug report consolidating this bug with others which have the same or similar problems when can be traced back to the FS. The new bug is 145950. Please let me know if you need additional information. Once again, sorry for the long delay in responding.
I'll then put this as duplicate of the new bug you filed :) *** This bug has been marked as a duplicate of bug 145950 ***