This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: ICE seg fault
Hi Florian,
Florian Ladstaedter wrote:
> ok thanks a lot. I send you the output of valgrind -v and of gdb, in
> case it already helps you. Although I guess you will need a piece of
> code as well...? Still not sure how to extract the relevant pieces though.
I think we need a piece of code. The best way is to start deleting
function/subroutine bodies step by step and see whether it still gives
an ICE (if not use the editor's undo function and remove something else)
. Then deleting the functions itself etc. After one has reduced it, one
can start removing some of the used modules etc. Then one can put the
remaining modules in the same file and reduce them etc.
This unfortunately takes some time, but is usually easier than it sounds
(I can also reduce it, if you make the source available [possibly
without copyright violation]; you can send it to me by email if you want.)
> 0x08064563 in check_specification_function (e=<value optimized out>)
> at ../../gcc/gcc/fortran/expr.c:696
> 696 sym = e->symtree->n.sym;
> ==12878== Invalid read of size 4
> ==12878== at 0x8064563: check_specification_function (expr.c:696)
> ==12878== Address 0x14 is not stack'd, malloc'd or (recently) free'd
At least gdb and valgrind agree on the problem. The problem must be
somehow related to expressions which are regarded as functions
(EXPR_FUNCTION), not necessarily statement functions, and seemingly the
e->symtree == NULL.
A backtrace (i.e. running in gdb and entering after the segfault "bt")
would help too.
You could also try to find out more about the expression. In gdb after
the segfault do:
p e->symtree
p e->where
p e->where->lb->file->filename
p e->where->lb->file->line
This should give some clue where it crashes.
Tobias