* [Bug lto/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
2021-03-07 10:35 [Bug lto/99447] New: [11 Regression] ICE (segfault) in lookup_page_table_entry doko at debian dot org
@ 2021-03-07 10:41 ` doko at debian dot org
2021-03-07 11:17 ` pinskia at gcc dot gnu.org
` (27 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: doko at debian dot org @ 2021-03-07 10:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
--- Comment #1 from Matthias Klose <doko at debian dot org> ---
object files at
https://people.debian.org/~doko/tmp/guymager-tst.tar.xz
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug lto/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
2021-03-07 10:35 [Bug lto/99447] New: [11 Regression] ICE (segfault) in lookup_page_table_entry doko at debian dot org
2021-03-07 10:41 ` [Bug lto/99447] " doko at debian dot org
@ 2021-03-07 11:17 ` pinskia at gcc dot gnu.org
2021-03-08 8:46 ` marxin at gcc dot gnu.org
` (26 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-03-07 11:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Looks like a stack overflow while doing gc. To me die_struct GTY could use a
recursive note added to it. That is just by looking at the backtrace.
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug lto/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
2021-03-07 10:35 [Bug lto/99447] New: [11 Regression] ICE (segfault) in lookup_page_table_entry doko at debian dot org
2021-03-07 10:41 ` [Bug lto/99447] " doko at debian dot org
2021-03-07 11:17 ` pinskia at gcc dot gnu.org
@ 2021-03-08 8:46 ` marxin at gcc dot gnu.org
2021-03-08 9:01 ` rguenth at gcc dot gnu.org
` (25 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-03-08 8:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2021-03-08
Status|UNCONFIRMED |WAITING
Ever confirmed|0 |1
--- Comment #3 from Martin Liška <marxin at gcc dot gnu.org> ---
Please reduce that, similarly to what I wrote to PR99448.
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug lto/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
2021-03-07 10:35 [Bug lto/99447] New: [11 Regression] ICE (segfault) in lookup_page_table_entry doko at debian dot org
` (2 preceding siblings ...)
2021-03-08 8:46 ` marxin at gcc dot gnu.org
@ 2021-03-08 9:01 ` rguenth at gcc dot gnu.org
2021-03-08 10:57 ` doko at debian dot org
` (24 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-03-08 9:01 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |11.0
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
I also wonder when the GC was triggered, thus whether it's another case of a
live stmt / SSA name where we now forcefully free the CFG.
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug lto/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
2021-03-07 10:35 [Bug lto/99447] New: [11 Regression] ICE (segfault) in lookup_page_table_entry doko at debian dot org
` (3 preceding siblings ...)
2021-03-08 9:01 ` rguenth at gcc dot gnu.org
@ 2021-03-08 10:57 ` doko at debian dot org
2021-03-17 12:18 ` rguenth at gcc dot gnu.org
` (23 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: doko at debian dot org @ 2021-03-08 10:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
--- Comment #5 from Matthias Klose <doko at debian dot org> ---
I'm able to reduce the amount of object files involved in this ICE. But then
trying to rebuild the package with -save-temps makes the ICE disappear.
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug lto/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
2021-03-07 10:35 [Bug lto/99447] New: [11 Regression] ICE (segfault) in lookup_page_table_entry doko at debian dot org
` (4 preceding siblings ...)
2021-03-08 10:57 ` doko at debian dot org
@ 2021-03-17 12:18 ` rguenth at gcc dot gnu.org
2021-03-17 12:20 ` rguenth at gcc dot gnu.org
` (22 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-03-17 12:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hubicka at gcc dot gnu.org
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
More specifically, likely caused by g:ae99b315ba5b9e1ccc221b3c45de323cbc574400
which did
diff --git a/gcc/cfg.c b/gcc/cfg.c
index 529b6ed2105..e8bd1456c9f 100644
--- a/gcc/cfg.c
+++ b/gcc/cfg.c
@@ -102,8 +102,7 @@ free_block (basic_block bb)
bb->succs = NULL;
vec_free (bb->preds);
bb->preds = NULL;
- /* Do not free BB itself yet since we leak pointers to dead statements
- that points to dead basic blocks. */
+ ggc_free (bb);
}
/* Free the memory associated with the CFG in FN. */
and the backtrace of the crash points at some RTX tree (if gtype-desc from
trunk still matches, it's likely SYMBOL_REF_DECL) refers to a GIMPLE stmt
via the callgraph edge ->call_stmt which refers to the CFG BB it is contained
in.
unfortunately it's not visible what pass/phase this segfault occurs in
(might be WPA function materialization or ltrans compilation).
That said, the ggc_free above looks like a bad idea until we can sort out
these issue. So - should we simply revert the change again?
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug lto/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
2021-03-07 10:35 [Bug lto/99447] New: [11 Regression] ICE (segfault) in lookup_page_table_entry doko at debian dot org
` (5 preceding siblings ...)
2021-03-17 12:18 ` rguenth at gcc dot gnu.org
@ 2021-03-17 12:20 ` rguenth at gcc dot gnu.org
2021-03-17 12:33 ` rguenth at gcc dot gnu.org
` (21 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-03-17 12:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Matthias Klose from comment #5)
> I'm able to reduce the amount of object files involved in this ICE. But then
> trying to rebuild the package with -save-temps makes the ICE disappear.
I guess always-collect might ease triggering it (--enable-checking=yes,gcac).
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug lto/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
2021-03-07 10:35 [Bug lto/99447] New: [11 Regression] ICE (segfault) in lookup_page_table_entry doko at debian dot org
` (6 preceding siblings ...)
2021-03-17 12:20 ` rguenth at gcc dot gnu.org
@ 2021-03-17 12:33 ` rguenth at gcc dot gnu.org
2021-03-17 12:38 ` rguenth at gcc dot gnu.org
` (20 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-03-17 12:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #6)
> More specifically, likely caused by
> g:ae99b315ba5b9e1ccc221b3c45de323cbc574400 which did
>
> diff --git a/gcc/cfg.c b/gcc/cfg.c
> index 529b6ed2105..e8bd1456c9f 100644
> --- a/gcc/cfg.c
> +++ b/gcc/cfg.c
> @@ -102,8 +102,7 @@ free_block (basic_block bb)
> bb->succs = NULL;
> vec_free (bb->preds);
> bb->preds = NULL;
> - /* Do not free BB itself yet since we leak pointers to dead statements
> - that points to dead basic blocks. */
> + ggc_free (bb);
> }
>
> /* Free the memory associated with the CFG in FN. */
>
> and the backtrace of the crash points at some RTX tree (if gtype-desc from
> trunk still matches, it's likely SYMBOL_REF_DECL) refers to a GIMPLE stmt
> via the callgraph edge ->call_stmt which refers to the CFG BB it is
> contained in.
>
> unfortunately it's not visible what pass/phase this segfault occurs in
> (might be WPA function materialization or ltrans compilation).
>
> That said, the ggc_free above looks like a bad idea until we can sort out
> these issue. So - should we simply revert the change again?
Note we can't leave cgraph & edge reclaim to GC when we free a function
and at the same time forcefully ggc_free things pointed to (but ultimatively
dead). That's in principle true for the gimple stmts themselves as well.
It looks like release_function_body simply leaves stmts dangling, it doesn't
remove them from blocks (clearing ->bb). We've not seen ICEs from that
for unknown reasons.
I'm not sure it's worth all the trouble?
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug lto/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
2021-03-07 10:35 [Bug lto/99447] New: [11 Regression] ICE (segfault) in lookup_page_table_entry doko at debian dot org
` (7 preceding siblings ...)
2021-03-17 12:33 ` rguenth at gcc dot gnu.org
@ 2021-03-17 12:38 ` rguenth at gcc dot gnu.org
2021-03-17 12:39 ` rguenth at gcc dot gnu.org
` (19 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-03-17 12:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
For the ICE in this bug it might be enough to, in cgraph_node::release_body,
walk callees and zap ->call_stmt on the cgraph edges. But the more general
issue remains - GC will still try to collect the now unreferenced stmts and
follow the link to the ggc_free()ed basic-block.
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug lto/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
2021-03-07 10:35 [Bug lto/99447] New: [11 Regression] ICE (segfault) in lookup_page_table_entry doko at debian dot org
` (8 preceding siblings ...)
2021-03-17 12:38 ` rguenth at gcc dot gnu.org
@ 2021-03-17 12:39 ` rguenth at gcc dot gnu.org
2021-03-17 13:30 ` hubicka at ucw dot cz
` (18 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-03-17 12:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
So like this.
diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index 80140757d16..447d9a920f7 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -1854,6 +1854,9 @@ cgraph_node::release_body (bool keep_arguments)
needed to emit debug info later. */
if (!used_as_abstract_origin && DECL_INITIAL (decl))
DECL_INITIAL (decl) = error_mark_node;
+ /* Zap references to call stmts of our body. */
+ for (cgraph_edge *e = callees; e; e = e->next_callee)
+ e->call_stmt = NULL;
release_function_body (decl);
if (lto_file_data)
{
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug lto/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
2021-03-07 10:35 [Bug lto/99447] New: [11 Regression] ICE (segfault) in lookup_page_table_entry doko at debian dot org
` (9 preceding siblings ...)
2021-03-17 12:39 ` rguenth at gcc dot gnu.org
@ 2021-03-17 13:30 ` hubicka at ucw dot cz
2021-03-25 15:27 ` marxin at gcc dot gnu.org
` (17 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: hubicka at ucw dot cz @ 2021-03-17 13:30 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
--- Comment #11 from Jan Hubicka <hubicka at ucw dot cz> ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
>
> --- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
> So like this.
>
> diff --git a/gcc/cgraph.c b/gcc/cgraph.c
> index 80140757d16..447d9a920f7 100644
> --- a/gcc/cgraph.c
> +++ b/gcc/cgraph.c
> @@ -1854,6 +1854,9 @@ cgraph_node::release_body (bool keep_arguments)
> needed to emit debug info later. */
> if (!used_as_abstract_origin && DECL_INITIAL (decl))
> DECL_INITIAL (decl) = error_mark_node;
> + /* Zap references to call stmts of our body. */
> + for (cgraph_edge *e = callees; e; e = e->next_callee)
> + e->call_stmt = NULL;
Looks good but will also need to warlk indirect calls.
However I wonder in what situations it makes sense to release body but
keep cgraph edges?
Honza
> release_function_body (decl);
> if (lto_file_data)
> {
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug lto/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
2021-03-07 10:35 [Bug lto/99447] New: [11 Regression] ICE (segfault) in lookup_page_table_entry doko at debian dot org
` (10 preceding siblings ...)
2021-03-17 13:30 ` hubicka at ucw dot cz
@ 2021-03-25 15:27 ` marxin at gcc dot gnu.org
2021-03-26 11:03 ` doko at gcc dot gnu.org
` (16 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-03-25 15:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
--- Comment #12 from Martin Liška <marxin at gcc dot gnu.org> ---
@doko: Can you please reduce objects and then .ii files needed to reproduce the
issue?
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug lto/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
2021-03-07 10:35 [Bug lto/99447] New: [11 Regression] ICE (segfault) in lookup_page_table_entry doko at debian dot org
` (11 preceding siblings ...)
2021-03-25 15:27 ` marxin at gcc dot gnu.org
@ 2021-03-26 11:03 ` doko at gcc dot gnu.org
2021-03-26 11:18 ` [Bug ipa/99447] " rguenth at gcc dot gnu.org
` (15 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: doko at gcc dot gnu.org @ 2021-03-26 11:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
Matthias Klose <doko at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |RESOLVED
Resolution|--- |WORKSFORME
CC| |doko at gcc dot gnu.org
--- Comment #13 from Matthias Klose <doko at gcc dot gnu.org> ---
rechecked with trunk 20210321, and gcc-10 branch. I can't reproduce this
anymore.
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
2021-03-07 10:35 [Bug lto/99447] New: [11 Regression] ICE (segfault) in lookup_page_table_entry doko at debian dot org
` (12 preceding siblings ...)
2021-03-26 11:03 ` doko at gcc dot gnu.org
@ 2021-03-26 11:18 ` rguenth at gcc dot gnu.org
2021-03-29 18:20 ` hubicka at gcc dot gnu.org
` (14 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-03-26 11:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|WORKSFORME |---
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org
Keywords| |lto
Component|lto |ipa
Priority|P3 |P1
Status|RESOLVED |ASSIGNED
--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Matthias Klose from comment #13)
> rechecked with trunk 20210321, and gcc-10 branch. I can't reproduce this
> anymore.
That's just bad luck. The issue needs resolving and analysis has identified
two things we can improve (cgraph edges & SSA name def stmts).
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
2021-03-07 10:35 [Bug lto/99447] New: [11 Regression] ICE (segfault) in lookup_page_table_entry doko at debian dot org
` (13 preceding siblings ...)
2021-03-26 11:18 ` [Bug ipa/99447] " rguenth at gcc dot gnu.org
@ 2021-03-29 18:20 ` hubicka at gcc dot gnu.org
2021-03-29 21:45 ` hubicka at gcc dot gnu.org
` (13 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: hubicka at gcc dot gnu.org @ 2021-03-29 18:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
--- Comment #15 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
I also tried to reproduce this locally w/o luck.
Looking at the backtrace in detail, there is no DEF_STMT involved. It walks
from dwarf dies, to RTL constant pool address that points to tree which has
abstract origin that points to symtab node which points to callgraph edge which
points to dead basic block.
The pointer from cgraph node to edge that should be removed.
I can add code to clear pointers SSA_NAME->def_stmt bit there is no def stmt in
the backtrace, so it would not help here.
W/o reproducer it seem hard to tell what is/was real cause of this issue...
Honza
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
2021-03-07 10:35 [Bug lto/99447] New: [11 Regression] ICE (segfault) in lookup_page_table_entry doko at debian dot org
` (14 preceding siblings ...)
2021-03-29 18:20 ` hubicka at gcc dot gnu.org
@ 2021-03-29 21:45 ` hubicka at gcc dot gnu.org
2021-03-30 7:20 ` rguenth at gcc dot gnu.org
` (12 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: hubicka at gcc dot gnu.org @ 2021-03-29 21:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
--- Comment #16 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
I was trying to reproduce some kind of ICE for a while, trying to also rebuild
with ggc forced on every ggc_collect call, but no luck.
I wonder if you happen to know specific gcc regression that was failing and if
it was patched or not...
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
2021-03-07 10:35 [Bug lto/99447] New: [11 Regression] ICE (segfault) in lookup_page_table_entry doko at debian dot org
` (15 preceding siblings ...)
2021-03-29 21:45 ` hubicka at gcc dot gnu.org
@ 2021-03-30 7:20 ` rguenth at gcc dot gnu.org
2021-03-30 8:49 ` hubicka at gcc dot gnu.org
` (11 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-03-30 7:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
--- Comment #17 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #15)
> I also tried to reproduce this locally w/o luck.
>
> Looking at the backtrace in detail, there is no DEF_STMT involved. It walks
> from dwarf dies, to RTL constant pool address that points to tree which has
> abstract origin that points to symtab node which points to callgraph edge
> which points to dead basic block.
>
> The pointer from cgraph node to edge that should be removed.
> I can add code to clear pointers SSA_NAME->def_stmt bit there is no def stmt
> in the backtrace, so it would not help here.
We're already doing this it seems:
void
fini_ssanames (struct function *fn)
{
unsigned i;
tree name;
/* Some SSA names leak into global tree data structures so we can't simply
ggc_free them. But make sure to clear references to stmts since we now
ggc_free the CFG itself. */
FOR_EACH_VEC_SAFE_ELT (SSANAMES (fn), i, name)
if (name)
SSA_NAME_DEF_STMT (name) = NULL;
> W/o reproducer it seem hard to tell what is/was real cause of this issue...
So the backtrace points at
gt_ggc_m_11symtab_node
((*x).generic.function_decl.common.common.symtab_node);
from LTO 'tree' walk. To me it's still obvious - we walk a cgraph edge
call_stmt and from there to gimple_bb which was freed.
Looking around the only place (we don't know whether this was WPA or LTRANS)
we'd have a cgraph with edges is during clone materialization which pointed
me at cgraph_node::release_body which frees the body but fails to eventually
zap ->call_stmt references.
Matthias reported this for "trunk 20210306" which I assume is a snapshot
tarball configured the Debian way.
> Honza
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
2021-03-07 10:35 [Bug lto/99447] New: [11 Regression] ICE (segfault) in lookup_page_table_entry doko at debian dot org
` (16 preceding siblings ...)
2021-03-30 7:20 ` rguenth at gcc dot gnu.org
@ 2021-03-30 8:49 ` hubicka at gcc dot gnu.org
2021-03-30 9:00 ` hubicka at gcc dot gnu.org
` (10 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: hubicka at gcc dot gnu.org @ 2021-03-30 8:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
--- Comment #18 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
> Looking around the only place (we don't know whether this was WPA or LTRANS)
> we'd have a cgraph with edges is during clone materialization which pointed
> me at cgraph_node::release_body which frees the body but fails to eventually
> zap ->call_stmt references
This I agree with, but during our last discussion I went through all
release_body calls and found none which would match this scenario - they are
all on paths where we zap cgraph edges to (it is only makes sense to exist in
this case, since we are supposed to keep cgrpah edges in sync with actual body
and after feeing the body this would leave cgaph in inconsistent stage).
I will try to move tree to 20210306 and see if that helps.
I can simply add cgraph edge removal to release_body to make code bit more
robust - while most uses erases edges earlier, it is almost free to check the
pointer for being NULL twice. Still it is weird that the bug does not
reproduce with allways collect.
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
2021-03-07 10:35 [Bug lto/99447] New: [11 Regression] ICE (segfault) in lookup_page_table_entry doko at debian dot org
` (17 preceding siblings ...)
2021-03-30 8:49 ` hubicka at gcc dot gnu.org
@ 2021-03-30 9:00 ` hubicka at gcc dot gnu.org
2021-03-30 12:16 ` hubicka at gcc dot gnu.org
` (9 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: hubicka at gcc dot gnu.org @ 2021-03-30 9:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
--- Comment #19 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Created attachment 50485
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50485&action=edit
small refactoring
this patch moves the removal to release_body and removes the calls on those
paths where removal is done just after call to it (as opposed to being done
earlier or via reset cal).
But still there is no code path where it should make difference. Pehraps the
assert will catch something interesting. Tests are running.
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
2021-03-07 10:35 [Bug lto/99447] New: [11 Regression] ICE (segfault) in lookup_page_table_entry doko at debian dot org
` (18 preceding siblings ...)
2021-03-30 9:00 ` hubicka at gcc dot gnu.org
@ 2021-03-30 12:16 ` hubicka at gcc dot gnu.org
2021-03-31 9:18 ` doko at debian dot org
` (8 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: hubicka at gcc dot gnu.org @ 2021-03-30 12:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
Jan Hubicka <hubicka at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |WAITING
--- Comment #20 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
I re-tried with g:0ad6a2e2f0c667f9916cfcdb81f41f6055f1d0b3
and it builds all fine even with --param ggc-min-expand=0 --param
ggc-min-heapsize=0. It seems that --enable-checking=gcac is now noop.
@doko: perhaps using --param ggc-min-expand=0 --param ggc-min-heapsize=0 on
your setup may trigger the problem again. There is some chance that i.e. the
qt headers are the cause, but I am tempted to close the bug as WORKSFORME after
committing the refactoring patch.
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
2021-03-07 10:35 [Bug lto/99447] New: [11 Regression] ICE (segfault) in lookup_page_table_entry doko at debian dot org
` (19 preceding siblings ...)
2021-03-30 12:16 ` hubicka at gcc dot gnu.org
@ 2021-03-31 9:18 ` doko at debian dot org
2021-03-31 9:18 ` doko at gcc dot gnu.org
` (7 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: doko at debian dot org @ 2021-03-31 9:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
--- Comment #21 from Matthias Klose <doko at debian dot org> ---
building with trunk 20210330 using these parameters didn't succeed:
make[1]: Entering directory '/packages/tmp/guymager-0.8.12'
g++ -c -pipe -g -O2 -ffile-prefix-map=/packages/tmp/guymager-0.8.12=.
-flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat
-Werror=format-security --param ggc-min-expand=0 ggc-min-heapsize=0
-fmessage-length=0 -fno-strict-aliasing -flto -g
-ffile-prefix-map=/packages/tmp/guymager-0.8.12=. -flto=auto -ffat-lto-objects
-fstack-protector-strong -Wformat -Werror=format-security --param
ggc-min-expand=0 --param ggc-min-heapsize=0 -Wdate-time -D_FORTIFY_SOURCE=2 -O3
-ggdb -std=gnu++1y -Wall -Wextra -D_REENTRANT -fPIC
-DSPLASH_DIR='"/usr/share/guymager"' -DLANGUAGE_DIR='"/usr/share/guymager"'
-DLANGUAGE_DIR_QT='"/usr/share/qt5/translations"' -DQT_NO_DEBUG
-DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_DBUS_LIB -DQT_CORE_LIB -I.
-I/usr/include/libguytools2 -I/usr/include/x86_64-linux-gnu/qt5
-I/usr/include/x86_64-linux-gnu/qt5/QtWidgets
-I/usr/include/x86_64-linux-gnu/qt5/QtGui
-I/usr/include/x86_64-linux-gnu/qt5/QtDBus
-I/usr/include/x86_64-linux-gnu/qt5/QtCore -Imoc
-I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -o aaff.o aaff.cpp
g++: warning: ggc-min-heapsize=0: linker input file unused because linking not
done
g++: error: ggc-min-heapsize=0: linker input file not found: No such file or
directory
make[1]: *** [Makefile:897: aaff.o] Error 1
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
2021-03-07 10:35 [Bug lto/99447] New: [11 Regression] ICE (segfault) in lookup_page_table_entry doko at debian dot org
` (20 preceding siblings ...)
2021-03-31 9:18 ` doko at debian dot org
@ 2021-03-31 9:18 ` doko at gcc dot gnu.org
2021-03-31 9:19 ` doko at gcc dot gnu.org
` (6 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: doko at gcc dot gnu.org @ 2021-03-31 9:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
Matthias Klose <doko at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |NEW
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
2021-03-07 10:35 [Bug lto/99447] New: [11 Regression] ICE (segfault) in lookup_page_table_entry doko at debian dot org
` (21 preceding siblings ...)
2021-03-31 9:18 ` doko at gcc dot gnu.org
@ 2021-03-31 9:19 ` doko at gcc dot gnu.org
2021-03-31 9:33 ` hubicka at ucw dot cz
` (5 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: doko at gcc dot gnu.org @ 2021-03-31 9:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
--- Comment #22 from Matthias Klose <doko at gcc dot gnu.org> ---
this is a compiler configured with --enable-default--pie
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
2021-03-07 10:35 [Bug lto/99447] New: [11 Regression] ICE (segfault) in lookup_page_table_entry doko at debian dot org
` (22 preceding siblings ...)
2021-03-31 9:19 ` doko at gcc dot gnu.org
@ 2021-03-31 9:33 ` hubicka at ucw dot cz
2021-03-31 9:35 ` cvs-commit at gcc dot gnu.org
` (4 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: hubicka at ucw dot cz @ 2021-03-31 9:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
--- Comment #23 from Jan Hubicka <hubicka at ucw dot cz> ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
>
> --- Comment #21 from Matthias Klose <doko at debian dot org> ---
> building with trunk 20210330 using these parameters didn't succeed:
>
> make[1]: Entering directory '/packages/tmp/guymager-0.8.12'
> g++ -c -pipe -g -O2 -ffile-prefix-map=/packages/tmp/guymager-0.8.12=.
> -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat
> -Werror=format-security --param ggc-min-expand=0 ggc-min-heapsize=0
^^^ missing --param here
(which may be my mistake in earlier comment, sorry for htat)
Honza
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
2021-03-07 10:35 [Bug lto/99447] New: [11 Regression] ICE (segfault) in lookup_page_table_entry doko at debian dot org
` (23 preceding siblings ...)
2021-03-31 9:33 ` hubicka at ucw dot cz
@ 2021-03-31 9:35 ` cvs-commit at gcc dot gnu.org
2021-03-31 9:39 ` hubicka at ucw dot cz
` (3 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-03-31 9:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
--- Comment #24 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jan Hubicka <hubicka@gcc.gnu.org>:
https://gcc.gnu.org/g:d7145b4bb6c8729a1e782373cb6256c06ed60465
commit r11-7926-gd7145b4bb6c8729a1e782373cb6256c06ed60465
Author: Jan Hubicka <jh@suse.cz>
Date: Wed Mar 31 11:35:29 2021 +0200
Small refactoring of cgraph_node::release_body
PR lto/99447
* cgraph.c (cgraph_node::release_body): Remove all callers and
references.
* cgraphclones.c (cgraph_node::materialize_clone): Do not do it
here.
* cgraphunit.c (cgraph_node::expand): And here.
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
2021-03-07 10:35 [Bug lto/99447] New: [11 Regression] ICE (segfault) in lookup_page_table_entry doko at debian dot org
` (24 preceding siblings ...)
2021-03-31 9:35 ` cvs-commit at gcc dot gnu.org
@ 2021-03-31 9:39 ` hubicka at ucw dot cz
2021-03-31 18:10 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: hubicka at ucw dot cz @ 2021-03-31 9:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
--- Comment #25 from Jan Hubicka <hubicka at ucw dot cz> ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
>
> --- Comment #23 from Jan Hubicka <hubicka at ucw dot cz> ---
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
> >
> > --- Comment #21 from Matthias Klose <doko at debian dot org> ---
> > building with trunk 20210330 using these parameters didn't succeed:
> >
> > make[1]: Entering directory '/packages/tmp/guymager-0.8.12'
> > g++ -c -pipe -g -O2 -ffile-prefix-map=/packages/tmp/guymager-0.8.12=.
> > -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat
^^^ this is interesting differnce, I will give it a try.
It did not occured to me you are using fat lto objects
(which is not very good idea in general since
nm/ranlib/ar gets confused by it)
Honza
> > -Werror=format-security --param ggc-min-expand=0 ggc-min-heapsize=0
> ^^^ missing --param here
> (which may be my mistake in earlier comment, sorry for htat)
>
> Honza
>
> --
> You are receiving this mail because:
> You are the assignee for the bug.
> You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
2021-03-07 10:35 [Bug lto/99447] New: [11 Regression] ICE (segfault) in lookup_page_table_entry doko at debian dot org
` (25 preceding siblings ...)
2021-03-31 9:39 ` hubicka at ucw dot cz
@ 2021-03-31 18:10 ` cvs-commit at gcc dot gnu.org
2021-03-31 18:12 ` hubicka at gcc dot gnu.org
2021-04-01 12:50 ` doko at debian dot org
28 siblings, 0 replies; 30+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-03-31 18:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
--- Comment #26 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jan Hubicka <hubicka@gcc.gnu.org>:
https://gcc.gnu.org/g:23ce9945d5efa77c96161443f68e03664705ada3
commit r11-7933-g23ce9945d5efa77c96161443f68e03664705ada3
Author: Jan Hubicka <jh@suse.cz>
Date: Wed Mar 31 20:10:31 2021 +0200
Fix overvactive check in cgraph_node::release_body
gcc/ChangeLog:
PR lto/99447
* cgraph.c (cgraph_node::release_body): Fix overactive check.
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
2021-03-07 10:35 [Bug lto/99447] New: [11 Regression] ICE (segfault) in lookup_page_table_entry doko at debian dot org
` (26 preceding siblings ...)
2021-03-31 18:10 ` cvs-commit at gcc dot gnu.org
@ 2021-03-31 18:12 ` hubicka at gcc dot gnu.org
2021-04-01 12:50 ` doko at debian dot org
28 siblings, 0 replies; 30+ messages in thread
From: hubicka at gcc dot gnu.org @ 2021-03-31 18:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
Jan Hubicka <hubicka at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |WAITING
--- Comment #27 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Even with pie and fat LTO the compilation works well. In addition I committed
patch that should make it clear that we to not stale pointers.
Without a reproducer I am not sure what we can do more, so perhaps we can
resolve it as WORKSFORME.
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
2021-03-07 10:35 [Bug lto/99447] New: [11 Regression] ICE (segfault) in lookup_page_table_entry doko at debian dot org
` (27 preceding siblings ...)
2021-03-31 18:12 ` hubicka at gcc dot gnu.org
@ 2021-04-01 12:50 ` doko at debian dot org
28 siblings, 0 replies; 30+ messages in thread
From: doko at debian dot org @ 2021-04-01 12:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
Matthias Klose <doko at debian dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |WORKSFORME
Status|WAITING |RESOLVED
--- Comment #28 from Matthias Klose <doko at debian dot org> ---
also retried with trunk 20210331, and the two extra --param settings. Can't
reproduce it anymore.
^ permalink raw reply [flat|nested] 30+ messages in thread