PGI User Forum
 SearchSearch   MemberlistMemberlist     RegisterRegister   ProfileProfile    Log inLog in 

CUDA-x86.

Segmentation fault--reason unknown
Goto page Previous  1, 2, 3, 4, 5  Next
 
Post new topic   Reply to topic    PGI User Forum Forum Index -> Debugging and Profiling
View previous topic :: View next topic  
Author Message
yus



Joined: 06 Oct 2008
Posts: 18

PostPosted: Tue Dec 09, 2008 7:52 am    Post subject: Reply with quote

Hi Mat,

Is there any luck to track down the possible cause of the segmentation fault in my submitted code?

Cheers.
Back to top
View user's profile
mkcolg



Joined: 30 Jun 2004
Posts: 5815
Location: The Portland Group Inc.

PostPosted: Tue Dec 09, 2008 9:56 am    Post subject: Reply with quote

Hi yus,

Sorry this one is has taken me so long. I have been working on it as a back ground task for the past few weeks.

What's happening is the derived type pointer called "density" is being hoisted out of the loop. The descriptor for "denisty" is being set to NULL somehow so when it's dereferenced it causes a seg fault. Note that while denisity's value is NULL, it's descriptor should be a legal value.

I'm currently try to determine if the stack is being corrupted (like from an array bounds error) to cause the descriptor to be set to zero. This might be a red herring, but that what I'll be investigating today.

FYI, you should take a look at actual you're passing. You map RMEM(RPT) to VecY and VecZ, BIGM to C1T, C2T, C3t, and BIGM. This is illegal Fortran and can cause inconsistent results. Fortran allows the compiler to assume arrays are disjoint and hence reorder some operations. Since C1T, C2T, C3T are all accessing the same array, you can get different answers depending on the order of operations. I don't think it's causing the seg fault, but is something to be aware of.

- Mat
Back to top
View user's profile
yus



Joined: 06 Oct 2008
Posts: 18

PostPosted: Tue Dec 09, 2008 10:17 am    Post subject: Reply with quote

Thanks Mat, you rock! I will check these points.
Back to top
View user's profile
mkcolg



Joined: 30 Jun 2004
Posts: 5815
Location: The Portland Group Inc.

PostPosted: Thu Dec 11, 2008 12:13 pm    Post subject: Reply with quote

Hi yus,

Below is the portion of the code that's causing the problem. I've changed most of the names since this a public forum.
Code:
          if (guard) then
             MYARR(:,:,gi)=get_values( &
                  density=get_val(density,i),&
                  topdis=get_val(topdis,ele),&
                  botdis=get_val(botdis,ele),&
                  d=eget_val(d,ele))
          end if

In order to pass the results of the "get_val" function to the "get_values" function, the compiler must first create temporary arrays since "get_val" returns an array of REALs. At "-O2" the compiler determines that the creation of these temporary arrays need only be done once so hoists this code out of the DO loop.

In this case the size of the temporary array is determined by a value found in the derived type itself, for example: "density%mesh%shape%loc". Normally since density is invariant, the hoist should still be ok, even with the guarded if statement. However, density is actually a pointer and unless the guard condition is true, is unassociated. So when density gets dereferenced to get the size of the temporary array, a seg fault occurs.

This is a compiler bug and once I'm able to put together a smaller test case, I'll create a technical problem report.

As for a workaround, you'll need to compile this file at -O0. However, given your build process, you can also do something like the following:
Code:
          if (guard) then
        CALL KLUGE(density%mesh%shape%loc,topdis%mesh%shape%ngi,botdis%mesh%shape%ngi, d%mesh%shape%ngi)
             MYARR(:,:,gi)=get_values( &
                  density=get_val(density,i),&
                  topdis=get_val(topdis,ele),&
                  botdis=get_val(botdis,ele),&
                  d=eget_val(d,ele))
          end if

.... add to the bottom of the module
  SUBROUTINE KLUGE (A,B,C,D)
     INTEGER :: A,B,C,D
  END SUBROUTINE KLUGE


I'll keep you informed how progress goes on the this bug,. Hopefully it's not too hard to fix and we can have it working correctly by January's 8.0-3

- Mat
Back to top
View user's profile
yus



Joined: 06 Oct 2008
Posts: 18

PostPosted: Fri Dec 12, 2008 9:38 am    Post subject: Reply with quote

Hi Mat,

Many thanks for all your efforts in debugging such a sophisticated problem. That's really brilliant!

All the best.

yus
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    PGI User Forum Forum Index -> Debugging and Profiling All times are GMT - 7 Hours
Goto page Previous  1, 2, 3, 4, 5  Next
Page 3 of 5

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © phpBB Group