![forums.silverfrost.com Forum Index](templates/subSilver/images/logo_phpBB.gif) |
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Sat Jan 29, 2022 4:11 pm Post subject: |
|
|
Paul, thanks for confirming my analysis. I did a similar analysis of the 32-bit EXE for the same test program, and found that it behaves a bit differently. Instead of calling a library function such as LENG8$, it calculates the trimmed length of the string in line. What gets clobbered in the 32-bit EXE is not the string length parameter (the constant 16), but the constant 2, which is later used in a call to WSF1 (Fortran I/O routine ?), and other variables that follow that 2 in memory.
I have seen other compilers put constants such as the 16 or the 2 that we saw in this program into a read-only data segment such as .rdata. This approach would cause an access violation earlier in the code and that would make it easier to catch the bug in user code.
As you said, catching the bug in LENG8$ is better than nothing, but users tend to conclude from the stack trace that the bug is in the library itself and may expect that it is for the compiler/library developers to fix it.
Last edited by mecej4 on Sat Jan 29, 2022 4:53 pm; edited 1 time in total |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Sat Jan 29, 2022 4:49 pm Post subject: Can PARAMETERs be protected from being clobbered |
|
|
Some details are given below about how to probe this error, which may help in debugging Wahorger's program, and other large programs that cannot be compiled with /check or /undef for some good reason, and memory corruption is suspected.
In an attempt to see how the source code could be modified to avoid subscript errors from clobbering constants, I changed the test program as follows:
Code: | ! http://forums.silverfrost.com/viewtopic.php?p=32570#32570
program wahbug
implicit none
integer, parameter :: SLEN=16 ! gets clobbered by writing to fms(3)
character(len=SLEN) :: fms(2)
data fms/'feet/inch','meters/2.54 cm'/
integer:: i_logmtr, ls
integer*8 :: l8
!
i_logmtr = 2
ls = 3
fms(ls) = ' ' !deliberately exceed upper bound of array
l8 = len_trim(fms(i_logmtr))
print *,l8
end program |
Compile with /64 /full_debug and link. Running the program gives an access violation inside LENG8$. Running the program within SDBG64 causes "access violation reading address FFFFFFFFFFFFFFFF" inside LENG8$. Neither message helps in understanding what caused the access violation.
To understand what happened, restart the program in SDBG64, set a breakpoint on line-13, "l8 = len_trim(fms(i_logmtr))", and run up to the breakpoint. Press F11. Open the registers window.
Step forward two machine instructions, stopping at "imul_q R15,..."
Observe that R15 contains the value 1.
Step forward one instruction. But for the bug, we should have seen R15 change to Z'00000000000000010', i.e,. the string length, 16. However, that "constant" has been clobbered, and we see Z'2020202020202020'. Observing this is a good hint that the string with 16 blanks has been written over the (supposedly constant) parameter SLEN. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
|
|
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, 2005 phpBB Group
|