TD-23629: New error messagebox: Internal memory has become invalid...

General discussion forum about all things Team Developer 7.x
Dave Rabelink
Founder/Site Admin
Founder/Site Admin
Netherlands
Posts: 275
Joined: 24 Feb 2017, 09:12
Location: Gouda, The Netherlands

TD-23629: New error messagebox: Internal memory has become invalid...

Post by Dave Rabelink » 03 Jul 2017, 05:52

Based on the thread started on OpenText forum having title: "TD 7.0.2 General instability (Win32)"

https://knowledge.opentext.com/knowledg ... ncontainer

I have replied about a new TD error messagebox which pops up in certain cases.

TD7_InternalMemoryError.png

The error I have seen a few times.
In the case of the screenshot, when running from exe, it shows this message at some point and the application closes.

But when running in IDE, the outline jumps to the location where the error is thrown. I have marked the line in yellow.
What was the cause in this particular case: the dll which was called was not registered on the system. It is a ActiveX/COM component.

So I ran the same application, but still in TD63 which should also fail at the same point. And yes, it does but without the error message.
The application freezes and just stops (a crash).

So it seems that here, the error box is shown on a general error situation which is not new, existed before, but now is catched and will popup this message.
Nothing has changed to the dll, the code is exactly the same, except now running using TD7 runtime.

So my question to Gupta devs is this: what does this error exactly mean? In what situations does it occur?
The error explains one example, but clearly the error box pops up in the mentioned situation also, which has nothing to do with "new" object.

So what situations are there? The error is too vague for me to pinpoint the cause.
I had to inspect the line in the code and see that the issue was unregistered dll. Which is an error, but now in TD7 gives me this error box.

A clear overview from Gupta devs could help out where this errorbox will be thrown.

I like an error messagebox better than a crash without notice. But then the error must be informative so we can take the appropriate action.

So for others seeing this error, try to reproduce it in the IDE and maybe (like in my case here) the IDE outline will show the location where the error was thrown and give you a hint on the issue.
You do not have the required permissions to view the files attached to this post.
Regards,
Dave Rabelink

Image
Articles and information on Team Developer Tips & Tricks Wiki
Download samples, documents and resources from TD Sample Vault
Videos on TDWiki YouTube Channel

Dave Rabelink
Founder/Site Admin
Founder/Site Admin
Netherlands
Posts: 275
Joined: 24 Feb 2017, 09:12
Location: Gouda, The Netherlands

Re: New error messagebox: Internal memory has become invalid...

Post by Dave Rabelink » 05 Jul 2017, 08:07

To get the needed info on this, I created a ticket to request it from the devs.

Ticket # 3073394:
Info request on new error message box: Internal memory has become invalid...

TD-23629:
"Internal memory has become invalid..." what is the condition(s) that triggers this error in the TD runtime.
Regards,
Dave Rabelink

Image
Articles and information on Team Developer Tips & Tricks Wiki
Download samples, documents and resources from TD Sample Vault
Videos on TDWiki YouTube Channel

Dave Rabelink
Founder/Site Admin
Founder/Site Admin
Netherlands
Posts: 275
Joined: 24 Feb 2017, 09:12
Location: Gouda, The Netherlands

Re: New error messagebox: Internal memory has become invalid...

Post by Dave Rabelink » 10 Jul 2017, 05:46

This is a response from Gupta in the OpenText thread:
Regarding the new error message seen in 7.0 related to “Invalid memory”.
Unfortunately that error text needs to be re-worded to be more generic. We are now trapping exceptions in our message pump for the application, and reporting this error.
In the past we let these exceptions go back to the OS which could result in a crash.
This error text was introduced in response to some bad user code that was causing memory issues, but actually we can be trapping other errors as well.
So, based on this (not an 'official' response in the ticket) it seems that this error could popup in TD7 at places where older TD versions would crash without any error message.
As indicated, then the error message text is confusing and should be more generic. At least should not give an example, but speak more generally about 'any possible memory issue'.
Regards,
Dave Rabelink

Image
Articles and information on Team Developer Tips & Tricks Wiki
Download samples, documents and resources from TD Sample Vault
Videos on TDWiki YouTube Channel

mlueling
Germany
Posts: 1
Joined: 03 Jul 2017, 11:57
Location: Wetter Germany

Re: New error messagebox: Internal memory has become invalid...

Post by mlueling » 10 Jul 2017, 13:21

I did some research and I think I found a way to reproduce the invalid memory message.

The sample consists of a Program.apt, a Lib.apl and a DynaLib.apt. If you run the the DynaLib directly, everything works fine. If you call the exported Dynalib Function from Program.apt (.exe) you get the error message.
It seems that it is not possible to get a reference to an instance of a derived class accross DynaLib boundaries under some circumstances.

Furthermore I found that it is not possible to export overloaded functions. I do not know if this is a known limitation or a bug. This is also covered in the sample.

You can download the sample https://www.dropbox.com/s/73hc8viubj8k3 ... d.zip?dl=0. Use TD 7.0.2 in order to reproduce the problem.

We will create an opentext support ticket for this.

BR,
Matthias Lüling

Dave Rabelink
Founder/Site Admin
Founder/Site Admin
Netherlands
Posts: 275
Joined: 24 Feb 2017, 09:12
Location: Gouda, The Netherlands

Re: New error messagebox: Internal memory has become invalid...

Post by Dave Rabelink » 12 Jul 2017, 05:59

