RAD Studio 11.1 released

2 Likes

Aaaaand we have yet another release of delphi that (for my projects at least) is completely broken. I cannot debug at all in debug mode, so might as well use notepad.


FinalBuilder9.exe - Entry Point Not Found

The procedure entry point @System@Net@Mime@TMimĂŚTypes@$bcdtr$qqrv could not be located in the dynamic link library I:\FBAT_HG9\Output\FB9\FinalBuilder9.exe.

OK

But I can run under the debugger in Release mode - but can’t actually debug anything. Yes, they know about this issue, but they chose to release anyway.

There are other major issues that I reported that I cannot tell are fixed due to this issue.

Not sure where I go from here… I guess forget about High dpi etc and port the branch back to XE7 :unamused:

My subscription expires in a few days… having wasted money on so many versions of delphi that were not useable, I have to wonder if I am insane to renew (and hope that 11.2 or 12 or whatever the next release is will fix this).

I hope you all have better luck.

Edit : Btw, I have done a huge amount of diagnostic work on this issue, and it appears to be memory corruption in the IDE. The project runs fine in release mode or outside of the IDE. It’s loading the files from the correct place (confirned using procmon etc). The entry point that it complains about changes randomly between bds runs - I just restart and try again and it gives a different error, e.g The procedure entry point @Rzspnedt@TRzÌpinEdit@CheckValue$qqrxg could not be located in the dynamic link library I:\FBAT_HG9\Output\FB9\FinalBuilder9.exe.

I made some progress on this issue and posted an issue - turns out that enabling Linking\Debug info is what triggers the error - I haven’t been able to reproduce the error in a sample project so I guess the size of the project or project group might be a factor.

I know it’s a terrible idea … but could you ever imagine (maybe as a last resort) finding a way to use gdb as a debugger ?

gdb on linux is apparently very capable (eg step forward / backward through code)

Yep it’s a terrible idea :smirk: - even embarcadero is moving away from gdb for the non windows platforms - using lldb instead - but even then they need to modify it to understand delphi debug info etc.

FWIW - with help of Bruneau Babet at embarcadero (one of the few borland era guys left there) we have narrowed it down to being caused by the debugger inserting breakpoints into the imports table - the clue was the ĂŚ character in the entry point - the hex value for that char is $00CC which is just happens to be the opcode for INT 3 - otherwise known as a breakpoint.

2 Likes

Well done :slight_smile:

Is this an issue with the IDE, or a bad project config (since it contains the breakpoint information in it)?

Not sure yet… new breakpoints work fine, just these two old ones.

FWIW, this is what I have in the dsk, the first two breakpoints are the problem ones.

[Breakpoints]
Count=4
Breakpoint0='I:\FBAT_HG9\Src\IDE\VSoft.IDE.VariableHintWindow.pas',528,'',0,1,'',1,0,0,'',1,'','','',0,''
Breakpoint1='I:\FBAT_HG9\Src\IDE\VSoft.IDE.VariableHintWindow.pas',397,'',0,1,'',1,0,0,'',1,'','','',0,''
Breakpoint2='I:\FBAT_HG9\Src\IDE\VSoft.IDE.Startup.pas',450,'',0,1,'',1,0,0,'',1,'','','',0,''
Breakpoint3='I:\FBAT_HG9\Src\IDE\VSoft.IDE.Startup.pas',451,'',0,1,'',1,0,0,'',1,'','','',0,''