Before I go into my response. Most of it is only valuable if either
- you are fine spending some time in the hope getting valgrind to work
- you want to pursuit this on the (probably rather very low) off chance that there is a hidden bug in your code (or - even less likely - in fpc 3.2.3 itself)
Otherwise, you may be better off investing time in one off the other tools.
1) Is the address always the same?
2) Have you tried to load it in any debugger and find out what code (if any) is at that location?
3) And that it is at the begin of an asm instruction?
4) I.e. if you find the start of the function and disassemble, it has a statement starting at this address?
1) If you mean memory address I have no idea, I don't mess with memory address allocation.
2) This I have no idea on how to do or what it means, sorry
3) I have no asm code in my app
4) I don't know
1)
Your image shows an address: 40ee8c
I wonder, if there is another. Google indicates there should be (before the text from your screenshot)
" valgrind: Unrecognised instruction at address: xxxxx"
2)
If you use the same exe (no recompile) running in the debugger and you pause it, then you can enter that address in the asm view and see where it points too.
Alternatively you can copy the callstack from the image, open View > Leaks and traces => paste it, and press "Resolve" and find the executable of your project (the same that threw the error, no recompile)
3)
I mean the asm generated by the compiler (as machine code / not readable asm / but then disassembled)
if you have that function, then you disassemble (using the debugger) from the begin of that function.
If disassemble from the begin of the function then 40ee8c may be at the begin of one of the statements shown (good).
Or there may be a statement at 40ee8B (or before) and the next statement is after the wanted address (bad / 99.99% likely something wrong in your executable)
4)
if there is a statement at this address, then it will have a name (e.g. "lea"). That name can be googled with the term "valgrind".
If it is an issues in valgrind, other may have had it too.
I understand it passed all your tests. And I will assume at this point that your tests are extensive, and have excellent coverage and all.
I would still keep open to the idea that there might be a bug in there. Even if it may not be likely.
I have seen very elusive bugs.
On the other hand, I don't know how up to date valgrind is on the Ubuntu 20. Since it is LTS, I would expect them to keep at least bugfixes for installed software...
There are release notes here
https://valgrind.org/docs/manual/dist.news.html (and the latest release is very new, matching the kind of error you got)
Search for "unhandled". There are quite a few fixed in the latest release.
If you get the asm instruction (and hex bytes) from the disassembler, then you can compare. (assuming that the given address is actually the one at which valgrind stopped)
Last not least, if valgrind does not understand a valid instruction, and if it either isn't fixed or you can't update, then you could try to get FPC to avoid that instruction.
For example (from the fixes in the release notes) " vmovq %xmm9,%xmm1", you may be able to disable fpu or sse usage or something.
Or compile with -Cp____ / Get the list of names with: fpc -ic
Recent
