http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57970
Bug ID: 57970 Summary: segfault in sched-deps.c Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: colanderman at gmail dot com Created attachment 30546 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30546&action=edit Patch Symptom: Segfault in sched-deps.c when compiling a large auto-generated C file: ==3363== Invalid read of size 8 ==3363== at 0x95A41D: sched_analyze_1 (sched-deps.c:2479) ==3363== by 0x95D182: sched_analyze_insn (sched-deps.c:2859) ==3363== by 0x95E636: deps_analyze_insn (sched-deps.c:3505) ==3363== by 0x95E7F1: sched_analyze (sched-deps.c:3653) ==3363== by 0x6EC4F8: sched_rgn_compute_dependencies (sched-rgn.c:2702) ==3363== by 0x6EF582: schedule_insns (sched-rgn.c:2915) ==3363== by 0x89E237: tilegx_reorg (tilegx.c:4710) ==3363== by 0x6E0699: rest_of_handle_machine_reorg (reorg.c:4183) ==3363== by 0x69F5BF: execute_one_pass (passes.c:2084) ==3363== by 0x69FA30: execute_pass_list (passes.c:2139) ==3363== by 0x69FA44: execute_pass_list (passes.c:2140) ==3363== by 0x69FA44: execute_pass_list (passes.c:2140) ==3363== Address 0x8 is not stack'd, malloc'd or (recently) free'd Cause: deps->pending_read_insns and deps->pending_read_mems are getting out of sync. (Hence the NULL pointer access at sched-deps.c:2479.) Fix: The conditions "!deps->readonly" under which deps->pending_read_mems is freed in flush_pending_lists() should be changed to "!deps->readonly && !DEBUG_INSN_P (insn)" to match the condition "deps->readonly || DEBUG_INSN_P (insn)" under which deps->pending_read_insns is not freed in add_dependence_list_and_free(). Patch attached. Unfortunately I cannot provide a test case, as I have only been able to reproduce the crash with a very large (auto-generated) proprietary C file. The bug seems to exist in the source code of at least 4.6.3 as well, though I have not been able to trigger it therein.