[racket-dev] stypes.h + 3M woes
I overlooked the crucial line of the second stack trace. The
fixup_table and mark_table fields of the NewGC each allocate space for
512 function pointers, indexed by type tag (I think). So, when I tried
to create a tag with 512 as it's value, I ended up writing outside of
the array bounds. Maybe those arrays should have length
_scheme_last_type_?
-Jon
On Sun, May 5, 2013 at 8:16 PM, Jon Zeppieri <zeppieri at gmail.com> wrote:
> When I try to make a hole in the enumeration defined in stypes.h (by
> explicitly setting the value of a member), I get a segfault in the 3m
> build, though not the cgc one.
>
> Depending on where I place the hole, I've seen different stack traces.
> If I place the new tag before the _rt_ tags, then I get:
>
> #0 0x00007fff886d9db0 in bzero$VARIANT$sse42 ()
> #1 0x000000010030d5ea in malloc_pages () at vm_osx.c:185
> #2 0x0000000100314106 in allocate_big (request_size_bytes=32807,
> type=0) at newgc.c:974
> #3 0x0000000100314e08 in GC_malloc_weak_array (size_in_bytes=16384,
> replace_val=0x0) at newgc.c:1463
>
> If I place it after (which is where I want to place it), I get:
>
> #0 0x0000000000000000 in ?? ()
> #1 0x0000000100310e9f in repair_heap [inlined] () at
> /Users/jaz/src/racket/src/racket/gc2/newgc.c:4171
> #2 0x0000000100310e9f in garbage_collect (gc=0x7fff5fbf7c00,
> force_full=5339440, switching_master=1606384640, lmi=0x7fff5fbf7c00)
> at newgc.c:4753
> #3 0x000000010031487a in scheme_get_thread_local_variables [inlined]
> () at /Users/jaz/src/racket/src/racket/include/schthread.h:1283
> #4 0x000000010031487a in allocate_slowpath [inlined] () at
> /Users/jaz/src/racket/src/racket/gc2/newgc.c:1289
> #5 0x000000010031487a in allocate (request_size=4300306736,
> type=1606384720) at newgc.c:1348
> #6 0x00000001002ad122 in scheme_make_stx_w_offset (val=0x102a00300,
> src=0x1003b10b8, props=0x1003b10b8, line=-1, col=-1, pos=1553,
> span=140734799772896) at syntax.c:577
>
>
> I noticed that gc2.h's description of GC_init_type_tags() mentions
> that the count parameter will always be less than 256, and I wondered
> if that could be causing a problem, because I was trying to create a
> type tag with a value of 512. However, the comment appears to be
> wrong, because stypes.h currently defines tags up to 259
> (_scheme_last_type_ == 260), and it looks like _scheme_last_type_ is
> used as the count param in salloc.c.
>
> Is there some other limit (aside from the limit of Scheme_Type itself,
> which is defined as a short, so that's at least 16 bits)? Or is there
> an assumption that the enumeration is dense? Or something else?
>
> -Jon