[racket] DrRacket 6.1.1 stuck in a gc loop on Windows7x64

From: Ben Lerner (blerner at ccs.neu.edu)
Date: Tue Feb 24 23:06:22 EST 2015

I ran into an unfortunate situation last night with DrRacket, where I 
was editing a single scribble file, and DrRacket basically locked up in 
a gc loop (the recycle icon was flashing, syntax highlighting was 
glacially slow, and the entire UI was mostly frozen.)  There were two 
threads which seem to be stuck looping (and consuming 36+% of my CPU).  
The two stack traces were, according to Process Explorer:

Stack 1 (25% of CPU, aka one entire processor out of four)
USP10.dll+0x8580
libracket3m_9xtjc8.dll!GC_mark+0x1ab
libracket3m_9xtjc8.dll!GC_mark_variable_stack+0x8d0
libracket3m_9xtjc8.dll!GC_mark_variable_stack+0xb0b
libracket3m_9xtjc8.dll!GC_construct_child_gc+0x5a0
libracket3m_9xtjc8.dll!GC_free_all+0x318
libracket3m_9xtjc8.dll!GC_check_master_gc_request+0xc2
libracket3m_9xtjc8.dll!scheme_thread_block+0x630
libracket3m_9xtjc8.dll!scheme_block_until+0x225
libracket3m_9xtjc8.dll!scheme_kill_thread+0x8b1
libracket3m_9xtjc8.dll!scheme_kill_thread+0xb28
libracket3m_9xtjc8.dll!scheme_apply_known_prim_closure_multi+0x210
libracket3m_9xtjc8.dll!scheme_hash_set_atomic+0x3db0b

Stack 2 (11% CPU, aka half of one processor)
USP10.dll+0x8580
libracket3m_9xtjc8.dll!GC_retract_only_mark_stack_entry+0x63a
libracket3m_9xtjc8.dll!GC_mark+0x151
libracket3m_9xtjc8.dll!GC_mark_variable_stack+0x8d0
libracket3m_9xtjc8.dll!GC_mark_variable_stack+0xb0b
libracket3m_9xtjc8.dll!GC_construct_child_gc+0x5a0
libracket3m_9xtjc8.dll!GC_free_all+0x318
libracket3m_9xtjc8.dll!GC_make_jit_nursery_page+0x20b
libracket3m_9xtjc8.dll!GC_make_jit_nursery_page+0x2ff
libracket3m_9xtjc8.dll!scheme_break_thread+0xed8
libracket3m_9xtjc8.dll!scheme_kill_thread+0x743
libracket3m_9xtjc8.dll!scheme_sync+0x22
libracket3m_9xtjc8.dll!scheme_make_modidx+0x188f
libracket3m_9xtjc8.dll!scheme_module_is_declared+0xeb7
libracket3m_9xtjc8.dll!scheme_namespace_require+0x7e48
libracket3m_9xtjc8.dll!scheme_dynamic_require+0xbd
libracket3m_9xtjc8.dll!scheme_read_byte_string+0x9b4d
libracket3m_9xtjc8.dll!scheme_read_byte_string+0xa572
libracket3m_9xtjc8.dll!scheme_read_byte_string+0x1069a
libracket3m_9xtjc8.dll!scheme_read_byte_string+0x15df9
libracket3m_9xtjc8.dll!scheme_make_rational+0x29f9
libracket3m_9xtjc8.dll!scheme_get_seconds+0x2515
libracket3m_9xtjc8.dll!scheme_make_rational+0x2c27
libracket3m_9xtjc8.dll!scheme_call_enable_break+0x265c
libracket3m_9xtjc8.dll!scheme_dynamic_wind+0x3b6
libracket3m_9xtjc8.dll!scheme_call_enable_break+0x33ed


I managed to save my work and DrRacket did eventually close cleanly (I 
didn't have to force quit it).  I don't have the instance still running, 
since I needed a running DrRacket (and a not-frozen computer).  
Hopefully this stack info will be of sufficient use to someone trying to 
debug it.  A bit of searching reveals that "USP10.dll 0x8580" is 
probably a red herring, and running Process Explorer with administrator 
rights suggests that the USP10.dll line should really be a bunch of 
calls into ntoskrnl.exe, culminating in ntoskrnl.exe!memset+0x61a.

Ben

Posted on the users mailing list.