Post not yet marked as solved
Thanks, Quinn!
For debugging purpose and exchanging of logs/dumps its sometimes easier to directly write to log files. Which are suitable locations to write from CoreAudio and CoreMIDI? (We see that permissions do change between the MacOS versions.)
Thanks, hagen.
Post not yet marked as solved
Thanks again,yep you were right. I don't know why I didn't see them.Unfortunately restarting either/both of the demons does not reset the logging system in a way so it cures the garbled output...BTW. Its not only garbled, it seems also that the logging system accesses the log string at the wrong memory position. Here it seems that it reads the format string at a position skipping the string start which contained %s (to display the denoted string parameter)...<decode: mismatch for [%x] got [STRING sz:59]>] {I am bit clueless right now, since logging is a very valueable and neccesary way of developing/debuggin kernel code. Often its not even possible/manageable to connect a debugger...What can I do to progress here?Thanks & cheers,Hagen
Post not yet marked as solved
@mhorgan, did you find a way yet to get precedence over AppleMIDIUSBDriver.plugin and possibly com.apple.driver.AppleUSBAudio?@Apple: wouldn't that be easy to answer: just a yes or a no. And if you don't care, just a "we don't care" so we know at least what to expect!Thanks,Hagen.
Post not yet marked as solved
Thanks Quinn,that seems to be true for Catalina (even for the man page - great, I am impressed...!!!), and there its named properly,but not for Mojave (and unfortunately I am still bound to Mojave for some reasons like svn support, I still need Xcode 9 - while running current Xcode in parallel).What would be the name of the unified logging process in Mojave?Thanks & cheers,Hagen.
Post not yet marked as solved
Since there is no progress here, is it possible to restart the logging process? Whats the name of the process?
Post not yet marked as solved
Hi Quinn,I probably don't get you quite right here.Amongst the audio plugin development community there are ongoing discussionsi.e.https://forum.juce.com/t/macos-plugins-in-sandboxed-daw/36999https://forum.juce.com/t/garageband-x-sandboxing/11739and others, which indicate that the entitlements can be successfully set for individual bundles (wether .vst/ .vst3/ .component/ or .aax); this also is in accordance to our own findings - except for IOHIDDevice access, which can't be accessed; even when the sandbox is excepted by setting the plugins com.apple.security.device.usb entitlement.Now, my question is: should this work (i.e. is there something wrong on our side or is there a bug in Apples sandbox)? or is this not suppose to work and how can we achieve in this case IOHiddevice communication from within a sandboxed plugin? So far to me Apples sandboxing does not look being entirely thought thru (what is with other hardware/kext/IOKit access?) but I strongly hope I am wrong here.Having said that, an entire product line is depending on being able to communicate from our audio plugins with our controlling hardware.Or, maybe we are not using the correct (sandbox except-able) API? I see there are more HID related frameworks (i.e. HIDDriverKit.framework vs. IOKit.framework), where we are currently using the later...?!On the other hand, according to the sandbox profiles located at/System/Library/Sandbox/Profiles/application.sbthere seem to be a separate (but nowhere mentioned) "com.apple.security.device.hid" entitlement. Is this the one to use? Can these profiles be "trusted" in any way? Where is the actual documentation?I am blindly tumbling around, waisting my time with simple question... Just because Apples seems to be too ignorrant to provide adequate documentation. Those "maybe this or that" are so tiring and far away from being professional and in the end the cause of bad or wrong development decisions.Thanks & cheers,Hagen.
Post not yet marked as solved
Thanks Quinn, but I think you are wrong here:https://developer.apple.com/library/archive/technotes/tn2247is indicating the possibilty to control sandbox exceptions.Thanks & cheers,Hagen.
Post not yet marked as solved
Yes, there are various kexts driving different hardware. For test purpose I also have software-only kexts. If it matters I could check the software-only kext for that behaviour.Thanks,Hagen.
Post not yet marked as solved
Thanks,yes the UUID changes.Cheers,Hagen.
Post not yet marked as solved
Thanks, Quinn,Apple bugreporter problem ID is 43176244 (as mentioned above).Cheers,Hagen.
Post not yet marked as solved
Thanks, opening an ADC incident was my first action. This resulted in requiring me opening a bug report: the place were eventually all issues get safely burried.
Post not yet marked as solved
Issue persists up to today. Bug has been reported.To recap:The output of a kext using the unified logging via console or terminal is garbled after kextloading a rebuilt kext if another version was loaded before (macOS 10.12/10.13).Steps to Reproduce:build a kext with logging. kextload. rebuild it with slightly changed source. kextunload/kextload.Anyone cares?
