forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Crash in library function (cannot duplicate)
Goto page Previous  1, 2, 3
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit
View previous topic :: View next topic  
Author Message
mecej4



Joined: 31 Oct 2006
Posts: 1884

PostPosted: Sat Jan 29, 2022 4:11 pm    Post subject: Reply with quote

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
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1884

PostPosted: Sat Jan 29, 2022 4:49 pm    Post subject: Can PARAMETERs be protected from being clobbered Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit All times are GMT + 1 Hour
Goto page Previous  1, 2, 3
Page 3 of 3

 
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 © 2001, 2005 phpBB Group