The assertion stacktrace doesn't seem that useful (at least to me): #0 assert_failed (file=0x4d7d71 "event-stream.c", line=1037, expr= 0x4d8ebc "tm") at emacs.c:3258 #1 0x004e1268 in pop_low_level_timeout (timeout_list=0x9971e0, time_ out=0x0) at event-stream.c:1037 #2 0x005b5c2a in check_what_happened () at signal.c:317 #3 0x00454ec5 in Ffuncall (nargs=1, args=0x2e4af54) at eval.c:3474 #4 0x00418907 in execute_optimized_program (program=0xa747c10 "À\t !«\006Â\t!ª\002\t\211\e­\004Ä\013!\035Æ\036\a\r¬\013ÈÉ ÊË\t\"\"\210ª=\212\rq\210ÌÍÎ\"\210\016\017«\"~\210\t¬ \004\r«\tÐ «\005Ñ \026\a\016\022¬\016ÓÔ\016\025ÖH!!®\ 002×\026\022)\016\aض¬\b\016\031Ú\r!!\210+ÛÜ !q\207", sta ck_depth=6, constants_data=0xa37eb10) at bytecode.c:746 #5 0x004181ce in funcall_compiled_function (fun=169383348, nargs=2 , args=0x2e4b0d4) at bytecode.c:518 #6 0x004552c7 in Ffuncall (nargs=3, args=0x2e4b0d0) at eval.c:3563 #7 0x00418907 in execute_optimized_program (program=0xa746410 "À\t !\032\013®\004ÄÅ!\036\006Ç \210\nÈH\036\t\nÊH®\016\nËH­ \tÌ\nÍH\016\016\"£\036\017\016\020®\036\n\211\036\021ÒH«\02 1\016\021ÓHÔÕÖ\016\021ÒHÔ#Qª\005\016\021ÓH)\036\027\nØ H\036\031Ú\036\e\016\017Ük«\004Ý\026\017\016\027Ük«\004Þ\ 026\027\016\t¬\bßà\t\"\202½", stack_depth=7, constants_data= 0xa288410) at bytecode.c:746 #8 0x004181ce in funcall_compiled_function (fun=172328540, nargs=1 , args=0x2e4b254) at bytecode.c:518 #9 0x004552c7 in Ffuncall (nargs=2, args=0x2e4b250) at eval.c:3563 Setting a breakpoint in alarm_signal(), it appears that some cygwin (?) code is raising SIGALRM. Here are three partial stacktraces from different runs (all of which resulted in the assertion): #0 alarm_signal (signo) at signal.c:167 #1 0x6100e5df in ?numDevices＠OSinterface＠＠2HA () #2 0x005a9256 in re_match_2_internal (bufp 96924, string1