having trouble running generic linked list program

Terry_Wong · ‎03-05-2014

I have a small test program which creates a generic linked list. It compiles, but doesn't run.

When I try to access the values of the link, it gets a memory error (access violation).

The values of the list are pointers to unlimited polymorphic variables.

I have attached the code.

Can you tell me what I'm doing wrong?

Thanks

pbkenned1 · ‎03-06-2014

Hello Terry,

I think in link.f90, instead of:

type link
    !private
    class(*), pointer :: value => null()
    type(link), pointer :: next => null()

you should first define 'next' as:

type link
    !private
    class(*), pointer :: value => null()
    class(link), pointer :: next => null()

Otherwise, you will have conflicting pointer type assignments at line 31 (constructor%next => next) and line 44 ( this%next => next), ie, you would attempting to assign CLASS(link) to TYPE(link).

I made that change, and the code compiled and linked, but the executable crashed at line 56 in link.f90, on the select type:

    subroutine printLink(this)
      implicit none
      class(link) :: this
      select type(v => this%value)

I don't know if this is a compiler bug or not. I'll need to work through the traceback. I suspect something funny about line 59:

type is (character(*))

I think this is legal, but I'll need to look into it.

Thank you,

Patrick

pbkenned1 · ‎03-07-2014

Hello Terry,

The access violation is due to a bug in link.f90, subroutine printLinks.

On first entry, 'curr' is unassociated.

If you comment out the call to printLink (as shown), the program runs normally.

    subroutine printLinks(this)
    implicit none
    class(link) :: this
    class(link), pointer :: curr

!!!    call printLink(curr)
    curr => this%next
    do while(associated(curr))
      call printLink(curr)
      curr => curr%next
    enddo

With that change, things seem normal:

>ifort link.f90 list_0.f90 generic_linklist.f90 -Fe:foo.exe

-out:foo.exe
-subsystem:console
link.obj
list_0.obj
generic_linklist.obj

>foo
           2
           3
           4
           5
           6
           7
           8
           9
          10
   1.230000
A
B

Is that the correct output?

Thanks,

Patrick

Terry_Wong · ‎03-08-2014

Thanks Patrick, that did fix the problem.

However, I wanted to print the first element as well, so instead of commenting out the first call to printLink, I preceded it with curr=>this, or I could have used printLink(this).

One comment, I can't see the value variable in the debugger. Is this because it is a unlimited polymorphic variable?

pbkenned1 · ‎03-10-2014

Hi Terry,

I don't know of a restriction viewing class(*) variables in the debugger. Could you be more specific? For example, using VS2012, in subroutine addInteger(this, value), I set a breakpoint on the allocate statement at line 56:

allocate(v,source=value) !! line 56

With a Debug x64 configuation, I can repeatedly run to that breakpoint and see 'value' updated with every pass:
U506813.exe!LIST_MOD_mp_ADDINTEGER(TYPE(LIST) THIS={...} , INTEGER(4) VALUE=#00000004 ) Line 56 Unknown

What do you see?

Thanks,

Patrick

Terry_Wong · ‎03-10-2014

Yes, I can see the what the variable value contains, but after I allocate v, I cannot see what v contains.

Also, when I am looping through prinkLink, the debugger cannot show me the value of v or this%value.

I am using the debugger in 64 bit mode.

Thanks for looking at it.

Terry

Steven_L_Intel1 · ‎03-10-2014

A class(*) variable has no type on its own - you need to be within a SELECT TYPE construct and then a new "copy" of the variable will be visible in the debugger and you can see its contents as if it were the selected type.

pbkenned1 · ‎03-10-2014

Hi Terry,

Thanks for the feedback. Right, I can't see the value of the associate-name variable (ie, the 'v') nor the value of this%value in PrintLink(). You might have run into a limitation of the Fortran Expression Evaluator (FEE). I'll ask the developers.

Patrick