Thanks for quick response! Here is the compiler version: gcc version 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC)
Furthermore, although I was not able to re-produce the issue with codes caused the problem, I generated some core files of normal and abnormal masters and workers. Here is a glimpse of `ruby_current_vm.objspace.global_list` compared with normal and abnormal masters with same codes. // normal (gdb) $72 = (struct gc_list *) 0x7feb65625680 $73 = 5 --------------------------------------------- (gdb) $74 = (struct gc_list *) 0x7feb6424e2a0 $75 = 7 # T_ARRAY --------------------------------------------- (gdb) $76 = (struct gc_list *) 0x7feb63a8c120 $77 = 8 // abnormal (gdb) $72 = (struct gc_list *) 0x7f7547651cc0 $73 = 5 --------------------------------------------- (gdb) $74 = (struct gc_list *) 0x7f7546939760 $75 = 27 # T_NODE --------------------------------------------- (gdb) $76 = (struct gc_list *) 0x7f7546583e70 $77 = 8 Note that I have checked the whole global_list, the order looks the same. Hence, I am quite sure that the T_NODE in the abnormal one comes from the same module as the T_ARRAY in the normal one. And from contents in T_ARRAY, the module should be unicorn_http.
