https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115386
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to David Binderman from comment #7) > (In reply to Richard Biener from comment #6) > > Are you using a compiler with release checking? > > No, with asan & ubsan. > > I tried running cc1 under gdb and got this backtrace: > > #0 0x0000000000b54615 in gt_ggc_mx_rtx_def (x_p=0x7fffe939bd00) > at gtype-desc.cc:323 > #1 0x0000000000b54829 in gt_ggc_mx_rtx_def (x_p=<optimized out>) > at gtype-desc.cc:940 > #2 0x0000000000b55405 in gt_ggc_mx_rtx_def (x_p=<optimized out>) > at gtype-desc.cc:717 > #3 0x0000000000b55405 in gt_ggc_mx_rtx_def (x_p=<optimized out>) > at gtype-desc.cc:717 > #4 0x0000000000b55405 in gt_ggc_mx_rtx_def (x_p=<optimized out>) > at gtype-desc.cc:717 > #5 0x0000000000b55405 in gt_ggc_mx_rtx_def (x_p=<optimized out>) > at gtype-desc.cc:717 > > That continues on for a depth of more than 1000 frames. Yes, the garbage collecting marking can be deeply recursive. I guess asan/ubsan cause the marker functions to consume more stack. The issue can likely be reproduced even w/o asan/ubsan by lowering the stack size though I'm not sure how much the frame size of gt_ggc_mx_rtx_def explodes with asan/ubsan (or other functions in gtype-desc.cc). It might bake sense to exempt gtype-desc.cc from asan/ubsan instrumentation. Lowering the stack size to 1MB down from 8MB still doesn't make it reproduce without UBSAN/ASAN ...
