Bug 47546 - [OOP] Internal error - free_pi_tree(): Unresolved fixup
Summary: [OOP] Internal error - free_pi_tree(): Unresolved fixup
Status: RESOLVED WORKSFORME
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.6.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks:
 
Reported: 2011-01-30 19:03 UTC by Rich Townsend
Modified: 2011-03-29 19:15 UTC (History)
3 users (show)

See Also:
Host:
Target: x86_64-apple-darwin10.6.0
Build:
Known to work:
Known to fail:
Last reconfirmed: 2011-01-30 19:21:40


Attachments
Tar file containing source code and Makefile (1.25 KB, application/x-gzip)
2011-01-30 19:03 UTC, Rich Townsend
Details
Valgrind out for test case that completes compilation (2.65 KB, text/plain)
2011-03-16 04:10 UTC, Jerry DeLisle
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rich Townsend 2011-01-30 19:03:07 UTC
Created attachment 23169 [details]
Tar file containing source code and Makefile

Compiling the attached code:

gfortran -c hydro_types.f90 hydro_state.f90 hydro_speeds.f90 hydro_fluxes.f90

...I get the following error:

hydro_fluxes.f90:7.18:

  use hydro_speeds
                  1
Internal Error at (1):
free_pi_tree(): Unresolved fixup
Comment 1 Dominique d'Humieres 2011-01-30 19:21:40 UTC
The code compiles with if I concatenate all the files in a single one. The ICE is still there if I reduce the file hydro_fluxes.f90 to

module hydro_fluxes

! Uses

  use hydro_types
  use hydro_state
  use hydro_speeds

end module hydro_fluxes

and disappears if I comment the line

  use hydro_speeds

If gfortran is 4.5, I get 

hydro_fluxes.f90:7.18:

  use hydro_speeds
                  1
Internal Error at (1):
mio_component_ref(): Component not found

so it looks like an avatar of pr45827.
Comment 2 Mikael Morin 2011-01-30 19:45:02 UTC
It works here if I circumvent the driver.

