Open Bug 1011449 Opened 12 years ago Updated 4 months ago

mdworker is unable to load thunderbird.mdimporter, because of Library not loaded: @executable_path/libmozglue.dylib

Categories

(Thunderbird :: OS Integration, defect)

Product:
Thunderbird
Component:
OS Integration
Platform:
x86
macOS
Type:
defect

Tracking

(Not tracked)

People

(Reporter: Nomis101, Unassigned, NeedInfo)

References

Details

(Whiteboard: [regression:TB31])

Attachments

(2 files)

Small changes to Info.plist
1.33 KB, patch
Details | Diff | Splinter Review
Patch to reverse the xcodebuild changes (gives a linker error)
32.22 KB, patch
Details | Diff | Splinter Review
While testing TB 31, I had a look into Console.app. I've found there a lot of entries like: 16.05.14 12:29:45,214 mdworker[27874]: Error loading /Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/Contents/MacOS/thunderbird: dlopen(/Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/Contents/MacOS/thunderbird, 262): Library not loaded: @executable_path/libmozglue.dylib Referenced from: /Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/Contents/MacOS/thunderbird Reason: image not found 16.05.14 12:29:45,215 mdworker[27874]: Cannot find function pointer MetadataImporterPluginFactory for factory 37401ADE-1058-42DB-BBE5-F2AAB9D7C13E in CFBundle/CFPlugIn 0x7f8f98c13840 </Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter> (bundle, not loaded) 16.05.14 12:29:45,216 mdworker[27874]: (Error) Import: Could not create instance for plugIn 'file:///Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/' 16.05.14 12:29:45,216 mdworker[27874]: (Error) Import: BAD IMPORTER ~~~~~~~~~~~~~~~~~~ file:///Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/ I don't know if this means, that the mdimporter is not working currently.
Blocks: TB31found
I'm not seeing this myself but I'm sure I've disabled search integration. Nomis can you try to figure out if it's working or not ?
Sorry, the search integration is not working. I've tried with the newest TB 31 build. If I do $ /usr/bin/mdimport -L Than the plugin shows up properly in the list of Spotlight plugins. But $ /usr/bin/mdimport -d2 fails with: $ /usr/bin/mdimport -d2 /Users/Library/Caches/Metadata/Thunderbird/Mail/pop3.web-3.de/Sent.mozmsgs/536F9366.8030409\%40web.de.mozeml 2014-06-04 19:44:57.397 mdimport[9261:507] Error loading /Applications/Earlybird.app/Contents/Library/Spotlight/thunderbird.mdimporter/Contents/MacOS/thunderbird: dlopen(/Applications/Earlybird.app/Contents/Library/Spotlight/thunderbird.mdimporter/Contents/MacOS/thunderbird, 262): Library not loaded: @executable_path/libmozglue.dylib Referenced from: /Applications/Earlybird.app/Contents/Library/Spotlight/thunderbird.mdimporter/Contents/MacOS/thunderbird Reason: image not found 2014-06-04 19:44:57.398 mdimport[9261:507] Cannot find function pointer MetadataImporterPluginFactory for factory 37401ADE-1058-42DB-BBE5-F2AAB9D7C13E in CFBundle/CFPlugIn 0x7ff4e0603ba0 </Applications/Earlybird.app/Contents/Library/Spotlight/thunderbird.mdimporter> (bundle, not loaded) (Error) Import: Could not create instance for plugIn 'file:///Applications/Earlybird.app/Contents/Library/Spotlight/thunderbird.mdimporter/' (Error) Import: BAD IMPORTER ~~~~~~~~~~~~~~~~~~ file:///Applications/Earlybird.app/Contents/Library/Spotlight/thunderbird.mdimporter/ 2014-06-04 19:44:57.399 mdimport[9261:507] Imported '/Users/Library/Caches/Metadata/Thunderbird/Mail/pop3.web-3.de/Sent.mozmsgs/536F9366.8030409%40web.de.mozeml' of type 'com.mozilla.thunderbird.mozeml' with plugIn /Applications/Earlybird.app/Contents/Library/Spotlight/thunderbird.mdimporter. 2014-06-04 19:44:57.400 mdimport[9261:507] Attributes: { ":MD:kMDItemPath" = "/Users/Library/Caches/Metadata/Thunderbird/Mail/pop3.web-3.de/Sent.mozmsgs/536F9366.8030409%40web.de.mozeml"; "_kMDItemContentChangeDate" = "2014-05-11 15:11:35 +0000"; "_kMDItemCreationDate" = "2014-05-11 15:11:35 +0000"; "_kMDItemCreatorCode" = 0; "_kMDItemFileName" = "536F9366.8030409%40web.de.mozeml"; "_kMDItemFinderFlags" = 0; "_kMDItemFinderLabel" = 0; "_kMDItemIsExtensionHidden" = 0; "_kMDItemOwnerGroupID" = 20; "_kMDItemOwnerUserID" = 501; "_kMDItemStaticInterestScore" = "1.111111"; "_kMDItemTypeCode" = 0; "com_apple_metadata_modtime" = 421513895; kMDItemContentCreationDate = "2014-05-11 15:11:35 +0000"; kMDItemContentModificationDate = "2014-05-11 15:11:35 +0000"; kMDItemContentType = "com.mozilla.thunderbird.mozeml"; kMDItemContentTypeTree = ( "com.mozilla.thunderbird.mozeml", "public.data", "public.item", "public.content", "public.email-message", "public.message" ); kMDItemDateAdded = "2014-05-11 15:11:35 +0000"; kMDItemDisplayName = { "" = "536F9366.8030409%40web.de.mozeml"; }; kMDItemKind = { "" = "Thunderbird Mail Message"; }; kMDItemLogicalSize = 597; kMDItemPhysicalSize = 4096; } And it also finds no TB message from me if I search for them via Spotlight. https://developer.apple.com/library/mac/documentation/Carbon/Conceptual/MDImporters/Concepts/Troubleshooting.html
Mark do you also see this ?
10.10 is a bit more detailed (from Cosole app): 18.08.14 22:23:45,172 mdworker[5313]: Error loading /Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/Contents/MacOS/thunderbird-mdimport: dlopen(/Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/Contents/MacOS/thunderbird-mdimport, 262): Library not loaded: @executable_path/libmozglue.dylib Referenced from: /Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/Contents/MacOS/thunderbird-mdimport Reason: unsafe use of @executable_path in /Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/Contents/MacOS/thunderbird-mdimport with restricted binary
I have the same issue. Mac OS X 10.9.4
Same here. Noticed it with TB 31 on OS X 10.9.4. Used to be able to see TB emails in Spotlight search. Get the same messages in console when I look to see why I no longer get TB emails in Spotlight searches. Note that at times (very rarely), TB email files (not messages per se) somehow show up for certain Spotlight searches (I assume because some text matching was going on). I can grab and share more info if it's requested of me.
FWIW: I went ahead and renamed the Thunderbird.mdimporter directory in the Thunderbird.app for 31.0, and copied in the same from a backup of 24.6.0 (as of Jul7 19, 2014). After doing so, no more errors, and rebuilding the Spotlight index now shows real messages found within the TB 31.0 folders. However, TB 31 is not handling the request to open the specific message correctly - it just opens and displays the default account's inbox. So, I still have to search again within TB. (No errors I can see...) With the Thunderbird.mdimporter from 24.6.0, messages are again indexed correctly and there are no more errors logged regarding Spotlight and related Thunderbird 31.0 objects and functionality. However, Thunderbird 31.0 is not handling the request from the system/Spotlight to open the specific message selected within the Spotlight search results and no specific errors are written. Hope this helps.
Thats good to know. So, maybe it is related to Bug 944952? Thats the only relevant change in mdimporter I could find that happened between TB 24 and 31. Yesterday I also played a bit with the mdimporter plugin, and I was able to remove this Console log and $ /usr/bin/mdimport -d2 gives now a proper output. But I only can test this on 10.10., I don't have 10.9 anymore. I will attach a patch with the changes I've made later today.
This is, what I did yesterday to help the console message to go away. I have no idea, why this should help, but it did. Maybe it only triggered something. But, it only works in combination with the fix from Bug 1045026. And it removes this odd com.apple.yourcfbundle which is only meant as an example in the ADC documentation.
After the TB 31.3.0 installed on my Mac I started getting these errors again showing up in the console log: 14·12·17 10:24:55.588 PM mdworker[4112]: Error loading /Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/Contents/MacOS/thunderbird: dlopen(/Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/Contents/MacOS/thunderbird, 262): Library not loaded: @executable_path/libmozglue.dylib Referenced from: /Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/Contents/MacOS/thunderbird Reason: unsafe use of @executable_path in /Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/Contents/MacOS/thunderbird with restricted binary 14·12·17 10:24:55.589 PM mdworker[4112]: Cannot find function pointer MetadataImporterPluginFactory for factory 37401ADE-1058-42DB-BBE5-F2AAB9D7C13E in CFBundle/CFPlugIn 0x7f8ac04143a0 </Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter> (bundle, not loaded) 14·12·17 10:24:55.589 PM mdworker[4112]: (Import.Error:711) Could not create instance for plugIn 'file:///Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/' 14·12·17 10:24:55.589 PM mdworker[4112]: (Import.Error:867) BAD IMPORTER ~~~~~~~~~~~~~~~~~~ file:///Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/ which would repeat every half hour or so, I imagine each time the Spotlight indexer was trying to load TB's mdimporter. It seems like @executable_path is unsafe to use as it is for some reason or perhaps was just aimed at the wrong place to find TB's mdimporter. I used the following to change the reference to the libmozglue.dylib to use @loader_path rather than @executable_path and ran "mdimport" and the errors from the console log are now gone: install_name_tool -change @executable_path/libmozglue.dylib @loader_path/../../MacOS/libmozglue.dylib (which changes: @executable_ path/libmozglue.dylib to @loader_path/../../MacOS/libmozglue.dylib ) I imagine this change can be made when the application is linked and the dylibs are specified or it could be made after linking as I did. (I'm not skilled enough to know how to put it all together, though, but I hope this helps someone to make the change if needed.
This is interesting to know and reminds me to Bug 578751. Does it also work for you if you use @rpath?
At the moment it's not working again. As far as I know, it had worked but something is different (maybe the relative directory reference since I'm not totally comfortable with where the @loader_path is starting from). I'm looking further though I don't have much time today. Instead of trying to work on the @loader_path method I'll make an attempt to try a fix using @rpath. If it works (or worked) with @loader_path I'd think it should work with @rpath but didn't have the time or focus to continue earlier. I'll get back as soon as I have more idea of what's going on.
Sorry, was researching the various ways that libraries are found and then went to bed with a cold for 2 days. The problem I had is not clear to me yet but appeared as system console errors after an update from an earlier version of Thunderbird (24.?.?) to the 31.3.0. In my incremental learning process I somewhat lost track of the exact changes I had made and finally "reinstalled" the newest release of Thunderbird (31.3.0) and then everything was fine once more. Fortunately I still have the original 24.?.? version I had during the update which I want to put back in place and then do an upgrade to 31.3.0 and see if the problem recurs. If so it may be a a delay OS X's use of the newest Spotlight importer or a cache file that needed to be updated which could be just a temporary glitch until the system irons out everything or it may indicate that something should be done in an upgrade to get everything in sync right away. At this point my thought is that it isn't a permanent problem when it occurs but that's a guess. As to the @executable_path versus the @loader_path (and possibly @rpath), since I'm not yet sure of what state everything was in when the problem occurred it's hard to say if there is any problem. Now that I know more it seems that, unless there has been a restriction of some sort added as to using @executable_path in some situations (due to jeopardizing one's system), it seems that either @executable_path or @loader_path or @rpath (which would reference one of those anyway) should work since the directory structure of the Thunderbird.app where the Spotlight importer lives is stable and doesn't shift around in a way that @executable_path or @loader_path couldn't deal with. I'll add more as I find out anything of concern. (Interestingly, while playing around with this issue I've encountered the "thunderbird triggered DYLD shared region unnest for…" issue which both Thunderbird and Firefox seem to be running against which might be a more useful thing to pursue but I think that can be done in parallel with this. Also, what I've learned from this may shine some light on Bug 578751 too and I'll keep that in mind as I go.
I see the same errors on TB 34 on my Yosemite MacPro: Jan 3 15:06:15 jarmac-2.local mdworker[38527]: Error loading /Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/Contents/MacOS/thunderbird-mdimport: dlopen(/Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/Contents/MacOS/thunderbird-mdimport, 262): Library not loaded: @executable_path/libmozglue.dylib Referenced from: /Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/Contents/MacOS/thunderbird-mdimport Reason: unsafe use of @executable_path in /Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/Contents/MacOS/thunderbird-mdimport with restricted binary Jan 3 15:06:15 jarmac-2.local mdworker[38527]: Cannot find function pointer MetadataImporterPluginFactory for factory 37401ADE-1058-42DB-BBE5-F2AAB9D7C13E in CFBundle/CFPlugIn 0x7f838850e2d0 </Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter> (bundle, not loaded) Jan 3 15:06:15 jarmac-2.local mdworker[38527]: (Import.Error:711) Could not create instance for plugIn 'file:///Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/' Jan 3 15:06:15 jarmac-2.local mdworker[38527]: (Import.Error:867) BAD IMPORTER ~~~~~~~~~~~~~~~~~~ file:///Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/
@James: Did you upgrade the TB to 34 in response to TB letting you know it was there and telling it to upgrade or did you download a new copy and install it yourself? At some point once you've rebooted and after starting TB at least once to kick in the Spotlight Importer it would be good to know if those are still occurring for you. If not that might indicate that there's a conflict between the pre and post upgraded TB importers or libraries that might resolve itself after rebooting. My current TB 31 seems to be working OK now. When I went back and forth installing the old version I had been using and upgrading to the newer one I wasn't able to replicate the problem.
I don't remember how I upgraded. I think it updated. But I stopped and started TB again this morning, and so far none of these messages have appeared.
James> Thanks for checking that out. That seems to fit in with my experience. If I remember correctly about Spotlight Importers that reside in an application bundle (as this one is) they are loaded when the application is started. Ignoring other subtleties I'd assume that if TB updates itself and asks to be restarted for updates to take effect that it restarts in a way that doesn't trigger reloading the importer. Then the TB application bundle (and the dynamic libraries and references it contains) might be out of sync with the currently loaded older importer causing this issue to emerge until TB is restarted in a way that would reload the importer and bring everything back into sync. That be a reboot or logoff/login or whatever but it seems to be a transitory issue that solves itself quickly (unless, for example, should a reboot be required, one doesn't reboot for a long time). If this issue were to be looked at it should probably be examined in the light of upgrading TB since the current code does seem to work OK.
I am getting werrors again: Jan 14 09:13:50 jarmac-2.local mdworker[90209]: Error loading /Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/Contents/MacOS/thunderbird-mdimport: dlopen(/Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/Contents/MacOS/thunderbird-mdimport, 262): Library not loaded: @executable_path/libmozglue.dylib Referenced from: /Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/Contents/MacOS/thunderbird-mdimport Reason: unsafe use of @executable_path in /Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/Contents/MacOS/thunderbird-mdimport with restricted binary
I am also getting the "@executable_path" and "BAD IMPORTER ~~~~~~…" errors again myself. I've now done some exhausting (if not exhaustive) testing to try to see why it happens and then may disappear or come back at seemingly random times. At this point I'm almost certain (I'll never be totally!) that is has to do with the executable files with their quarantine attribute set when they are downloaded (which is correct) but not being removed after the first execution of Thunderbird. This seems to agree with problems other developers have had to deal with when securing applications for OS X. Here is what I'm finding on my system (and which is probably the same for others (though the behavior might vary depending on what security preferences a user has set): - If I remove TB from my /Applications folder, download a fresh copy and drag it to /Applications all of the files in the bundle are marked with the quarantine attribute. - When I open it I'm asked to OK it (since it has been downloaded) so I click OK and it runs. When I check the bundle's files with xattr I see the quarantine attributes are still set although I am no longer asked to OK it when I start it (same behavior as other developers have described). (Currently I have my security set to allow applications from the AppStore or identified developers.) - Even though TB starts up OK the TB MDImporter fails with the errors mentioned earlier. If I use xattr to clear the extended attributes from the downloaded files and then use mdimport to reindex TB mail files (or wait until it is done automatically) then the TB MDImporter functions correctly. - If a manual download and complete copy of a new TB release is done then the situation is the same as loading a fresh copy since all the files' quarantine attributes are turned on again. If an automatic update occurs then any files that are replaced are marked as quarantined; that means that most or all files are quarantined but (due to the way TB updates itself, I think) most or all of the directories remain non-quarantined. The effect is the same though since the "thunderbird.mdimporter" executable is quarantined. - The problem is that since the TB MDImporter is started by MDS automatically the only place that one would see a problem is from the error messages that are written to the console log; most user's would never see them and the only indication of a problem is when spotlight can't find TB mail files that it should. (And, IMHO, spotlight has enough problems due to various issues that cause it to miss showing relevant files that even that is hard to know is happening.) - If the quarantine attribute is cleared from the TB MDImporter sub-bundle then it will again function correctly. - Finally I found in Apple's code signing guide the following requirement: "You should sign every executable in your product, including applications, tools, hidden helper tools, utilities and so forth. Signing an application bundle covers its resources, but not its subcomponents such as tools and sub-bundles. Each of these must be signed independently." TB has the bundle's main application code signed but there is no code signature (which should be identical to the existing one) applied to the MDImporter sub-bundle. I've not tested it (unfortunately, I don't have time to learn the skills to do so or even time to do it myself) but it seems likely that with the proper code signing that the current problems with the TB MDImporter might be resolved. - In the meantime for those who want to attempt to fix their TB spotlight indexing it may be necessary to use xattr to clear the quarantine attributes from the entire TB bundle and contained sub-bundles, etc. This can be done within the terminal as: xattr -cr /Applications/Thunderbird.app That command will recursively [r] clear [c] the entire Thunderbird.app directory tree. The next time Thunderbird is started MDS should pick up the TB MDImporter and run it without errors. I'm still getting a spurious error when I use mdimport to reindex the TB files but don't seem to get it if I invoke the TB MDImporter by starting up TB and letting MDS do the auto start up of TB's importer. Hopefully some improvement with the code signing (and perhaps other security issues that may be involved) will get things totally in working order. (I wish I was 100% certain of that but that's all I can deal with just now; I'll post again if things go bad.) Zhora
Almost forgot! If you do the xattr clear fix I mentioned you should also make sure that the dates on the files of the TB MDImporter are changed or a new execution of it won't happen. Probably only the MDImporter sub-bundle needs to be changed but I updated the dates on the entire Thunderbird.app tree like this: find /Applications/Thunderbird.app -exec touch {} \; That seems to have fixed the remaining errors but as I said, I'll post again if there are problems. Zhora
After doing the above, I still get these messages: Feb 10 09:48:29 jarmac.local thunderbird[95220]: Performance: Please update this scripting addition to supply a value for ThreadSafe for each event handler: "/Library/ScriptingAdditions/SIMBL.osax" Feb 10 09:48:31 jarmac.local thunderbird[95220]: GetDYLDEntryPointWithImage(/System/Library/Frameworks/AppKit.framework/Versions/Current/AppKit,_NSCreateAppKitServicesMenu) failed.
And the mdimporter messages are back: Feb 12 10:46:37 jarmac.local mdworker[26976]: (Import.Error:867) BAD IMPORTER ~~~~~~~~~~~~~~~~~~ file:///Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/ Also, I can no longer send mail!
James Rome: You didn't say exactly what you did but if it was any of the above then the only thing that would be changed from doing those things would be your Thunderbird.app bundle. In that case you can revert from any changes that may have caused problems by downloading your current version of Thunderbird and copying it to /Applications (replacing the version you have). That doesn't touch any of your mailboxes or mail or extensions which are stored in your Thunderbird profile, not in the Thunderbird.app application. SIMBL is a third party "extension" that alters some of the internal opertations (code) in OS X and is often installed by other extensions or applications to allow them to do certain things that can't be done in the allowed (by Apple) ways. Depending on how it is being used it may or may not cause problems in the operation of other software or OS X in general. (Note that I'm not saying that one should or shouldn't use it but should be aware that it may cause other OS X internal or third-party code to misbehave, especially if it isn't kept updated as need be. It's sometimes used for ad blockers or anything that needs to perform some function that for good or bad Apple has made impossible or difficult to do. I used to have it installed and eventually removed it and the applications that depended on it due to various problems that it caused for me.) From what you've said I'd guess that some extension for Thunderbird that has been installed has installed SIMBL for it's own use. From the message it appears that something referred to as "jarmac.local" is using SIMBL in a way that is failing and causing an error in a call to the AppKit library. The message says to update jarmac to hopefully correct the problem. Whether that suggestion is coming from "jarmac" itself or some other place I can't say and can't say if or if not "jarmac" can be updated or if it will help. As I said earlier, the way to fix it is to either install a fresh copy of Thunderbird.app or (if "jarmac" or SIMBL have altered the Thunderbird.app in some way (which they shouldn't really) reload Thunderbird.app from a recent backup before you made any of the changes that may have caused the problem. (If somehow there have been other changes to files outside of the Thunderbird.app then they should be identified and corrected in the same sort of way or by some other means. That is the situation with the error messages you show in comment 21. The "BAD IMPORTER" messag in comment 22 is again the original problem which, after finally downloading several of the minor updates to Thunderbird 31 (31.4, 31.3, 31.2 and 31.0), shows that the MDImporer for Thunderbird is broken (there appears to be no generated code in the importer app). I did downloaded Thunderbird 24.? which I was able to find quickly and verified that it did contain the MDImporter code. So at this point it appears that none of the Thunderbird MDImporters that have shipped with Thunderbird 31 have been functional copies. (I'll expand on this soon but don't have the time just now…in any case it doesn't matter until a working MDImporter is able to be produced which means only that currently, Thunderbird 31 is not able to index it's mail files for Spotlight's use. If that is absolutely needed by someone then for now they probably need to downgrade to a working version though I haven't myself determined when the broken MDImporter began to be distributed.)
Noomis, I now see what's wrong though I don't know enough about how the build process works to be able to say why. All of the TB releases starting at some point after 24.8.1 (including all the current 31.x releases have mdimporter executables that appear to contain no compiled object code. I've been running the otool command on the mdimporter executable for various TB releases to decompile the code like so… otool -tV /Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/Contents/MacOS/thunderbird (shown for TB in /Applications though it can be looked at wherever one copies TB.) Here is the beginning of the results of the otool disassembly for TB 24.8.1: /Users/zhora/Desktop/test TB/Thunderbird 24.8.1.app/Contents/Library/Spotlight/thunderbird.mdimporter/Contents/MacOS/thunderbird: ------------------------------------------ (__TEXT,__text) section _AllocMetadataImporterPluginType: 000000000000074c pushq %rbp 000000000000074d movq %rsp, %rbp 0000000000000750 pushq %r14 0000000000000752 pushq %rbx 0000000000000753 movq %rdi, %rbx 0000000000000756 movl $0x18, %edi 000000000000075b callq 0xc7a ## symbol stub for: _malloc 0000000000000760 movq %rax, %r14 0000000000000763 movq $0x0, 0x10(%r14) 000000000000076b movq $0x0, 0x8(%r14) 0000000000000773 movq $0x0, (%r14) 000000000000077a leaq 0x96f(%rip), %rax 0000000000000781 movq %rax, (%r14) 0000000000000784 movq %rbx, %rdi 0000000000000787 callq 0xc56 ## symbol stub for: _CFRetain 000000000000078c movq %rax, 0x8(%r14) 0000000000000790 movq %rbx, %rdi 0000000000000793 callq 0xc2c ## symbol stub for: _CFPlugInAddInstanceForFactory 0000000000000798 movl $0x1, 0x10(%r14) 00000000000007a0 movq %r14, %rax 00000000000007a3 popq %rbx 00000000000007a4 popq %r14 00000000000007a6 popq %rbp 00000000000007a7 retq _MetadataImporterPluginAddRef: 00000000000007a8 pushq %rbp 00000000000007a9 movq %rsp, %rbp 00000000000007ac movl 0x10(%rdi), %eax …and so on, you get the idea. ------------------------------------------ Here is what I'm seeing in the later, including the current, mdimporters for TB… ------------------------------------------ /Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/Contents/MacOS/thunderbird: (__TEXT,__text) section ------------------------------------------ That's all…pretty much nothing! So it seems that something is going wrong in the TB build that causes a failure in the compilation/linking/whatever that constructs the mdimporter execuatble (at least). I'm pretty sure that this "null" executable is the cause of the error we're seeing in the console log regarding @executable_path error. Since our TB build is stable in terms of where each of the libraries is located in relation to anything else I believe that it doesn't matter if we use @executable_path, @loader_path or @rpath since we have a known hierarchy of directories to traverse to get to (in this case) the libmozglue.dylib. That can be checked once the source of the build error is determined. It, of course, would also be good to see what needs to be done to test that the build of the importer at least produces code and better yet correct code.) I attempted to set up my own build of FF/TB to be able to test some of this but I'm afraid that it's too much for me to comprehend at the moment and would be lots easier for someone with the right experience to handle (such as you?). Anyway, that's why I'm aiming this at you so that you can make whatever changes, flagging, comments, etc. are required to bring this bug into it's correct form to be handled. Sorry I don't have the time to do more just now but I unfortunately have basic living issues, i.e. food, money, shelter that need to be dealt with. I'll note one other thing…I looked at the latest beta release, TB 36.0b1, and in that release the final MacOS/thunderbird branch of the mdimporter appears to be missing completely. I'm not sure if that is intentional or not but being a beta release (I think) I suspect it's a problem. In anycase I plan to graft the mdimporter from 24.8.1 onto 31.4 and see if that works OK since it doesn't appear that much has changed with the importer and I think the dynamic library's connections to the importer should be…well…dynamic and should work. I'll try to remember to come back and say what I find. And after all the false leads that seemed to be this or that or whatever along the way, I have to finish by quoting the very first paragraph of Apple's "Troubleshooting Spotlight Importers" section of the "Spotlight Importer Developer's Guide: "Rare is the project that is flawless from the start. Troubleshooting a Spotlight importer can be difficult given that it is run by the system automatically as required and is run outside the development environment." Damn right it's difficult! I think it's worth noting that without removing (or obscuring) every other version of an mdimporter that has previously loaded and restarting (and perhaps even more than that) you'll never be sure if the mdimporter you are running is the version you think it is or not. In trying to test an mdimporter for a different version of TB than I had been "running" I eventually found that the system was actually running the mdimporter execuatable that was in the TB that was in the Trash! (And, if I recall correctly, which I won't vouch for, that was occurring AFTER I had restarted the machine with TB in the Trash. Difficult, difficult, difficult!!!
Flags: needinfo?(Nomis101)
Interestingly, in the newer builds (current beta and trunk) I don't see any folder "MacOS" in /Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/Contents This is only present in older builds (24). Thats an issue! What versions have you tested?
Flags: needinfo?(Nomis101)
Here's the mdimporter tree portion of various TB releases that I've looked at (I've added the version numbers into the "Thunderbird.app" name after downloading to keep things organized: ------------------------------------------------------------------------ Here's the TB 24.8.1 release which is the last non-beta release that seems to contain a valid TB mdimporter: Thunderbird\ 24.8.1.app/ ├── Contents │   ├── CodeResources │   ├── Info.plist │   ├── Library │   │   └── Spotlight │   │   └── thunderbird.mdimporter │   │   └── Contents │   │   ├── Info.plist │   │   ├── MacOS │   │   │   └── thunderbird │   │   └── Resources │   │   ├── English.lproj │   │   │   ├── InfoPlist.strings │   │   │   └── schema.strings │   │   └── schema.xml │   ├── MacOS │   │   ├── XUL │   │   ├── application.ini │   │   ├── blocklist.xml │   │   ├── crashreporter.app (rest of TB.app tree omitted) otool -tV for the 24.8.1 mdimporter (mdimporter is still named "thunderbird") shows what is probably normal code: Thunderbird 24.8.1.app/Contents/Library/Spotlight/thunderbird.mdimporter/Contents/MacOS/thunderbird: (__TEXT,__text) section _AllocMetadataImporterPluginType: 000000000000074c pushq %rbp 000000000000074d movq %rsp, %rbp 0000000000000750 pushq %r14 0000000000000752 pushq %rbx 0000000000000753 movq %rdi, %rbx 0000000000000756 movl $0x18, %edi 000000000000075b callq 0xc7a ## symbol stub for: _malloc 0000000000000760 movq %rax, %r14 0000000000000763 movq $0x0, 0x10(%r14) 000000000000076b movq $0x0, 0x8(%r14) 0000000000000773 movq $0x0, (%r14) 000000000000077a leaq 0x96f(%rip), %rax 0000000000000781 movq %rax, (%r14) 0000000000000784 movq %rbx, %rdi 0000000000000787 callq 0xc56 ## symbol stub for: _CFRetain 000000000000078c movq %rax, 0x8(%r14) 0000000000000790 movq %rbx, %rdi 0000000000000793 callq 0xc2c ## symbol stub for: _CFPlugInAddInstanceForFactory 0000000000000798 movl $0x1, 0x10(%r14) 00000000000007a0 movq %r14, %rax 00000000000007a3 popq %rbx 00000000000007a4 popq %r14 00000000000007a6 popq %rbp 00000000000007a7 retq _MetadataImporterPluginAddRef: 00000000000007a8 pushq %rbp 00000000000007a9 movq %rsp, %rbp 00000000000007ac movl 0x10(%rdi), %eax 00000000000007af incl %eax 00000000000007b1 movl %eax, 0x10(%rdi) 00000000000007b4 popq %rbp 00000000000007b5 retq _MetadataImporterQueryInterface: 00000000000007b6 pushq %rbp 00000000000007b7 movq %rsp, %rbp 00000000000007ba pushq %r15 00000000000007bc pushq %r14 00000000000007be pushq %r12 00000000000007c0 pushq %rbx 00000000000007c1 subq $0x60, %rsp 00000000000007c5 movq %rcx, %rbx 00000000000007c8 movq %rdi, %r14 00000000000007cb movq 0x83e(%rip), %rax ## literal pool symbol address: _kCFAllocatorDefault 00000000000007d2 movq (%rax), %r15 00000000000007d5 movq %r15, %rdi 00000000000007d8 callq 0xc68 ## symbol stub for: _CFUUIDCreateFromUUIDBytes 00000000000007dd movq %rax, %r12 00000000000007e0 movl $0xfc, 0x50(%rsp) 00000000000007e8 movl $0x26, 0x48(%rsp) 00000000000007f0 movl $0x67, 0x40(%rsp) 00000000000007f8 movl $0x93, 0x38(%rsp) 0000000000000800 movl $0x3, 0x30(%rsp) 0000000000000808 movl $0x0, 0x28(%rsp) 0000000000000810 movl $0xae, 0x20(%rsp) 0000000000000818 movl $0x84, 0x18(%rsp) 0000000000000820 movl $0xd8, 0x10(%rsp) 0000000000000828 movl $0x11, 0x8(%rsp) 0000000000000830 movl $0x9c, (%rsp) 0000000000000837 movl $0x6e, %esi 000000000000083c movl $0xbc, %edx 0000000000000841 movl $0x27, %ecx 0000000000000846 movl $0xc4, %r8d 000000000000084c movl $0x89, %r9d 0000000000000852 movq %r15, %rdi 0000000000000855 callq 0xc6e ## symbol stub for: _CFUUIDGetConstantUUIDWithBytes 000000000000085a movq %r12, %rdi 000000000000085d movq %rax, %rsi 0000000000000860 callq 0xc26 ## symbol stub for: _CFEqual 0000000000000865 testb %al, %al 0000000000000867 je 0x884 0000000000000869 movq (%r14), %rax 000000000000086c movq %r14, %rdi 000000000000086f callq *0x10(%rax) 0000000000000872 movq %r14, (%rbx) 0000000000000875 movq %r12, %rdi 0000000000000878 callq 0xc50 ## symbol stub for: _CFRelease 000000000000087d xorl %eax, %eax 000000000000087f jmp 0x91d 0000000000000884 movl $0x46, 0x50(%rsp) 000000000000088c movl $0x0, 0x48(%rsp) 0000000000000894 movl $0x0, 0x40(%rsp) 000000000000089c movl $0x0, 0x38(%rsp) 00000000000008a4 movl $0x0, 0x30(%rsp) 00000000000008ac movl $0x0, 0x28(%rsp) 00000000000008b4 movl $0x0, 0x20(%rsp) 00000000000008bc movl $0xc0, 0x18(%rsp) 00000000000008c4 movl $0x0, 0x10(%rsp) 00000000000008cc movl $0x0, 0x8(%rsp) 00000000000008d4 movl $0x0, (%rsp) 00000000000008db movq 0x736(%rip), %rax ## literal pool symbol address: _kCFAllocatorSystemDefault 00000000000008e2 movq (%rax), %rdi 00000000000008e5 xorl %esi, %esi 00000000000008e7 xorl %edx, %edx 00000000000008e9 xorl %ecx, %ecx 00000000000008eb xorl %r8d, %r8d 00000000000008ee xorl %r9d, %r9d 00000000000008f1 callq 0xc6e ## symbol stub for: _CFUUIDGetConstantUUIDWithBytes 00000000000008f6 movq %r12, %rdi 00000000000008f9 movq %rax, %rsi 00000000000008fc callq 0xc26 ## symbol stub for: _CFEqual 0000000000000901 testb %al, %al 0000000000000903 jne 0x869 0000000000000909 movq $0x0, (%rbx) 0000000000000910 movq %r12, %rdi 0000000000000913 callq 0xc50 ## symbol stub for: _CFRelease 0000000000000918 movl $0x80000004, %eax ## imm = 0x80000004 000000000000091d addq $0x60, %rsp 0000000000000921 popq %rbx 0000000000000922 popq %r12 0000000000000924 popq %r14 0000000000000926 popq %r15 0000000000000928 popq %rbp 0000000000000929 retq _DeallocMetadataImporterPluginType: 000000000000092a pushq %rbp 000000000000092b movq %rsp, %rbp 000000000000092e pushq %rbx 000000000000092f subq $0x8, %rsp 0000000000000933 movq 0x8(%rdi), %rbx 0000000000000937 callq 0xc74 ## symbol stub for: _free 000000000000093c testq %rbx, %rbx 000000000000093f jne 0x948 0000000000000941 addq $0x8, %rsp 0000000000000945 popq %rbx 0000000000000946 popq %rbp 0000000000000947 retq 0000000000000948 movq %rbx, %rdi 000000000000094b callq 0xc32 ## symbol stub for: _CFPlugInRemoveInstanceForFactory 0000000000000950 movq %rbx, %rdi 0000000000000953 addq $0x8, %rsp 0000000000000957 popq %rbx 0000000000000958 popq %rbp 0000000000000959 jmp 0xc50 ## symbol stub for: _CFRelease _MetadataImporterPluginRelease: 000000000000095e pushq %rbp 000000000000095f movq %rsp, %rbp 0000000000000962 movl 0x10(%rdi), %eax 0000000000000965 decl %eax 0000000000000967 movl %eax, 0x10(%rdi) 000000000000096a testl %eax, %eax 000000000000096c jne 0x975 000000000000096e callq _DeallocMetadataImporterPluginType 0000000000000973 xorl %eax, %eax 0000000000000975 popq %rbp 0000000000000976 retq _MetadataImporterPluginFactory: 0000000000000977 pushq %rbp 0000000000000978 movq %rsp, %rbp 000000000000097b pushq %r14 000000000000097d pushq %rbx 000000000000097e subq $0x60, %rsp 0000000000000982 movq %rsi, %rbx 0000000000000985 movl $0xfc, 0x50(%rsp) 000000000000098d movl $0x26, 0x48(%rsp) 0000000000000995 movl $0x67, 0x40(%rsp) 000000000000099d movl $0x93, 0x38(%rsp) 00000000000009a5 movl $0x3, 0x30(%rsp) 00000000000009ad movl $0x0, 0x28(%rsp) 00000000000009b5 movl $0xf9, 0x20(%rsp) 00000000000009bd movl $0xb3, 0x18(%rsp) 00000000000009c5 movl $0xd8, 0x10(%rsp) 00000000000009cd movl $0x11, 0x8(%rsp) 00000000000009d5 movl $0x5b, (%rsp) 00000000000009dc movq 0x62d(%rip), %rax ## literal pool symbol address: _kCFAllocatorDefault 00000000000009e3 movq (%rax), %rdi 00000000000009e6 movl $0x8b, %esi 00000000000009eb movl $0x8, %edx 00000000000009f0 movl $0xc4, %ecx 00000000000009f5 movl $0xbf, %r8d 00000000000009fb movl $0x41, %r9d 0000000000000a01 callq 0xc6e ## symbol stub for: _CFUUIDGetConstantUUIDWithBytes 0000000000000a06 movq %rbx, %rdi 0000000000000a09 movq %rax, %rsi 0000000000000a0c callq 0xc26 ## symbol stub for: _CFEqual 0000000000000a11 testb %al, %al 0000000000000a13 je 0xa46 0000000000000a15 movq 0x5f4(%rip), %rax ## literal pool symbol address: _kCFAllocatorDefault 0000000000000a1c movq (%rax), %rdi 0000000000000a1f leaq 0x6f2(%rip), %rsi ## Objc cfstring ref: @"37401ADE-1058-42DB-BBE5-F2AAB9D7C13E" 0000000000000a26 callq 0xc62 ## symbol stub for: _CFUUIDCreateFromString 0000000000000a2b movq %rax, %rbx 0000000000000a2e movq %rbx, %rdi 0000000000000a31 callq _AllocMetadataImporterPluginType 0000000000000a36 movq %rax, %r14 0000000000000a39 movq %rbx, %rdi 0000000000000a3c callq 0xc50 ## symbol stub for: _CFRelease 0000000000000a41 movq %r14, %rax 0000000000000a44 jmp 0xa48 0000000000000a46 xorl %eax, %eax 0000000000000a48 addq $0x60, %rsp 0000000000000a4c popq %rbx 0000000000000a4d popq %r14 0000000000000a4f popq %rbp 0000000000000a50 retq _GetMetadataForFile: 0000000000000a51 pushq %rbp 0000000000000a52 movq %rsp, %rbp 0000000000000a55 pushq %r15 0000000000000a57 pushq %r14 0000000000000a59 pushq %r13 0000000000000a5b pushq %r12 0000000000000a5d pushq %rbx 0000000000000a5e subq $0x18, %rsp 0000000000000a62 movq %rsi, %rbx 0000000000000a65 movq 0x5a4(%rip), %rax ## literal pool symbol address: _kCFAllocatorDefault 0000000000000a6c movq (%rax), %r14 0000000000000a6f movq %r14, %rdi 0000000000000a72 movq %rcx, %rsi 0000000000000a75 xorl %edx, %edx 0000000000000a77 xorl %ecx, %ecx 0000000000000a79 callq 0xc5c ## symbol stub for: _CFURLCreateWithFileSystemPath 0000000000000a7e movq %rax, %r15 0000000000000a81 movq %r14, %rdi 0000000000000a84 movq %r15, %rsi 0000000000000a87 callq 0xc44 ## symbol stub for: _CFReadStreamCreateWithFile 0000000000000a8c movq %rax, %r12 0000000000000a8f movq %r12, %rdi 0000000000000a92 callq 0xc4a ## symbol stub for: _CFReadStreamOpen 0000000000000a97 movq $0x0, -0x38(%rbp) 0000000000000a9f leaq -0x30(%rbp), %r8 0000000000000aa3 leaq -0x38(%rbp), %r9 0000000000000aa7 movq %r14, %rdi 0000000000000aaa movq %r12, %rsi 0000000000000aad xorl %edx, %edx 0000000000000aaf xorl %ecx, %ecx 0000000000000ab1 callq 0xc38 ## symbol stub for: _CFPropertyListCreateFromStream 0000000000000ab6 cmpq $0x0, -0x38(%rbp) 0000000000000abb je 0xae2 0000000000000abd leaq 0x2d1(%rip), %rdi ## literal pool for: "failed creating property list from stream" 0000000000000ac4 callq 0xc86 ## symbol stub for: _puts 0000000000000ac9 movq -0x38(%rbp), %rsi 0000000000000acd leaq 0x2eb(%rip), %rdi ## literal pool for: "error = %s\n" 0000000000000ad4 xorb %bl, %bl 0000000000000ad6 xorb %al, %al 0000000000000ad8 callq 0xc80 ## symbol stub for: _printf 0000000000000add jmp 0xbe4 0000000000000ae2 movq %rax, %r14 0000000000000ae5 movq 0x54c(%rip), %rax ## literal pool symbol address: _kMDItemTitle 0000000000000aec movq (%rax), %rsi 0000000000000aef movq %r14, %rdi 0000000000000af2 callq 0xc1a ## symbol stub for: _CFDictionaryGetValue 0000000000000af7 testq %rax, %rax 0000000000000afa je 0xb11 0000000000000afc movq 0x535(%rip), %rcx ## literal pool symbol address: _kMDItemTitle 0000000000000b03 movq (%rcx), %rsi 0000000000000b06 movq %rbx, %rdi 0000000000000b09 movq %rax, %rdx 0000000000000b0c callq 0xc20 ## symbol stub for: _CFDictionarySetValue 0000000000000b11 movq 0x518(%rip), %rax ## literal pool symbol address: _kMDItemTextContent 0000000000000b18 movq (%rax), %rsi 0000000000000b1b movq %r14, %rdi 0000000000000b1e callq 0xc1a ## symbol stub for: _CFDictionaryGetValue 0000000000000b23 testq %rax, %rax 0000000000000b26 je 0xb3d 0000000000000b28 movq 0x501(%rip), %rcx ## literal pool symbol address: _kMDItemTextContent 0000000000000b2f movq (%rcx), %rsi 0000000000000b32 movq %rbx, %rdi 0000000000000b35 movq %rax, %rdx 0000000000000b38 callq 0xc20 ## symbol stub for: _CFDictionarySetValue 0000000000000b3d movq 0x4dc(%rip), %rax ## literal pool symbol address: _kMDItemDisplayName 0000000000000b44 movq (%rax), %rsi 0000000000000b47 movq %r14, %rdi 0000000000000b4a callq 0xc1a ## symbol stub for: _CFDictionaryGetValue 0000000000000b4f testq %rax, %rax 0000000000000b52 je 0xb69 0000000000000b54 movq 0x4c5(%rip), %rcx ## literal pool symbol address: _kMDItemDisplayName 0000000000000b5b movq (%rcx), %rsi 0000000000000b5e movq %rbx, %rdi 0000000000000b61 movq %rax, %rdx 0000000000000b64 callq 0xc20 ## symbol stub for: _CFDictionarySetValue 0000000000000b69 xorl %edi, %edi 0000000000000b6b movl $0x3, %edx 0000000000000b70 xorl %esi, %esi 0000000000000b72 movl $0x3, %ecx 0000000000000b77 callq 0xc0e ## symbol stub for: _CFDateFormatterCreate 0000000000000b7c movq %rax, %r13 0000000000000b7f movq 0x4a2(%rip), %rax ## literal pool symbol address: _kMDItemLastUsedDate 0000000000000b86 movq (%rax), %rsi 0000000000000b89 movq %r14, %rdi 0000000000000b8c callq 0xc1a ## symbol stub for: _CFDictionaryGetValue 0000000000000b91 testq %rax, %rax 0000000000000b94 je 0xbe2 0000000000000b96 testq %r13, %r13 0000000000000b99 je 0xbe2 0000000000000b9b movq %rax, %r14 0000000000000b9e leaq 0x226(%rip), %rdi ## literal pool for: "trying to parse date " 0000000000000ba5 callq 0xc86 ## symbol stub for: _puts 0000000000000baa xorl %edi, %edi 0000000000000bac movq %r13, %rsi 0000000000000baf movq %r14, %rdx 0000000000000bb2 xorl %ecx, %ecx 0000000000000bb4 callq 0xc14 ## symbol stub for: _CFDateFormatterCreateDateFromString 0000000000000bb9 movq %rax, %r14 0000000000000bbc leaq 0x21e(%rip), %rdi ## literal pool for: "got cur date" 0000000000000bc3 callq 0xc86 ## symbol stub for: _puts 0000000000000bc8 testq %r14, %r14 0000000000000bcb je 0xbe2 0000000000000bcd movq %r14, %rdx 0000000000000bd0 movq 0x451(%rip), %rax ## literal pool symbol address: _kMDItemLastUsedDate 0000000000000bd7 movq (%rax), %rsi 0000000000000bda movq %rbx, %rdi 0000000000000bdd callq 0xc20 ## symbol stub for: _CFDictionarySetValue 0000000000000be2 movb $0x1, %bl 0000000000000be4 movq %r12, %rdi 0000000000000be7 callq 0xc3e ## symbol stub for: _CFReadStreamClose 0000000000000bec movq %r12, %rdi 0000000000000bef callq 0xc50 ## symbol stub for: _CFRelease 0000000000000bf4 movq %r15, %rdi 0000000000000bf7 callq 0xc50 ## symbol stub for: _CFRelease 0000000000000bfc movzbl %bl, %eax 0000000000000bff addq $0x18, %rsp 0000000000000c03 popq %rbx 0000000000000c04 popq %r12 0000000000000c06 popq %r13 0000000000000c08 popq %r14 0000000000000c0a popq %r15 0000000000000c0c popq %rbp 0000000000000c0d retq ------------------------------------------------------------------------ Here is TB 30.0b1 (mdimporter executable is still named "thunderbird" but now appears to not have code): Thunderbird\ 30.0b1.app/ ├── Contents │ ├── CodeResources │ ├── Info.plist │ ├── Library │ │ └── Spotlight │ │ └── thunderbird.mdimporter │ │ └── Contents │ │ ├── Info.plist │ │ ├── MacOS │ │ │ └── thunderbird <----mdimporter executable │ │ └── Resources │ │ ├── English.lproj │ │ │ ├── InfoPlist.strings │ │ │ └── schema.strings │ │ └── schema.xml │ ├── MacOS │ │ ├── XUL │ │ ├── application.ini │ │ ├── blocklist.xml │ │ ├── crashreporter.app (rest of TB.app tree omitted) otool -tV output for 30.0b1 (seems like no code in the executable): Thunderbird 30.0b1.app/Contents/Library/Spotlight/thunderbird.mdimporter/Contents/MacOS/thunderbird: (__TEXT,__text) section ------------------------------------------------------------------------ This is the current release (31.4.0) directly from my Applications folder. At this point the mdimporter executable is named "thunderbird": Thunderbird.app/ ├── Contents │ ├── CodeResources │ ├── Info.plist │ ├── Library │ │ └── Spotlight │ │ └── thunderbird.mdimporter │ │ └── Contents │ │ ├── Info.plist │ │ ├── MacOS │ │ │ └── thunderbird <----mdimporter executable │ │ └── Resources │ │ ├── English.lproj │ │ │ ├── InfoPlist.strings │ │ │ └── schema.strings │ │ └── schema.xml │ ├── MacOS │ │ ├── XUL │ │ ├── application.ini │ │ ├── blocklist.xml │ │ ├── crashreporter.app (rest of TB.app tree omitted) otool -tV showing the disassembled mdimporter for the current release, 31.4.0, shows nothing: Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/Contents/MacOS/thunderbird: (__TEXT,__text) section ------------------------------------------------------------------------ FYI, I think I looked at all of the release 31 versions and the mdimporter was lacking code in every one though it was still included and called "thunderbird". ------------------------------------------------------------------------ Here is 34.0b1. The mdimporter name is now named "thunderbird-mdimport" in this release, changed from just "thunderbird" at some point and still lacking object code: Thunderbird\ 34.0b1.app/ └── Contents ├── Info.plist ├── Library │   └── Spotlight │   └── thunderbird.mdimporter │   └── Contents │   ├── Info.plist │   ├── MacOS │   │   └── thunderbird-mdimport <----mdimporter executable │   ├── Resources │   │   ├── English.lproj │   │   │   ├── InfoPlist.strings │   │   │   └── schema.strings │   │   └── schema.xml │   └── _CodeSignature │   └── CodeResources ├── MacOS │   ├── XUL │   ├── crashreporter.app │   │   └── Contents (rest of TB.app tree omitted) otool -tV: MacOS/thunderbird-mdimport Thunderbird 34.0b1.app/Contents/Library/Spotlight/thunderbird.mdimporter/Contents/MacOS/thunderbird-mdimport: (__TEXT,__text) section (again, nothing) ------------------------------------------------------------------------ Here's 36.0b1: now the mdimporter structure is partially there but the executable has disappeared (and I didn't see it anywhere in the rest of the TB tree): Thunderbird\ 36.0b1.app/ └── Contents ├── Info.plist ├── Library │   └── Spotlight │   └── thunderbird.mdimporter │   └── Contents <-(should MacOS/(mdimporter executable) is now completely gone) │   ├── Info.plist │   └── Resources │   ├── English.lproj │   │   ├── InfoPlist.strings │   │   └── schema.strings │   └── schema.xml ├── MacOS │   ├── XUL │   ├── crashreporter.app │   │   └── Contents │   │   ├── Info.plist │   │   ├── MacOS │   │   │   └── crashreporter (rest of TB.app tree omitted) (There is no apparent mdimporter executable to run otool -tV on for TB 36.0b1) ------------------------------------------------------------------------ Now that I look at them in order I'm wondering if at some point the TB mdimporter name was changed to "thunderbird-mdimport" but when the build is constructed or updated perhaps there is a place where the name wasn't changed, remaining "thunderbird" (possibly containing no executable code) and so the final mdimporter (whatever it's supposed to be called) never gets the generated code copied into it? I think I saw a bugzilla entry where there was mention that something else couldn't be called "thunderbird" because the mdimporter had gotten that name; perhaps someone was attempting to "correct" the naming? I also think I saw somewhere in bugzilla, a suggestion that the mdimporter be removed from the testing for some reason; might that be why it isn't showing up in the betas and nightlies? I hope this helps some. Sorry I haven't managed to find time to run through the nightlies to see exactly when things went wrong. It seems to me, though, that the mdimporter hasn't been functioning since TB release 24 (and, I think, release 31 was the next real release since 24.
Flags: needinfo?(Nomis101)
(In reply to Zhora VandenBout from comment #26) > I think I saw a bugzilla entry where there was mention that something else > couldn't be called "thunderbird" because the mdimporter had gotten that > name; perhaps someone was attempting to "correct" the naming? I think you mean Bug 1045026.
Flags: needinfo?(Nomis101)
(In reply to Nomis101 from comment #27) > (In reply to Zhora VandenBout from comment #26) > > I think I saw a bugzilla entry where there was mention that something else > > couldn't be called "thunderbird" because the mdimporter had gotten that > > name; perhaps someone was attempting to "correct" the naming? > > I think you mean Bug 1045026. Yes, that's the one. I let TB automaticly update my installed TB (31.4.?) to 31.5.0 and the TB mdimporter (still named "thunderbird") now contains code works correctly for me. The original error for this problem that showed up in the console log is also gone. I think that means that the current bug (Bug 1011449) is now basically resolved (except maybe for any testing that needs done or anything changes required to propagate it to later versions and since I don't know the procedure I'm not doing anything of that sort myself). I see you opened Bug 1134867 about the missing mdimporter module in later versions but I'm mentioning it since it came up here and may interact with fixes to this bug. I'll add things about it there. Question: this bug blocks Bug 1008543 - (TB31found) Bugs found prior to 31 release with betas from TB30 and TB31 [meta] - which doesn't block anything else and hasn't changed since last August. Is it still useful now? Or was it just an abandoned at something useful that was was found ineffective or just dropped along the way? It might be a standard procedure and I apologize for not being more familiar with such things or if I'm asking in the wrong place. I was wondering if it would be good to close or change it since it makes the bugs it depends on look like they are actually blocking TB in some way but really those blocks accomplish nothing? Maybe its useful as a way to group the set of both completed and uncompleted bugs that affect betas 30 and 31, now released, but it seems more like something that confuses things at this point.
Zhora, could you check with the most recent nightly, which has Bug 1134867 fixed?
(In reply to Nomis101 from comment #29) > Zhora, could you check with the most recent nightly, which has Bug 1134867 > fixed? I'm still getting the hang of the organization of the various builds/versions/etc. so I'm including complete info about what I downloaded; so definitely make sure I checked the one you wanted me to . Downloaded nightly: thunderbird-39.0a1.en-US.mac.dmg Containing: Daily.app Version: 39.0a1 Location: http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2015-03-07-03-02-30-comm-central/thunderbird-39.0a1.en-US.mac.dmg The application has all of the expected files for the thunderbird mdimporter. The mdimporter is using name "thunderbird.mdimporter" that I believe was changed in release 36.?.? (but not totally sure of that number). Though all of the files now exist and the mdimporter still shows the same version number as earlier (1.0), "otool -tV" displays no usable code in the file. I haven't tested it out (since I keep messing up my working TB app when I do) I'm pretty sure that the problem of this bugzilla report is still happening (note following!); I'll actually install the nightly and check out the mdimporter later since anything I find with my 5:30am brain would need to be questioned. In double checking things while doing looking at the above I discovered that the mdimporter is still not working in 31.5 (though I had thought it was and said that earlier) and that when TB automatically updates one's working TB app there are no checks to see if the new version contains exactly the correct files that should be in the new release. After looking at why my auto updated release 31.5.0 version wasn't the same as the 31.5 version I manually downloaded I finally saw that mine contained an older mdimporter that I had grafted into the 31.4 release to get it to index files. For some reason my mdimporter wasn't replaced by the bad one in 31.5 though perhaps a correction was made which seems unlikely from a distribution point of view (but some dates are still confusing me so I can't be sure). Though the problem may have been caused by my changes to the app on my machine I think not having some checks of some sort (such as checksums) with perhaps the possibility to not write over the changes (should the user have made changes she wants to keep) could be considered a bug. Of course we don't have to be responsible for changes a user makes to an app that gets updated but if the changes caused the problem then the same issue would apply if the application bundle becomes corrupted, either accidentally or maliciously and at least the user should be informed that the resulting app is different than how it was created to be. (I'll file a bugzilla on that later.) Anyway, due to the update fluke, my report that the mdimporter was now working turns out to be wrong and why there is no code in the midimporter module still needs to be determined and fixed.
Symptoms reproduced with Thunderbird 31.6.0 on OS X 10.9.5. Also, for a short while I tried Earlybird 39.0a2 on Yosemite with a ZFS home directory. I didn't take a Console view of all messages but I did find that Spotlight could not find individual messages. In both cases, as far as I recall, a Spotlight search for part of a subject line found the .msf file for the mailbox (not the message). That match is categorised as 'Other'. If it's relevant: I use ExQuilla for Microsoft Exchange <https://exquilla.zendesk.com/home> 31.0.1136. Question ======== Has anyone reproduced this bug with Mountain Lion or less?
(In reply to Zhora VandenBout from comment #24) > /Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird. > mdimporter/Contents/MacOS/thunderbird: > (__TEXT,__text) section > ------------------------------------------ > > That's all…pretty much nothing! So it seems that something is going wrong in After some testing I blame Bug 944952 for this issue. If I reverse this changes I get a normal output of this build with otool. But currently I have no idea whats wrong and how to fix this...
Maybe this is the reason and it is needed? http://hg.mozilla.org/comm-central/rev/24c3a939f322#l3.33 I will test this...
My Yosemite console error message is similar, but not identical: 2015-08-28 10:49:34.983 AM mdworker[15093]: (Import.Error:867) BAD IMPORTER ~~~~~~~~~~~~~~~~~~ file:///Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/ Is this the same bug?
I get this on El Capitan on TB 38.3.0: Oct 19 14:25:13 jarmac mdworker[7998]: Cannot find function pointer MetadataImporterPluginFactory for factory 37401ADE-1058-42DB-BBE5-F2AAB9D7C13E in CFBundle/CFPlugIn 0x7f9bf530dc20 </Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter> (bundle, loaded) Oct 19 14:25:13 jarmac mdworker[7998]: (Import.Error:722) Could not create instance for plugIn 'file:///Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/' Oct 19 14:25:13 jarmac mdworker[7998]: (Import.Error:878) BAD IMPORTER ~~~~~~~~~~~~~~~~~~ file:///Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/
Same problem here on 10.9.5 (Mavericks) with TB 38.3.0 mdworker[13147]: Cannot find function pointer MetadataImporterPluginFactory for factory 37401ADE-1058-42DB-BBE5-F2AAB9D7C13E in CFBundle/CFPlugIn 0x7fdc12515e00 </Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter> (bundle, loaded) mdworker[13147]: (Error) Import: Could not create instance for plugIn 'file:///Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/' mdworker[13147]: (Error) Import: BAD IMPORTER ~~~~~~~~~~~~~~~~~~ file:///Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/
Confirming problem, TB 38.3.0 and El Capitan 10.11.1 --- console messages essentially identical to those found by Atlanx under Mavericks: mdworker[1039]: Cannot find function pointer MetadataImporterPluginFactory for factory 37401ADE-1058-42DB-BBE5-F2AAB9D7C13E in CFBundle/CFPlugIn 0x7fe6984260c0 </Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter> (bundle, loaded) mdworker[1039]: (Import.Error:722) Could not create instance for plugIn 'file:///Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/' mdworker[1039]: (Import.Error:878) BAD IMPORTER ~~~~~~~~~~~~~~~~~~ file:///Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/
This still doesn't work for TB 44.0beta and El Capitan 10.11.2. The key issue is this log message: mdworker[1039]: Cannot find function pointer MetadataImporterPluginFactory for factory 37401ADE-1058-42DB-BBE5-F2AAB9D7C13E in CFBundle/CFPlugIn 0x7fe6984260c0 </Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter> (bundle, loaded) That's indicating the Spotlight, when it goes to load Thunderbird importer plug in, can't locate the global symbol MetadataImporterPluginFactory because it isn't there. If you examine /Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/Contents/MacOS/thunderbird-mdimport with nm -gU, you see that there are no global symbols defined. If you look at other Spotlight plugs, all have at least one global symbol defined, the one corresponding to whatever the Info.plist file specifies as the function name. For Thunderbird, it's this: <key>CFPlugInFactories</key> <dict> <key>37401ADE-1058-42DB-BBE5-F2AAB9D7C13E</key> <string>MetadataImporterPluginFactory</string> </dict> Change the build options to keep the MetadataImporterPluginFactory symbol intact and you'll have a plugin that loads.
I'm getting the same problem, but this isn't just a symbol table problem, the thunderbird.mdimporter seems to be pretty empty - no entry points, no symbol table, basically a valid executable, but an empty one. It's only 34k in size. Here's the error from the console: 19/01/2016 18:42:15.739 mdworker[14604]: Cannot find function pointer MetadataImporterPluginFactory for factory 37401ADE-1058-42DB-BBE5-F2AAB9D7C13E in CFBundle/CFPlugIn 0x7fd991517ed0 </Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter> (bundle, loaded) Here's the ouput of otool -f Fat headers fat_magic 0xcafebabe nfat_arch 2 architecture 0 cputype 16777223 cpusubtype 3 capabilities 0x0 offset 4096 size 13584 align 2^12 (4096) architecture 1 cputype 7 cpusubtype 3 capabilities 0x0 offset 20480 size 13568 align 2^12 (4096) ... and the output of nm -a U dyld_stub_binder
(In reply to Saul Tannenbaum from comment #38) > Change the build options to keep the MetadataImporterPluginFactory symbol > intact and you'll have a plugin that loads. Do you think you can provide a patch with this suggestion?
I've recently begun seeing these messages in Console for TB 45.1.1. 6/30/16 4:53:21.296 AM mdworker[15104]: Cannot find function pointer MetadataImporterPluginFactory for factory 37401ADE-1058-42DB-BBE5-F2AAB9D7C13E in CFBundle/CFPlugIn 0x7ffb884111c0 </Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter> (bundle, loaded) 6/30/16 4:53:21.297 AM mdworker[15104]: (Import.Error:722) Could not create instance for plugIn 'file:///Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/' 6/30/16 4:53:21.297 AM mdworker[15104]: (Import.Error:878) BAD IMPORTER ~~~~~~~~~~~~~~~~~~ file:///Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/
I'm seeing it in TB 45.2. 7/13/16 3:53:31.949 AM mdworker[52146]: (Import.Error:878) BAD IMPORTER ~~~~~~~~~~~~~~~~~~ file:///Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/
The issue still exists on 10.9.5 (El Capitan) with TB 52.0.1 Apr 12 14:26:12 BeBox mdworker[1766]: Cannot find function pointer MetadataImporterPluginFactory for factory 37401ADE-1058-42DB-BBE5-F2AAB9D7C13E in CFBundle/CFPlugIn 0x7ffd03e10840 </Applications/Thunderbird.app/Contents/Library/Spotlightthunderbird.mdimporter> (bundle, loaded) Apr 12 14:26:12 BeBox mdworker[1766]: (Import.Error:722) Could not create instance for plugIn 'file:///Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/' Apr 12 14:26:12 BeBox mdworker[1766]: (Import.Error:878) BAD IMPORTER ~~~~~~~~~~~~~~~~~~ file:///Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter/ Also, it can be reproduce on 10.12.4 (Sierra) with TB 52.0.1.
Jcranmer, you seem to be the author of the suspect bug 944952, can you please look at this?
Flags: needinfo?(Pidgeot18)
Javi too perhaps
Blocks: tb-mac
Whiteboard: [regression:TB31]
I vote for reverting changes in bug 944952. Don't know what advantage is providing removing the use of Xcode for this part of the code. I was trying to backout those changes, but there were many merge conflicts and the building was failing. I have another priority right now in Calendar so cannot do anything else. However, if :jcranmer or whoever provides me a patch which both applies and compiles, then I will be glad to test it.
(In reply to :aceman from comment #44) > Jcranmer, you seem to be the author of the suspect bug 944952, can you > please look at this? I know almost nothing of OS X-specific build system details, particularly when it comes to this sort of code. The original patch was developed largely by begging the contents of the build system from some people, finding the relevant files, and using diffs until that portion of the build system saw no changes. (In reply to Javi Rueda from comment #46) > Don't know what advantage is providing removing the use of Xcode for this > part of the code. It means we're not reliant on an insane, fragile build system that probably blocks future automation improvements. (e.g., I'm quite sure it would have broken if we moved OS X to a cross-compile-from-Linux build environment). It probably also blocked the c-c/m-c merger work I was doing back then, although I don't recall the basic deatils.
Flags: needinfo?(Pidgeot18)
(In reply to Javi Rueda from comment #46) > However, if :jcranmer or whoever provides me a patch which both applies and > compiles, then I will be glad to test it. I tried very hard. But I don't get it to build. This attached patch applies, but it always fails with: ld: entry point (_main) undefined. for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) *** [thunderbird-mdimport] Error 1 make[3]: *** [mail/components/search/mdimporter/target] Error 2 make[3]: *** Waiting for unfinished jobs.... make[2]: *** [compile] Error 2 make[1]: *** [default] Error 2 make: *** [build] Error 2 I have no idea why this is. I tried a lot of different combinations, I every time get this linker error. If somebody can tell me why this fails, I can hopefully make a patch that also builds. Currently it just applies.
Assignee: nobody → Nomis101
Severity: normal → S3

Is this still a thing, and if so badly needed?

This issue still remains. At least I think it is an issue that needs to be resolved.

I'll confirm this is an issue.

As mentioned above, the thunderbird.mdimport binary is just invalid. otool -tV produces junk output (only a text section) and ng -gU lists no global symbols.

This is definitely a bug. I will try poking at it if I get a few minutes as it's clearly a build fail.

Assignee: Nomis101 → nobody
No longer blocks: tb-mac
Duplicate of this bug: 1106091

(In reply to Rob Lemley [:rjl] from comment #51)

I'll confirm this is an issue.

As mentioned above, the thunderbird.mdimport binary is just invalid. otool -tV produces junk output (only a text section) and ng -gU lists no global symbols.

This is definitely a bug. I will try poking at it if I get a few minutes as it's clearly a build fail.

Still actionable?

Flags: needinfo?(corey)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: