Jump to content
vhanla

Delphi Rio 10.3.3 crashes on big multiline constants.

Recommended Posts

https://quality.embarcadero.com/browse/RSP-27564

 

I reported that issue, hopefully you can help me to avoid this issue.

 

I'm including constants of large strings as it will be embedded in the executable, each constant has many characters, because they contain compressed javascript libraries, previous Delphi versions didn't have any issue with these, maybe is because of the recent changes to the variable declaration, I'm not sure, but this one just hangs and closes without any warning.

 

Here I include a demo that crashes after opening it.

CrashIDE.zip

Edited by vhanla

Share this post


Link to post

As I noticed, in one constant, if it surpasses 1255 lines, that error happens, maybe it is different on other machines.

Share this post


Link to post

Maybe they reduced the maximum lines for constants in multiline appends, so the current workaround was to reduce them by splitting into another constant, using another text editor of course.

Share this post


Link to post

Thank you, that would be ideal, though I just wanted to avoid that.

So it seems that a registry tweak fixes that.
 

Quote

The IDE uses the following value as each parser-thread's reserved-stack. (The max size of the thread's stack.)

Key Name: HKEY_CURRENT_USER\Software\Embarcadero\BDS\20.0\Globals
Name: ReservedStackSize
Type: REG_DWORD
The value entered is used as the reserved-stack-size for each parser thread. If the registry key doesn't exist, the default value is $600000 (6M) bytes.

That fixed it.


 


https://quality.embarcadero.com/browse/RSP-22274

Share this post


Link to post

Since nothing is as volatile as a web thing, consider keeping that in a text file and load it once your application has started. This gives you the added benefit of being able to change this HTML-File without the need for an update.

Share this post


Link to post

The process of making a change to the example file in the QP case would be painstaking and error-prone.

I'd compress the original file, add it as a resource, and decompress in memory.

No worries about encoding, quoting, and such.

 

Share this post


Link to post

Certainly I'd do all the work to prepare the resource from the source file as a pre build step, properly automated. 

 

I'd question the choice to use compression. What is the point of that? 

Share this post


Link to post
Just now, David Heffernan said:

Certainly I'd do all the work to prepare the resource from the source file as a pre build step, properly automated. 

 

I'd question the choice to use compression. What is the point of that? 

Integrity control. 

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×