mlueling wrote:
10 Jul 2017, 13:21
It seems that it is not possible to get a reference to an instance of a derived class accross DynaLib boundaries under some circumstances.
Yes. That is a "feature" which at some time is not supported anymore by TD starting from a certain version.
I know this worked in TD 1.5, but at least TD 5.1 and up will crash your application (without error message).
Now on TD 7, this new error message is given instead. So the cause of the crash is not introduced in TD 7.
Furthermore I found that it is not possible to export overloaded functions. I do not know if this is a known limitation or a bug. This is also covered in the sample.
Dynalibs are probably forgotten to support function overloading.
But my guess is that it is a limitation due to the fact that you could have this situation:

DynalibA exports MyFunction( param1 )
DynalibB exports MyFunction( param1, param2 )

When including both dynalibs, the overloading is now spread over 2 dynalibs.
I think this could be a complex situation for Gupta to support, but maybe it could be implemented.


As for the sample on dropbox. I converted that one to TD 6.3 so you can see it actually crashes TD while the same application will give the new error messagebox.
The TD 6.3 sample is attached here:

InternalMemoryHasBecomeInvalid_TD63.zip
You do not have the required permissions to view the files attached to this post.
Regards,
Dave Rabelink

Image
Articles and information on Team Developer Tips & Tricks Wiki
Download samples, documents and resources from TD Sample Vault
Videos on TDWiki YouTube Channel

Dave Rabelink
Founder/Site Admin
Founder/Site Admin
Netherlands
Posts: 275
Joined: 24 Feb 2017, 09:12
Location: Gouda, The Netherlands

Re: TD-23629: New error messagebox: Internal memory has become invalid...

Post by Dave Rabelink » 12 Jul 2017, 08:27

A comment on your implementation.

I would really recommend not to use any class structures using inheritance in Dynalib exports.
I have seen many issues with this. The problem is the initial design of the way dynalibs handles classes.
As classes can not be exported from a dynalib, objects from a class passed between the dynalib export boundaries are only based on the internal structure of the memory of the object.
So TD runtime does not do any type checking. It only "assumes" at runtime that the object memory structure passed between the boundary is the same.

This can lead into problems when you change the class structure in the apd (or the calling side), for instance remove instance variables or add variables not in the end but at the start of the variable section, but do not change the class on the other side. That can happen when rebuilding the apd but not rebuilding the executable or visa versa.
Then an object in the apd has a different memory structure compared to the executable, at runtime this can lead to crashes because TD handles an object with different memory structure.

These issues only appear at runtime and not at compile time.

The best way to approach Dynalib exports is that it is a real interface. And the interface should never map 1:1 to the internal structure inside the dynalib.

When you are using dynalibs to create modular application, where you split functionality into physical separate parts, the interface should only change when the data/functionality which is passed between modules is changed.
When the internal domain classed inside the dynalib changes, but it does not change the data/functionality which is used outside the dynalib, the interface should not change.
But having a 1:1 mapping it actually does. In TD you MUST to recompile all executables/dynalibs which are using the changed dynalib even when the shared data structure/functionality of the dynalib did not change.
And forgetting this, will lead to unstable applications which are only encountered when using the running application.

To make your life easier it is best to limit the class hierarchy of objects passing dynalib boundaries to 1. A simple interface class.
And if you really need inheritance, make sure the interface is completely disconnected from the dynalib internals. This can be done not by returning objects instance references, but make a copy of the data.

EXE -> copy exe object data to interface object -> APD -> copy interface object to local structure object
(visa versa)

I think the best way to envision how APD's should work is like using a web-service.
If you pass data to a web-service, you actually make an interface object having data which is a copy from the "real" data. The "real" data structure is your local domain which could be completely different compared to the interface.
Then the web-service is called. There at that side, the data is copied out of the interface and fed to its domain.
When getting data back from a web-service you never get an object from the web-service domain, but a copy. You will never get a reference to an internal object inside the web-server.

When looking at dynalibs, where it is possible to pass references through the boundaries, you must be really sure the reference is exactly what is expected.

To me, creating dynalib boundaries having interface objects only used for the interface will prevent these kind of issues and also will ensure you that when dynalib internals change and no change is done to the interface, you only need to rebuild the dynalib and keep the rest untouched. In that case you only deploy one dynalib (having the changes) into an existing deployment which will keep working.

A side note, but that's more like a personal taste: never return objects as return value.
This will force you to check the returned object for validity before using it, making reading the code harder and even more important, forgetting the checks will cause TD runtime errors.

This

Code: Select all

If GetSomeObject( uMyObject )
	Call uMyObject.Display( )
Else
	Call Error( )
compared to

Code: Select all

Set uMyObject = GetSomeObject(  )
If SalObjIsNull( uMyObject )
	Call Error( )
Else
	Call uMyObject.Display( )
Forget the ObjIsNull check and the application surely will end with an TD runtime error.
Regards,
Dave Rabelink

Image
Articles and information on Team Developer Tips & Tricks Wiki
Download samples, documents and resources from TD Sample Vault
Videos on TDWiki YouTube Channel

thomas.uttendorfer
Site Admin
Site Admin
Germany
Posts: 34
Joined: 05 Mar 2017, 17:19
Location: Munich Germany

Re: TD-23629: New error messagebox: Internal memory has become invalid...

Post by thomas.uttendorfer » 13 Jul 2017, 06:45

Hi,
another issue with passing functional classes from a dynalib:
If there is a late bound call in that class and you call it from outside
then your program always will crash then.
Anyway how clean you built your files.

Regards Thomas
Thomas Uttendorfer
[ frevel & fey ] Software-System GmbH
https://thomasuttendorfer.wordpress.com/

Return to “General Discussion”

Who is online

Users browsing this forum: Ccbot [Crawler] and 0 guests