Retain c-strings, pointers to which are used by the OS's logger subsystem #7
Conversation
…ers to the OS's logging subsystem, which may attempt to use them after they have been dropped. The fix simply adds the CStrings as fields to the logger instance, so they are guaraneteed to be retained for the lifetime of the logger.
|
Hello? |
|
I'll note this patch, while making the problem dramatically less frequent, does not entirely eliminate cases where logged strings are dropped before the system logger tries to log them. I'm not sure what exactly is going on but my suspicion is that logging from real-time audio rendering threads gets special treatment from the Mac OS logging subsystem and may be done asynchronously. Obviously one shouldn't do much logging from realtime audio threads, or at least one should not do a lot of that, but it probably shouldn't take out the host application when it fails either. I can't reproduce it in isolation, but it can be reproduced sporadically when running one of my audio unit plugins built along these lines is hosted in Logic Pro. At this point I'm simply disabling use of this crate, but with some runtime cost it ought to be fixable if there is any way to get a reliable signal back from the logging subsystem for when it is done with a string, so it can be retained until that point. |
Fixes #6 - CStrings used in constructor are passed as pointers to the OS's logging subsystem, which may (and evidently does) attempt to use them after they have been dropped.
The fix simply adds the CStrings as fields to the logger instance, so they are guaranteed to be retained for the lifetime of the logger.