|
| View previous topic :: View next topic |
| Author |
Message |
yus
Joined: 06 Oct 2008 Posts: 18
|
Posted: Tue Dec 09, 2008 7:52 am Post subject: |
|
|
Hi Mat,
Is there any luck to track down the possible cause of the segmentation fault in my submitted code?
Cheers. |
|
| Back to top |
|
 |
mkcolg
Joined: 30 Jun 2004 Posts: 5001 Location: The Portland Group Inc.
|
Posted: Tue Dec 09, 2008 9:56 am Post subject: |
|
|
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 |
|
 |
yus
Joined: 06 Oct 2008 Posts: 18
|
Posted: Tue Dec 09, 2008 10:17 am Post subject: |
|
|
| Thanks Mat, you rock! I will check these points. |
|
| Back to top |
|
 |
mkcolg
Joined: 30 Jun 2004 Posts: 5001 Location: The Portland Group Inc.
|
Posted: Thu Dec 11, 2008 12:13 pm Post subject: |
|
|
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 |
|
 |
yus
Joined: 06 Oct 2008 Posts: 18
|
Posted: Fri Dec 12, 2008 9:38 am Post subject: |
|
|
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 |
|
 |
|
|
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 © 2001, 2002 phpBB Group
|