$ for file in hydro_types.f90 hydro_state.f90 hydro_speeds.f90 hydro_fluxes.f90
do
~/gcc46/build/gcc/f951 $file
done
Comment 3 janus 2011-02-02 14:49:16 UTC
(In reply to comment #1)
> If gfortran is 4.5, I get 
> 
> hydro_fluxes.f90:7.18:
> 
>   use hydro_speeds
>                   1
> Internal Error at (1):
> mio_component_ref(): Component not found


I get the same error with gfortran 4.5, but 4.6 works nicely for me at r169520. Rich, which version are you using?
Comment 4 Rich Townsend 2011-02-02 16:52:49 UTC
On Feb 2, 2011, at 8:49 AM, janus at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47546
> 
> --- Comment #3 from janus at gcc dot gnu.org 2011-02-02 14:49:16 UTC ---
> (In reply to comment #1)
>> If gfortran is 4.5, I get 
>> 
>> hydro_fluxes.f90:7.18:
>> 
>>  use hydro_speeds
>>                  1
>> Internal Error at (1):
>> mio_component_ref(): Component not found
> 
> 
> I get the same error with gfortran 4.5, but 4.6 works nicely for me at r169520.
> Rich, which version are you using?

Here's what gfortran -v gives:

Using built-in specs.
COLLECT_GCC=gfortran-mp-4.6
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin10/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10
Configured with: ../gcc-4.6-20110122/configure --prefix=/opt/local --build=x86_64-apple-darwin10 --libdir=/opt/local/lib/gcc46 --includedir=/opt/local/include/gcc46 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-4.6 --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-4.6 --with-gxx-include-dir=/opt/local/include/gcc46/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --enable-stage1-checking --disable-multilib --enable-fully-dynamic-string --enable-languages=c,c++,objc,obj-c++,fortran
Thread model: posix
gcc version 4.6.0 20110122 (experimental) (GCC) 

The install is via macports.

cheers,

Rich
Comment 5 janus 2011-02-02 17:14:56 UTC
(In reply to comment #4)
> > Rich, which version are you using?
> 
> Here's what gfortran -v gives:
> [...]
> Target: x86_64-apple-darwin10
> [...]
> gcc version 4.6.0 20110122 (experimental) (GCC) 

Huh. Either it has been fixed in the meantime or it is a Darwin-specific problem, since I don't see it on Linux with the current trunk.
Comment 6 janus 2011-02-02 18:25:42 UTC
(In reply to comment #0)
> hydro_fluxes.f90:7.18:
> 
>   use hydro_speeds
>                   1
> Internal Error at (1):
> free_pi_tree(): Unresolved fixup

I can reproduce the error on Darwin with current trunk (r169590).
Comment 7 Dominique d'Humieres 2011-02-02 18:51:17 UTC
> I can reproduce the error on Darwin with current trunk (r169590).

Me too at revision 169531. Revision 158105 gives

hydro_fluxes.f90:7.18:

  use hydro_speeds
                  1
Internal Error at (1):
mio_component_ref(): Component not found

revision 159105 gives

hydro_fluxes.f90:7.18:

  use hydro_speeds
                  1
Internal Error at (1):
free_pi_tree(): Unresolved fixup
Comment 8 janus 2011-02-02 19:31:39 UTC
This is a *very* strange bug, to say the least. Here is a reduced test case:


module hydro_types
  implicit none
end module hydro_types

module hydro_state
  implicit none
  type :: state_t
     real    :: U         
     integer :: n
  end type
  private
  public :: state_t
contains
  subroutine init
    type(state_t) :: this
  end subroutine init
end module hydro_state

module hydro_speeds
  use hydro_state
  implicit none
contains
  subroutine speeds_cell (st, c_l, c_r)
    class(state_t) :: st
    real     :: c_l(st%n)
    real     :: c_r(st%n)
  end subroutine speeds_cell
end module hydro_speeds

module hydro_fluxes
  use hydro_state
  use hydro_speeds
end module



Putting this in a single file and compiling still gives me the error:

  use hydro_speeds
                  1
Interner Fehler bei (1):
free_pi_tree(): Unresolved fixup


I'm not quite sure it is related to OOP. There is still one CLASS variable in there which I could not remove.

On the other hand, the failure is very elusive: Even removing the 'implicit none' line in the module 'hydro_types' (which btw is never used) will make it go away for me.
Comment 9 Rich Townsend 2011-02-02 19:56:25 UTC
(In reply to comment #8)
> On the other hand, the failure is very elusive: Even removing the 'implicit
> none' line in the module 'hydro_types' (which btw is never used) will make it
> go away for me.

Sounds like a Heisenbug -- it goes away when you look for it. Would it be worth bringing valgrind into the picture?

cheers,

Rich
Comment 10 janus 2011-02-02 20:15:07 UTC
(In reply to comment #9)
> Sounds like a Heisenbug -- it goes away when you look for it. Would it be worth
> bringing valgrind into the picture?

Maybe. Could you try if it gives any useful output? Also: Can you reproduce the error with my reduced test case in comment #8?


A different thought: Since 4.5 gives on the same test case

mio_component_ref(): Component not found

it may be related to PR45827.
Comment 11 Dominique d'Humieres 2011-02-02 21:04:14 UTC
> ... Also: Can you reproduce the
> error with my reduced test case in comment #8?

I can. Apparently some p->fixup has not been initialized/nullified.
Comment 12 janus 2011-02-02 21:17:23 UTC
(In reply to comment #11)
> > ... Also: Can you reproduce the
> > error with my reduced test case in comment #8?
> 
> I can. Apparently some p->fixup has not been initialized/nullified.

In fact I can even reproduce this on Linux (in contrast to the code in comment #0).
Comment 13 Mikael Morin 2011-02-02 21:26:56 UTC
(In reply to comment #12)
> (In reply to comment #11)
> > > ... Also: Can you reproduce the
> > > error with my reduced test case in comment #8?
> > 
> > I can. Apparently some p->fixup has not been initialized/nullified.
> 
> In fact I can even reproduce this on Linux (in contrast to the code in comment
> #0).

Same on FreeBSD. 
It is something with the 'n' component of type state_t. 
That component is needed in hydro_speeds for the prototype of speeds_cell but it is not found somehow. 
I can see it in the module file however.
Comment 14 Mikael Morin 2011-02-02 22:24:54 UTC
in read_module, around line 4390

	  /* Skip symtree nodes not in an ONLY clause, unless there
	     is an existing symtree loaded from another USE statement.  */
	  if (p == NULL)
	    {
	      st = gfc_find_symtree (gfc_current_ns->sym_root, name);
	      if (st != NULL)
		info->u.rsym.symtree = st;
	      continue;
	    }


state_t from hydro_speeds(imported from hydro_state) is not loaded because state_t from hydro_state is already present in the namespace. Thus the components of state_t from hydro_speeds are not loaded either. 

I don't see any obvious/easy fix right now.

I think there were some module symbol conflicts PRs more or less related to this, but can't find them.
Comment 15 Rich Townsend 2011-02-03 00:09:57 UTC
(In reply to comment #10)
> (In reply to comment #9)
> > Sounds like a Heisenbug -- it goes away when you look for it. Would it be worth
> > bringing valgrind into the picture?
> 
> Maybe. Could you try if it gives any useful output? 

==13807== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==13807== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==13807== Command: gfortran-mp-4.6 -c foo.f90
==13807== 
foo.f90:32.17:

 use hydro_speeds
                 1
Internal Error at (1):
free_pi_tree(): Unresolved fixup
==13807== 
==13807== HEAP SUMMARY:
==13807==     in use at exit: 33,558 bytes in 82 blocks
==13807==   total heap usage: 135 allocs, 53 frees, 35,636 bytes allocated
==13807== 
==13807== LEAK SUMMARY:
==13807==    definitely lost: 2,027 bytes in 31 blocks
==13807==    indirectly lost: 75 bytes in 2 blocks
==13807==      possibly lost: 4,085 bytes in 2 blocks
==13807==    still reachable: 27,371 bytes in 47 blocks
==13807==         suppressed: 0 bytes in 0 blocks
==13807== Rerun with --leak-check=full to see details of leaked memory
==13807== 
==13807== For counts of detected and suppressed errors, rerun with: -v
==13807== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 3 from 3)

Nothing particularly alarming -- although I guess those memory leaks might need fixing at some point.

> Also: Can you reproduce the
> error with my reduced test case in comment #8?
> 

Done -- and I get the same fixup error.

> 
> A different thought: Since 4.5 gives on the same test case
> 
> mio_component_ref(): Component not found
> 
> it may be related to PR45827.
Comment 16 Mikael Morin 2011-02-03 18:32:07 UTC
Rich, in case this is a blocker on a real world application, you can probably circumvent the error by not use-importing hydro_state when you use-import hydro_speeds.
Comment 17 Rich Townsend 2011-02-03 22:54:34 UTC
(In reply to comment #16)
> Rich, in case this is a blocker on a real world application, you can probably
> circumvent the error by not use-importing hydro_state when you use-import
> hydro_speeds.

Thanks -- v. helpful suggestion. I implemented this by moving the hydro_speeds routines into hydro_state, and the code compiles and runs fine.

cheers,

Rich
Comment 18 Rich Townsend 2011-02-03 23:04:22 UTC
(In reply to comment #8)
> This is a *very* strange bug, to say the least. Here is a reduced test case:
> 
> 
> module hydro_types
>   implicit none
> end module hydro_types
> 
> module hydro_state
>   implicit none
>   type :: state_t
>      real    :: U         
>      integer :: n
>   end type
>   private
>   public :: state_t
> contains
>   subroutine init
>     type(state_t) :: this
>   end subroutine init
> end module hydro_state
> 
> module hydro_speeds
>   use hydro_state
>   implicit none
> contains
>   subroutine speeds_cell (st, c_l, c_r)
>     class(state_t) :: st
>     real     :: c_l(st%n)
>     real     :: c_r(st%n)
>   end subroutine speeds_cell
> end module hydro_speeds
> 
> module hydro_fluxes
>   use hydro_state
>   use hydro_speeds
> end module

Here's an interesting observation: if the definitions of c_l and c_r are changed to

 real     :: c_l(:)
 real     :: c_r(:)

(i.e., assumed shape rather than explicit shape), then the problem goes away.

In the interests of full disclosure, I should add that this is how I intended to code the speeds_cell routine in the first place -- I have no real need of the explicit shapes, assumed shapes are just fine. So, this bug becomes much less of a showstopper for me.
Comment 19 Rich Townsend 2011-03-16 02:29:35 UTC
(In reply to comment #18)
> (In reply to comment #8)
> > This is a *very* strange bug, to say the least. Here is a reduced test case:
> > 
> > 
> > module hydro_types
> >   implicit none
> > end module hydro_types
> > 
> > module hydro_state
> >   implicit none
> >   type :: state_t
> >      real    :: U         
> >      integer :: n
> >   end type
> >   private
> >   public :: state_t
> > contains
> >   subroutine init
> >     type(state_t) :: this
> >   end subroutine init
> > end module hydro_state
> > 
> > module hydro_speeds
> >   use hydro_state
> >   implicit none
> > contains
> >   subroutine speeds_cell (st, c_l, c_r)
> >     class(state_t) :: st
> >     real     :: c_l(st%n)
> >     real     :: c_r(st%n)
> >   end subroutine speeds_cell
> > end module hydro_speeds
> > 
> > module hydro_fluxes
> >   use hydro_state
> >   use hydro_speeds
> > end module
> 
> Here's an interesting observation: if the definitions of c_l and c_r are
> changed to
> 
>  real     :: c_l(:)
>  real     :: c_r(:)
> 
> (i.e., assumed shape rather than explicit shape), then the problem goes away.
> 
> In the interests of full disclosure, I should add that this is how I intended
> to code the speeds_cell routine in the first place -- I have no real need of
> the explicit shapes, assumed shapes are just fine. So, this bug becomes much
> less of a showstopper for me.

Well, I spoke too soon -- I've just gone through a code refactorization, and this same bug has cropped up again. This time, the 'workaround' above no longer helps out.

Fundamentally, this is a problem that hasn't gone away; the reduced test case fails in exactly the same way, even using a recent (4.6.0 20110312) build. Has anyone been able to figure out what is going on?
Comment 20 Jerry DeLisle 2011-03-16 02:48:41 UTC
I see the problem on x86-64 linux with current trunk.

Problem goes away if I reverse the order of the use statements:

From:

module hydro_fluxes
  use hydro_state
  use hydro_speeds
end module

To:

module hydro_fluxes
  use hydro_speeds
  use hydro_state
end module

This hints at some sort of namespace corruption, maybe related to hydro_speeds uses hydro_state.
Comment 21 Jerry DeLisle 2011-03-16 02:57:02 UTC
partial valgrind:

==3316== 5,104 bytes in 2 blocks are definitely lost in loss record 433 of 443
==3316==    at 0x4A04896: calloc (vg_replace_malloc.c:418)
==3316==    by 0xD49748: xcalloc (xmalloc.c:162)
==3316==    by 0x522F6D: gfc_get_namespace (symbol.c:2286)
==3316==    by 0x524C64: gfc_copy_formal_args (symbol.c:4022)
==3316==    by 0x5250F1: gfc_copy_formal_args_ppc (symbol.c:4151)
==3316==    by 0x50782A: resolve_fl_derived (resolve.c:11474)
==3316==    by 0x50233E: resolve_symbol (resolve.c:12021)
==3316==    by 0x504110: resolve_structure_cons (resolve.c:967)
==3316==    by 0x50D581: resolve_values (resolve.c:9313)
==3316==    by 0x51EFF6: traverse_ns (symbol.c:3333)
==3316==    by 0x51EFE5: traverse_ns (symbol.c:3330)
==3316==    by 0x50C8EE: resolve_types (resolve.c:13530)
==3316== 
==3316== 8,600 (5,104 direct, 3,496 indirect) bytes in 2 blocks are definitely lost in loss record 435 of 443
==3316==    at 0x4A04896: calloc (vg_replace_malloc.c:418)
==3316==    by 0xD49748: xcalloc (xmalloc.c:162)
==3316==    by 0x522F6D: gfc_get_namespace (symbol.c:2286)
==3316==    by 0x524C64: gfc_copy_formal_args (symbol.c:4022)
==3316==    by 0x5250F1: gfc_copy_formal_args_ppc (symbol.c:4151)
==3316==    by 0x50782A: resolve_fl_derived (resolve.c:11474)
==3316==    by 0x50233E: resolve_symbol (resolve.c:12021)
==3316==    by 0x51EFF6: traverse_ns (symbol.c:3333)
==3316==    by 0x50C7A3: resolve_types (resolve.c:13513)
==3316==    by 0x501363: gfc_resolve (resolve.c:13612)
==3316==    by 0x4F5E77: gfc_parse_file (parse.c:4368)
==3316==    by 0x52FAA5: gfc_be_parse_file (f95-lang.c:250)
Comment 22 Jerry DeLisle 2011-03-16 02:58:59 UTC
Another valgrind chunk:

==3316== 318 bytes in 2 blocks are definitely lost in loss record 357 of 443
==3316==    at 0x4A04896: calloc (vg_replace_malloc.c:418)
==3316==    by 0xD49748: xcalloc (xmalloc.c:162)
==3316==    by 0x656E34: init_emit (emit-rtl.c:5544)
==3316==    by 0x6EA958: prepare_function_start (function.c:4433)
==3316==    by 0x6F09F8: init_function_start (function.c:4487)
==3316==    by 0x54859E: trans_function_start.clone.0 (trans-decl.c:2103)
==3316==    by 0x552C60: gfc_generate_function_code (trans-decl.c:4728)
==3316==    by 0x534CA1: gfc_generate_module_code (trans.c:1511)
==3316==    by 0x4F6344: gfc_parse_file (parse.c:4379)
==3316==    by 0x52FAA5: gfc_be_parse_file (f95-lang.c:250)
==3316==    by 0x845EC6: toplev_main (toplev.c:579)
==3316==    by 0x3F03A1EE5C: (below main) (libc-start.c:226)
==3316==
Comment 23 Jerry DeLisle 2011-03-16 03:01:11 UTC
Another small piece just before the error message.

$ valgrind --leak-check=full f951 pr47546.f90 
==3316== Memcheck, a memory error detector
==3316== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==3316== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==3316== Command: f951 pr47546.f90
==3316== 
 init __copy_hydro_state_State_t speeds_cellpr47546.f90:32.18:

  use hydro_speeds
                  1
Internal Error at (1):
free_pi_tree(): Unresolved fixup

What the heck is that?
Comment 24 Jerry DeLisle 2011-03-16 04:10:09 UTC
Created attachment 23678 [details]
Valgrind out for test case that completes compilation

This attachment with the version of the test case that compiled without error shows the valgrind errors.  Hope this helps isolate the problem.
Comment 25 Dominique d'Humieres 2011-03-29 16:57:17 UTC
AFAICT this pr seems fixed by revision 171654 (pr48095).
Comment 26 janus 2011-03-29 17:12:54 UTC
(In reply to comment #25)
> AFAICT this pr seems fixed by revision 171654 (pr48095).

Oh, wow. That's kind of unexpected. But nice :)
Comment 27 janus 2011-03-29 17:28:43 UTC
(In reply to comment #25)
> AFAICT this pr seems fixed by revision 171654 (pr48095).

I can confirm that comment #8 works with current trunk on x86_64-unknown-linux-gnu. However, I do not see how or why it is fixed. The only explanation I have is that it was a bug in module I/O, and the modified module format somehow fixes (or just hides) it.

Rich, can you confirm that all test cases in this PR now work for you?

Also, since PR 47601 may be related, can someone check if this is fixed too (on Darwin)?
Comment 28 janus 2011-03-29 19:15:49 UTC
Comment #0 also works for me on darwin, so I'm closing this PR.

PR47601, however, does not seem to be fully fixed yet.