GSlice slab_stack corruption
Submitted by John Ralls
Link to original bug (#724590)
Description
This is rather an odd corner case: When building on OS X 10.9 (Mavericks) with Xcode3's gcc-4.2 (that's the real gcc, not llvm-gcc), I encountered a segfault: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0xa47fe801 0x00400c4f in slab_allocator_alloc_chunk (chunk_size=56) at gslice.c:1312 1312 if (!allocator->slab_stack[ix] || !allocator->slab_stack[ix]->chunks)
#0 0x00400c4f in slab_allocator_alloc_chunk (chunk_size=56) at gslice.c:1312
#1 0x003ffb0e in magazine_cache_pop_magazine (ix=6, countp=0xa4f43c) at gslice.c:732
#2 0x003fff0f in thread_memory_magazine1_reload (tmem=0xa4f400, ix=6) at gslice.c:807
#3 0x0040001a in g_slice_alloc (mem_size=56) at gslice.c:1005
which I eventually traced to gcc interpreting this line: g_mutex_lock_a (&allocator->magazine_mutex, &allocator->contention_counters[ix]); (which is line gslice.c:719, in magazine_cache_pop_magazine) in an unfortunate way. In particular, it's the &allocator->contention_counters[ix] statement: Instead of dereferencing allocator->contention_counters, finding the ix offset, and returning the address thereof, it's getting the address of allocator->contention_counters and offsetting that by ix; when ix is 6, that happens to be allocator->slab_stack. Since g_mutex_lock_a does predictable things with a counter, having that counter actually be a pointer to somewhere in the heap has predictable results.
Version: 2.39.x