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

Based on your description and the stack trace, I think this is probably
a bug that I fixed in November (after the v6.1.1 release):

 https://github.com/plt/racket/commit/50a8863169

Thanks for the report! 

At Tue, 24 Feb 2015 23:06:22 -0500, Ben Lerner wrote:
> 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
> ____________________
>   Racket Users list:
>   http://lists.racket-lang.org/users