[Window Title]
Error
[Content]
Project TexWorkshop raised exception class 'External: ?'.
At address 72D1117A
[OK]
Try 3.2.0 because it has structured exception handling as default for win32.
Can you test as per my suggestion and Marco's remark?
Otherwise I need full sources that replicate the issue.
Can you test as per my suggestion and Marco's remark?
Otherwise I need full sources that replicate the issue.
You need only the dll i attached in zip file and the example code i posted - compile with win32 and it will crash on compress line.
Regarding SEH, it could be - i would need to custom compile the compile, can someone first check if SEH is the issue?
I don't think this is SEH fault tho - there is no exception at all under delphi.
Unhandled exception at 0x6D0C4815 (squish.dll) in TexWorkshop.exe: 0xC00002B5: Multiple floating point traps (parameters: 0x00000000, 0x00001921).
Delphi doesn't know anything else, so that is why that is important.
I don't think this is SEH fault tho - there is no exception at all under delphi.
i ran the tool in visual studio and got a better exception message:It's nice to see that alternate way of debugging is used and useful :)
i ran the tool in visual studio and got a better exception message:It's nice to see that alternate way of debugging is used and useful :)
That has nothing to do with MS compilers. It would be similar with GCC: C/C++ programs normally don't expect floating point exceptions (floating point exceptions are not part of the standard). FPC (and Delphi) by default set the exception mask to something different, so it is rather common that one has to change the exception mask when working with such libraries.Delphi doesn't know anything else, so that is why that is important.
I don't think this is SEH fault tho - there is no exception at all under delphi.
And yes, specifically ms compilers mess with the float settings.(and are not in any way compliant to standards)
Glad it is now solved.
It is actually that the Borland 32 bit compilers - including C++ builder - adhere to the IEEE 754 described standards for floating point handling, whereas msvc does not adhere. if other compilers follow msvc they are also not standards compliant.That has nothing to do with MS compilers. It would be similar with GCC: C/C++ programs normally don't expect floating point exceptions (floating point exceptions are not part of the standard). FPC (and Delphi) by default set the exception mask to something different, so it is rather common that one has to change the exception mask when working with such libraries.Delphi doesn't know anything else, so that is why that is important.
I don't think this is SEH fault tho - there is no exception at all under delphi.
And yes, specifically ms compilers mess with the float settings.(and are not in any way compliant to standards)
Glad it is now solved.
Is it this one?It is actually that the Borland 32 bit compilers - including C++ builder - adhere to the IEEE 754 described standards for floating point handling, whereas msvc does not adhere. if other compilers follow msvc they are also not standards compliant.That has nothing to do with MS compilers. It would be similar with GCC: C/C++ programs normally don't expect floating point exceptions (floating point exceptions are not part of the standard). FPC (and Delphi) by default set the exception mask to something different, so it is rather common that one has to change the exception mask when working with such libraries.Delphi doesn't know anything else, so that is why that is important.
I don't think this is SEH fault tho - there is no exception at all under delphi.
And yes, specifically ms compilers mess with the float settings.(and are not in any way compliant to standards)
Glad it is now solved.
But indeed the issue exists for many years and up until now I only have to solve it for ms compiled code, or recompile for C++ builder (which I do not recommend for 32 bit since it optimizes not as good as msvc.)
Danny Thorpe wrote a lengthy blog about this many moons ago. I'll see if I can find it.
Could this be a good example for a bug report / improvement?I agree that there is definitely room for the message to be improved. Personally, I think it is worth reporting. Reporting it will make it visible and give the FPC developers the opportunity to decide if they want to do something about it.
Different compilers compile different code and to different addresses, so that is not a bug by itself.
Could this be a good example for a bug report / improvement?I agree that there is definitely room for the message to be improved. Personally, I think it is worth reporting. Reporting it will make it visible and give the FPC developers the opportunity to decide if they want to do something about it.
It seems that, in the future, GDB will be deprecated and abandoned in favor of fpDebug.Different compilers compile different code and to different addresses, so that is not a bug by itself.This is not a matter of code, but debugging - debugger in visual studio made a more correct error message than gdb + lazarus debugging combo, debugged were identical binaries.