Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash in malloc while allocating logger name. #6

Open
timboudreau opened this issue Aug 26, 2024 · 2 comments · May be fixed by #7
Open

Crash in malloc while allocating logger name. #6

timboudreau opened this issue Aug 26, 2024 · 2 comments · May be fixed by #7

Comments

@timboudreau
Copy link

I'm attempting to use os_log in some AudioUnit system extensions. Intermittently, logging initialization will crash hard while attemping to allocate the c-string for the logger name (!).

I'm not sure if there are some restrictions on allocating memory during initialization of a system extension, but it seems pretty odd (any chance the C-string you're translating the passed logger name into could accidentally be set to an extremely large size?).

For that matter, since in my case, since it's perfectly possible for me to allocate the logger name as a const c-string, it would be nice to be able to pass in c-string and avoid the allocation entirely - though while that might bypass this issue, it seems like something is probably genuinely wrong here.

0   libsystem_kernel.dylib        	    0x7ff802845196 __pthread_kill + 10
1   libsystem_pthread.dylib       	    0x7ff80287cee6 pthread_kill + 263
2   libsystem_c.dylib             	    0x7ff8027a3b45 abort + 123
3   libsystem_malloc.dylib        	    0x7ff8026ba752 malloc_vreport + 888
4   libsystem_malloc.dylib        	    0x7ff8026cfa08 malloc_zone_error + 183
5   libsystem_malloc.dylib        	    0x7ff8026cf70e _tiny_check_and_zero_inline_meta_from_freelist + 211
6   libsystem_malloc.dylib        	    0x7ff8026affbc tiny_malloc_from_free_list + 1507
7   libsystem_malloc.dylib        	    0x7ff8026af3a2 tiny_malloc_should_clear + 358
8   libsystem_malloc.dylib        	    0x7ff8026ae00a szone_malloc_should_clear + 66
9   libsystem_malloc.dylib        	    0x7ff8026b137e szone_realloc + 808
10  libsystem_malloc.dylib        	    0x7ff8026b02a0 malloc_zone_realloc + 69
11  libsystem_malloc.dylib        	    0x7ff8026aede6 realloc + 309
12  ZenCurvifyExtension           	       0x10b9341fb alloc::alloc::realloc::h0142492e4adaf69e + 13 (alloc.rs:138) [inlined]
13  ZenCurvifyExtension           	       0x10b9341fb alloc::alloc::Global::grow_impl::h127daf85a8f8363b + 13 (alloc.rs:215) [inlined]
14  ZenCurvifyExtension           	       0x10b9341fb _$LT$alloc..alloc..Global$u20$as$u20$core..alloc..Allocator$GT$::grow::h466d8ab34cd17903 + 13 (alloc.rs:268) [inlined]
15  ZenCurvifyExtension           	       0x10b9341fb alloc::raw_vec::finish_grow::h3603a421b9d173cf + 59 (raw_vec.rs:570)
16  ZenCurvifyExtension           	       0x10b934fd2 alloc::raw_vec::RawVec$LT$T$C$A$GT$::grow_exact::h944fcbaad794ca9a + 68 (raw_vec.rs:505) [inlined]
17  ZenCurvifyExtension           	       0x10b934fd2 alloc::raw_vec::RawVec$LT$T$C$A$GT$::try_reserve_exact::h2e3f279e87d6b3cf + 73 (raw_vec.rs:412) [inlined]
18  ZenCurvifyExtension           	       0x10b934fd2 alloc::raw_vec::RawVec$LT$T$C$A$GT$::reserve_exact::h143f1a7c0c6edb4b + 73 (raw_vec.rs:400) [inlined]
19  ZenCurvifyExtension           	       0x10b934fd2 alloc::vec::Vec$LT$T$C$A$GT$::reserve_exact::hd77cb16b787b71c7 + 80 (mod.rs:1002) [inlined]
20  ZenCurvifyExtension           	       0x10b934fd2 alloc::ffi::c_str::CString::_from_vec_unchecked::h9c6e085f898e9e05 + 98 (c_str.rs:349)
21  ZenCurvifyExtension           	       0x10b81ca57 oslog::OsLog::new::he3ca41c37c771796 + 247
22  ZenCurvifyExtension           	       0x10b81c0dd _$LT$oslog..logger..OsLogger$u20$as$u20$log..Log$GT$::log::h079db1b32d6bcb2c + 205
23  ZenCurvifyExtension           	       0x10b8bf91b log::__private_api::log_impl::ha9cf7b229ffe2ebe + 155
24  ZenCurvifyExtension           	       0x10b7e82ae create_eight_band_curvifier + 974
25  ZenCurvifyExtension           	       0x10b710fc9 ZenCurvifyExtensionDSPKernel::initialize(int, int, double) + 2121 (ZenCurvifyExtensionDSPKernel.hpp:179)
26  ZenCurvifyExtension           	       0x10b70ee42 ZenCurvifyExtensionDSPKernel::setParameter(unsigned long long, float) + 914 (ZenCurvifyExtensionDSPKernel.hpp:419)
27  ZenCurvifyExtension           	       0x10b70f197 __55-[ZenCurvifyExtensionAudioUnit setupParameterCallbacks]_block_invoke + 119 (ZenCurvifyExtensionAudioUnit.mm:197)
28  AudioToolboxCore              	    0x7ff8044cd54d __59-[AUParameter setValue:extOriginator:atHostTime:eventType:]_block_invoke + 239
29  libdispatch.dylib             	    0x7ff8026dc033 _dispatch_client_callout + 8
@timboudreau
Copy link
Author

Hmm, digging into the code a bit, I'm wondering if this is the problem:

        let subsystem = to_cstr(subsystem);
        let category = to_cstr(category);

        let inner = unsafe { os_log_create(subsystem.as_ptr(), category.as_ptr()) };

Depending on what os_log_create actually does - which could be asynchronous - it seems entirely possible that the pointers to the CStrings could be accessed after they have been dropped.

I will try giving OsLog ownership of the CStrings and see if that eliminates the crashes. If it does, then that is probable the correct diagnosis.

timboudreau added a commit to timboudreau/oslog that referenced this issue Aug 26, 2024

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
…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.
@timboudreau
Copy link
Author

That does indeed eliminate the crashes - I had one project which would crash in the way described very frequently, which now runs without any problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants
@timboudreau and others