|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
wahorger
Joined: 13 Oct 2014 Posts: 1225 Location: Morrison, CO, USA
|
Posted: Fri Jan 22, 2021 12:02 am Post subject: Crash in library function (cannot duplicate) |
|
|
I am getting a crash in the library function LENG8$. I cannot duplicate in a small example.
It would appear that the function finds the trimmed length of a character string, returning the new trimmed length. In the routine in question it is used successfully over a dozen times in my assembly listing before failing here.
The assembler code (my code) is:
Quote: |
j = len_trim(feet_or_meters_scale(i_logmtr))
00003a1a(#20238,2524,693): NOP
00003a1b(#20238,2524,693): MOVSX_Q RBX,I_LOGMTR
00003a22(#35595,2525,693): IMUL_Q RBX,16_4
00003a2a(#20244,2526,693): LEA RCX,FEET_OR_METERS_SCALE:d[RBP+RBX]
00003a32(#20244,2527,693): MOV_Q RDX,16_4
00003a39(#20244,2528,693): CALL LENG8$
00003a3e(#20226,2529,693): MOV J,RAX
|
The data declarations are:
Quote: | character*16:: feet_or_meters_scale(0:2)
data feet_or_meters_scale/'UNDEFINED','feet/inch','meters/2.54 cm'/
integer:: i_logmtr
real*8:: log_scale
|
The error is:
Quote: |
Silverfrost 64-bit exception report on F:\cmasterf95\RELEASE\win64\C-MASTER.exe Thu Jan 21 15:50:24 2021
Access violation (c0000005) at address 7ff9bba20ae3
Within file CLEARWIN64.DLL
In LENG8$ at address 13
Within file C-MASTER.exe
in LOGPLT_WINDOWS in line 693, at address 3a3e
in LOGPLOT_WINDOWS in line 26, at address 143
Within file CLEARWIN64.DLL
In _set_mg_return_value at address 6B72
In CallWindowProcW at address 3BD
Within file USER32.DLL
In DispatchMessageW at address 1F2
In IsDialogMessageW at address 280
In IsDialogMessage at address 7C
In _register_message_interception at address 63E
Within file CLEARWIN64.DLL
In _yield_program_control at address 15A
RAX = 00000000ffffffff RBX = 0000000202020200 RCX = 00000002058935ff RDX = 0000000000000010
RBP = 0000000000400000 RSI = 000000000a626720 RDI = 0000000000000004 RSP = 000000000de99c58
R8 = 0000000013fd0e40 R9 = 0000000000000001 R10 = 0000000000008000 R11 = 000000000de99840
R12 = 000000000387360c R13 = 00000000038734c0 R14 = 00000000038734c4 R15 = 0000000003874da8
7ff9bba20ae3) movzx_b_q RAX,[RCX]
|
|
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8011 Location: Salford, UK
|
Posted: Fri Jan 22, 2021 9:21 am Post subject: |
|
|
Is there a check in the code to ensure that i_logmtr is in the range 0 to 2? |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1896
|
Posted: Fri Jan 22, 2021 11:16 am Post subject: |
|
|
Given the gaps in the information available, the following is definitely speculative.
I do not know which version of the CLEARWIN64 DLL Bill is using; so I will take the information from the one that I have with FTN95 8.70:
22.11.17.16, date 11/17/2020
Here are the relevant lines of machine code, starting with the pieces in Bill's traceback, and the code of LENG8$ in the DLL (disassembly generated using Microsoft's DUMPBIN):
Code: | 00003a1b(#20238,2524,693): MOVSX_Q RBX,I_LOGMTR
00003a22(#35595,2525,693): IMUL_Q RBX,16_4
00003a2a(#20244,2526,693): LEA RCX,FEET_OR_METERS_SCALE:d[RBP+RBX]
00003a32(#20244,2527,693): MOV_Q RDX,16_4
00003a39(#20244,2528,693): CALL LENG8$
00003a3e(#20226,2529,693): MOV J,RAX
...
LENG8$:
00000001800CF090: 48 83 FA 01 cmp rdx,1
00000001800CF094: 7D 03 jge 00000001800CF099
00000001800CF096: 33 C0 xor eax,eax
00000001800CF098: C3 ret
00000001800CF099: 48 8D 4C 11 FF lea rcx,[rcx+rdx-1]
00000001800CF09E: 48 85 D2 test rdx,rdx
00000001800CF0A1: 7E 12 jle 00000001800CF0B5
00000001800CF0A3: 0F B6 01 movzx eax,byte ptr [rcx] # CRASH LOCATION
00000001800CF0A6: 48 FF C9 dec rcx
00000001800CF0A9: 3C 20 cmp al,20h
00000001800CF0AB: 75 08 jne 00000001800CF0B5
00000001800CF0AD: 48 FF CA dec rdx
00000001800CF0B0: 48 85 D2 test rdx,rdx
00000001800CF0B3: 7F EE jg 00000001800CF0A3
00000001800CF0B5: 48 8B C2 mov rax,rdx
00000001800CF0B8: C3 ret
|
The value of register RBX (0000000202020200) strikes me as suspicious.
At the crash location, LENG8$+0x13, we can deduce from the preceding instructions that register RBX has the same contents as had been set in the "IMUL_Q RBX,16_4" instruction in Bill's caller. We can thus infer that the I_LOGMTR was equal to 0000000020202020, which is not at all reasonable, as Paul has already pointed out -- it should be in the range 0 to 2.
I suspect that something such as an array overrun caused a character string containing blanks (byte 0x20 repeated) to be written into the integer variable I_LOGMTR.
---
A separate point, for Paul's consideration: the machine instructions given by DUMPBIN and FTN95's traceback for the crash location disagree:
Dumpbin gives: 00000001800CF0A3: 0F B6 01 movzx eax,byte ptr [rcx]
whereas FTN95 gave: 7ff9bba20ae3) movzx_b_q RAX,[RCX]
The distinction could be of no significance unless a subsequent instruction used the upper (nameless) half of RAX, but I should prefer to see the correct instruction disassembled.
Last edited by mecej4 on Sat Jan 23, 2021 10:38 am; edited 2 times in total |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1225 Location: Morrison, CO, USA
|
Posted: Fri Jan 22, 2021 7:28 pm Post subject: |
|
|
Paul, yes, there is. An "IF" earlier sets it to 1 or 2. This is the only usage for i_logmtr, locally defined. I should probably turn on /BOUNDS_CHECK just in case, but this is in previously working, untouched code. In 32-bit mode, I do have /BOUNDS_CHECK and it does not error out. |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1225 Location: Morrison, CO, USA
|
Posted: Fri Jan 22, 2021 7:34 pm Post subject: |
|
|
Paul, yes, there is. An "IF" earlier sets it to 1 or 2. This is the only usage for i_logmtr, locally defined. I should probably turn on /BOUNDS_CHECK just in case, but this is in previously working, untouched code. In 32-bit mode, I do have /BOUNDS_CHECK and it does not cause an error to be detected.
mejec4, the address is within a DLL, loaded at some weird address. Unlike the MAP for 32-bit, the eventual loading address is not given in SLINK64. Your example may be perfectly correct, just not the same as mine because our code and DLL references are different.
The code I show is my code that leads to the LENG8$ call which has the error. I have no idea what is before/after the "offending" instruction. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8011 Location: Salford, UK
|
Posted: Fri Jan 22, 2021 7:47 pm Post subject: |
|
|
Another possibility is that something is over-writing the character array.
Try printing out the array just before the failure occurs. |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1225 Location: Morrison, CO, USA
|
Posted: Fri Jan 22, 2021 8:20 pm Post subject: |
|
|
I had thought that /zeroise would zero memory, but no. There was an escapement in a secondary variable was not zero on entry, causing the i_logmtr to NOT be initialized appropriately. On to the next error.
Learned something new, and will apply caution in the future when similar problems arise!
Thanks, mecej4 and Paul. |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1225 Location: Morrison, CO, USA
|
Posted: Fri Jan 22, 2021 11:54 pm Post subject: |
|
|
So, cautiously, I approached the debugging of the module and found an interesting (unexpected) result: That is - every local variable I looked at contained the same pattern of (hex) 20202020. Specifically, I had initialized each of these variables with a DATA statement, or a specific assignment when the variable was declared (i.e. INTEGER:: ABCD=0) I printed these locals as the module was entered before any processing took place.
In addition, a ganged pair of radio buttons is (in 64-bit) no longer paired. They operate as separate buttons. Also, they initialized to (hex) 20202020 before they are used.
A local variable that is set via assignment statement later on in the module to 0.0 on entry is displayed as 6.0135E-154 (also= (hex) 2020202020202020).
Compiled in 32-bit mode as /CHECKMATE and as /RELEASE with /BOUNDS_CHECK turned on, none of these problems occur.
I am not able to duplicate none of these (the filling of memory with 20202020, nor the ganged radio button, nor the floating point number) in a small sample program.
Some guidance to find what is causing this would be helpful. DBG64? |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1896
|
Posted: Sat Jan 23, 2021 12:41 am Post subject: |
|
|
Do you have one or more character variables declared with len = a large number, inadvertently set equal to blank?
Does your code pass such a variable to a third party library routine which sets the variable to blank?
When you first see a variable with its bytes set to 0x20, is that the first time that execution of the current subprogram occurs, or otherwise? |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1225 Location: Morrison, CO, USA
|
Posted: Sat Jan 23, 2021 2:18 am Post subject: |
|
|
Within this routine nor in its caller, no big character variables being initialized.
The real*8 is getting changed back on the second time through, but I think the constant 0.0 is getting hammered, so cannot affect that.
The radio button values are not getting hammered again. But the ganging is still not working. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1896
|
Posted: Sat Jan 23, 2021 10:35 am Post subject: |
|
|
Bill, if you just tell us the version number of your CLEARWIN64.DLL, and that version was not a private version, we could easily settle any doubts regarding the library function LENG8$, which is called to find len_trim(char var).
I expect the machine code of that function to be identical in your DLL version to the one that I showed. The function is only 16 instructions long, takes two arguments in RCX and RDX, and returns the result in RAX. It does not change any of the other registers. Nothing can go wrong there.
Therefore, the errors must occur earlier in the call chain, in portions of your code that we know nothing about. With such tough errors, I would not completely trust a symbolic debugger.
You mentioned "radio buttons not getting hammered". I hope that you appreciate that the phrase has no meaning (to me, anyway) within the context of the information that you have disclosed in this thread. |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1225 Location: Morrison, CO, USA
|
Posted: Sat Jan 23, 2021 3:05 pm Post subject: |
|
|
mejec4, thanks for the response.
Yesterday, my post spoke of memory being filled with spaces, filled over data for which I had data statements. I uncovered also that included the floating point constant of 0.0. So the code in leng8$ is no longer in question. Since it loaded a non-valid number for the index to the array, having it crash was not unexpected. The variable was not set properly because the floating point constant of 0.0 was no longer exactly zero, this prevented a portion of my initialization code from running, leaving a key variable (i_logmtr) set to all spaces (or 538976288). Even though it had been also been initialized to zero in a data statement. The question remains of "Why? Why is memory that holds my variables AND constants getting filled with spaces?". The suggestions to look at initialization statements possibly "gone awry" was good. Big (wide) character arrays getting initialized (there are none). I don't use the char_fill@() function in this particular program at all, relying on program assignment statements to initialize bulk arrays. So where to look for the program going "rouge".
I first took out of the build any /ZEROISE, just in case that was the culprit. This had no effect.
And, yesterday, I put in a little PRINT statement on a couple of variables to show the state of the local variables on initial entry and immediately before first use. The print showed that these locals had been set to spaces. Integers that should be zero or one (from the DATA statements) are displaying as 538976288. REAL*8's are displayed as 6.0135E-154. These real*8's had been initialized by a program statement, setting the value explicitly to 0.0d0.
This morning (23 Jan), I placed in the module a small bit of code. The code would allow me to call this routine BEFORE any of my other code ran, just in case I have something (programmatically) that went bonkers. It can only be run once, it prints, and it immediately returns. Stated another way, before any of my "standard" code that initializes any other variables, opens files, clears character arrays; before any of that executes, I call the routine and print the values of a few variables that should have pre-defined values based on their data statements.
In a perfect world, the numbers that are displayed should match their initialization (data) statement values. That was not what is observed: the values are not what was expected; their values are set to all spaces and this is reflected in the numeric values displayed by the print.
I hope that clears up any confusion that I may have left yesterday.
And, the confusion about why this is happening is still there. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1896
|
Posted: Sat Jan 23, 2021 3:13 pm Post subject: |
|
|
Thanks for the details. The bugs are still present, then? |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1225 Location: Morrison, CO, USA
|
Posted: Sat Jan 23, 2021 4:10 pm Post subject: |
|
|
Oh, yeah. It is still there. I thought it might be a BLOCK DATA issue, so I went through all my INS files looking for problems. Can't find any, and not getting any compiler errors about too few or too many initializers. So, flummoxed.
Too bad I cannot come up with a smaller example for Paul, et. al. Since 64-bit was a goal for me, not a requirement, this and a few other stumbling blocks have now slowed my adoption.
As an aside, I have been able to find and fix inconsistencies in my code for 64-bit, namely winio@() arguments that were declared as INTEGER(7) incorrectly, or as INTEGER(3) and should have been INTEGER(7).
Even with this particular problem, I was able to make some progress to that ultimate end. I also learned a great deal about DLL's and third party compilers in the process. So, all in all, the time I spent was productive, albeit not to the exact end I had originally envisioned. |
|
Back to top |
|
|
Robert
Joined: 29 Nov 2006 Posts: 450 Location: Manchester
|
Posted: Sat Jan 23, 2021 4:57 pm Post subject: Re: |
|
|
mecej4 wrote: |
The value of register RBX (0000000202020200) strikes me as suspicious.
At the crash location, LENG8$+0x13, we can deduce from the preceding instructions that register RBX has the same contents as had been set in the "IMUL_Q RBX,16_4" instruction in Bill's caller. We can thus infer that the I_LOGMTR was equal to 0000000020202020, which is not at all reasonable, as Paul has already pointed out -- it should be in the range 0 to 2.
I suspect that something such as an array overrun caused a character string containing blanks (byte 0x20 repeated) to be written into the integer variable I_LOGMTR.
|
It isn't byte 0x20 repeated, it is 0x02 repeated.
mecej4 wrote: |
A separate point, for Paul's consideration: the machine instructions given by DUMPBIN and FTN95's traceback for the crash location disagree:
Dumpbin gives: 00000001800CF0A3: 0F B6 01 movzx eax,byte ptr [rcx]
whereas FTN95 gave: 7ff9bba20ae3) movzx_b_q RAX,[RCX]
The distinction could be of no significance unless a subsequent instruction used the upper (nameless) half of RAX, but I should prefer to see the correct instruction disassembled. |
I suspect they decode to the same thing, moving a byte from [RCX] to al, with the remaining length of string in RDX. |
|
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, 2005 phpBB Group
|