[racket-dev] stypes.h + 3M woes

From: Jon Zeppieri (zeppieri at gmail.com)
Date: Sun May 5 20:16:46 EDT 2013

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
#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
#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?


Posted on the dev mailing list.