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