TD-4604: TD51 & TD42 Must read : comments DO have effect at runtime

[Dave Rabelink]

Before I will explain what I have found, I first would like to give the conclusions of this bugreport :

- Commented text in source DOES have a negative effect on runtime stability
- Build applications straight from an APT which includes libraries results in a less stable runtime compared to builds straight out of a merged file
- TD creates hidden data blocks in the source which in some cases results in instable runtime

This bug report concerns TD51 SP2 and TD42, proven to be occurring using dynalibs.
Though this is reproducible using dynalibs I’m not sure it is not occurring in executables also. I could not get a repro-case showing executable issues for it but some older bug reports posted in the forums makes me suspicious it is a overall TD issue.
The sources involved are in TEXT format (no binary).

Symptoms
Some time now, after porting our main application from TD31, I got more and more reports from production environments users have crashes. Mostly, when users control the application using the keyboard. Due to the size of the application and the vague reports I could not get a clear procedure to reproduce the issue.
Happily a systems administrator could give me a few steps to get the application crashing on every case. On a certain window, when the user presses the ENTER key, the application just crashes. It vanishes from the system with or without a memory read/write error.

Obviously I started looking at the code in the window, but could not find any clue. There were no accelerators set (like a def button) or other code which would be executed when pressing ENTER. It did not matter where the focus was, on a datafield or a button, just the ENTER key would crash the application.

So I started stripping the window code. I deleted everything (all GUI objects, all functions, all parameters etc etc) resulting in a completely empty window. But the application still crashed by hitting ENTER.

Next try was to copy/paste the empty window and comment the ‘faulty’ one.
I kept the commented window in the source. Surprisingly, the crash was gone !
Initially I thought it was an outline corruption and a copy/paste solved it.
I deleted the commented ‘Faulty’ window and tested again. It was shocking to see the crash was back again !!!

After days of investigating I discovered that the problem was not the window itself, just by adding comments or uncommenting other parts of the source, the crash would appear or disappear suddenly. The commented-uncommented source was not even executed, it was just inside the same source file.

Even completely recreating the source file and creating a fresh new window, the crash would appear or disappear. Colleagues of mine did help in investigating on their own; I thought I was becoming crazy at one point. I must have overlooked something.
But they also concluded the issue was bizarre and was never seen before.
One strange thing we have seen which is reported in the forums in the past was that accelerators are fired twice !
The faulty window, when having an accelerator defined would get the accelerator fired twice when executed. The first one was created by the setting of the accelerator in the sourcecode, the second one was fired from somewhere else. But at least the crash was gone when the window forced an accelerator in sourcecode.

It took me days to strip the existing code to get a small and reproducible repro case to prove the issue is caused by the TD environment.

The results are really strange and worries me a lot.

I did always assume, commented source or added text as comments throughout the sourcecode did not have any effect at runtime. In fact, it should really not interfere.
Only at design time in the IDE, comments are present. But when eventually building the executable or dynalib, the comments should be stripped.
I believe TD does strip the comments, as the build runtime file does not get smaller or bigger when adding or removing huge amounts of comments.

The testcase 1 shows in fact, comments DO have effect on runtime.

I tried to find out what kind of comments do create issues. At one point I got a testcase where just adding one letter extra to a block of comments would cause runtime crashes. By removing the one character, the crash was gone !!!
Seemed in this case, the limit was 5600 characters. Comments with 5601 characters resulted in crashes !
Also the location of the comments. If I put the comment in front of the window, it crashes. When I move them after the window definition, no crash to be seen.


Another Testcase :
During stripping and testing I discovered TD actually creates hidden data blocks in the sourcecode. They represent something which is not seen in the IDE, but is saved along the source. The sources are all text format, so what is TD saving there ?

When looking in a text editor, those data blocks can be seen spread over the file.
One particular block of data had took my attention. It is the .data RESOURCE block in the classes section.
I discovered, such a block could be there even when there are no classes defined in the source. When starting from scratch with a new empty file, no such block is present. But when including libraries which have defined classes in them and just playing with them (commenting, changing, adding etc) and refreshing the APT which is including those libraries, TD creates the data block when the APT is saved to disk.

An example of a .data block :

Code: Select all

.head 2 -  Class Definitions
.data RESOURCE 0 0 1 2358765342
0000: 17010000E4000000 0000000000000000 0200000300FFFF01 00160000436C6173
0020: 73566172004F7574 6C696E6552006567 496E666F08003C00 000E63006663466F
0040: 7263654F00707469 6573400000E00002 000000A104000000 0260010500000046
0060: 0001730000000100 0036000400046B00 0206D800000046A3 0001000021018008
0080: 0000014200000D63 665500736572436F 6E66694867400000 0200DE0004CA0002
00A0: 0105C600A6017368 0001000004B30004 00B60206003DA600 011A000001801910
00C0: 0000000200001100 5F5F4D6F75736557 006865656C53636F 6C806C2200000001
00E0: 009E0019000A0001 010B00009E007300 600001000000
.enddata

What does the APT have to do with information which is included anyway?
Why would TD save this information along the APT source?

Not only this, but I found out that the data block is not cleared/deleted when the libraries were changed and all classes were removed. The block was still in the APT file. And surprisingly, while stripping a faulty source I got to a repro-case which shows two exactly the same APT files. All bits are identical (by looking using WinDiff) except for the data block.

When running the application build with the datablock, the application crashes when hitting ENTER. The application without the datablock (removed in notepad) did not crash !

Along side with this phenomenon, I did see a clear difference between runtimes which are build from an APT which is including libraries and one which is merged.
When building apps from APT, the runtime crashes on ENTER hit. When the same application is build from a merge, no crash !

And (yes I keep on going) there is a difference between this :

- Open APT
- Merge
- Build runtime

and

- Open APT
- Merge
- Save file as merged text file
- Close TD
- Open merged text file
- Build runtime

The result in the first steps are crashes. The other procedure in building does resolve most crashes.

And also this :

- Open APT
- Build runtime

and

- Open APT
- Press compile (F8)
- Build runtime

The last sequence will create a less stable runtime file.


Thoughts and worries
Up till now I did trust my sources. I always save my sources as text to be sure no strange outline corruptions would take place. I always did assume comments are just comments. My runtime did not suffer from them.

But now, my trust is gone. When I change code now and comment/uncomment code I’m not sure what effect it will have at runtime. Also the hidden data block bother me. Why would a hidden piece of data in a text file, not having any messages when reading the file in TD and no compile errors listed, result in a instable runtime ?

This is a severe issue, as it involves all builds, independent of implemented sourcecode. Even my testcases show a very simple application (in fact no application at all, only one window without code) which is crashing. So what would this issue have effect on my real applications, with lots of code ? Could be anything !
Another side effect : when I did resolve a crash on one window, it appeared on another. It just seems to shift from one location to the other.
Having no crash when window 1 is open and having no crash when window 2 is open, having them both open at the same time results in crashes.

Due to the fact I did not see this before, the problem has arrised between the TD31 and TD42 release and given along to TD51 SP2.

Tests show it is independent of Windows OS (seen in in XP, Home, Vista).

Look at the testcases to reproduce. I would like to know which TD versions have this issue. TD42 and TD51 SP2 proves to be faulty. I do not know about TD4.0 and 4.1 versions.

Make use of WinDiff to see the actual differences of the files which are OK and the ones which produce runtime crash. In both testcases the difference is the datablock and the comments.

Impact
Right now, I can not guarantee my customers they will get a stable runtime. The assumed workaround by removing datablocks and comments do help in some cases, but in some they do not help (like in the shifting of the issue from window to window and the fact combinations of windows opened together suddenly makes the application instable. In applications having hundreds of windows, it is impossible to test the stability in all combinations.
Right now, our production environments report crashes and offer major problems with their users.

We should be able to count on our own eyes to investigate bugs in sourcecode and fix them. Now, this issue does not makes sense at all and is hard to tackle.
As long I can not guarantee the stability to myself, I can not to my customers !
At this point it has escalated to the higher management here to fix the issue.

So I would like to give Unify as much info as possible to track this down and hopefully come up with a fix. As it is in TD51 SP2 and in TD42, the lastest versions suffer and will be a high risk for all Unify TD customers. I hope by finding the defect and investigate the impact on executables also, they can fix a internal fundamental defect which results in less unexplained crashes while using TD build applications.
Gladly I could create very simple reprocases, it took me a week of frustration. I initially was afraid the issue could only be reproduced having the complete application as testcase. But the reprocases posted in this thread show even a very simple application crashes and will help Unify in finding the issue.

The testcases are in TD42 text format, can be back ported to TD31 or ported TD51.
Also create a completely fresh project to see the porting is not the cause. I did it with my testcases also.

I include a WinDbg log which shows some details at the point of crash.
At is always at OamSetOutlineFileInfo, but it could be this function is not the cause.


I also have send this bug report to the appropriate channels.


I would ask Unify to respond to this and I would also like to ask if they could give more information about the .data blocks in the text files. I would like to know what info is stored there and how to extract readable info from it. This way I could determine if blocks are faulty or not and probably create a tool for it.
Maybe they can come up with an explanation why comments in sources create this phenomenon.

It has become a quite a long story here, but I think it is severe enough to get it to attention.

PS
Steps to use the repro cases :
The cases holds two folders, one with a faulty source, one which is OK. Repeat next steps in both folders and see the difference at runtime and in source using WinDiff

- Open Server.apt
- Build runtime (do not use F8 or messing with the source, just make a build)
- Close TD
- Open Client.apt
- Run from IDE or create executable and run from there
- A window is shown, activate it (with mouse) and just press ENTER

[niels]

I did always assume, commented source or added text as comments throughout the sourcecode did not have any effect at runtime. In fact, it should really not interfere.
Only at design time in the IDE, comments are present. But when eventually building the executable or dynalib, the comments should be stripped.
I believe TD does strip the comments, as the build runtime file does not get smaller or bigger when adding or removing huge amounts of comments.

Last time that I checked, huge comments (e.g. commented older versions of form windows) did have an impact on the size of the executable (TD4.0). Copying 21 form windows (commented out) from our main application to a small testprogram resulted in additional 4k in file size.

Look at the testcases to reproduce. I would like to know which TD versions have this issue. TD42 and TD51 SP2 proves to be faulty. I do not know about TD4.0 and 4.1 versions.

Without looking at the testcases (will try them later) I can confirm that sometimes code that worked for years, suddenly stops working. Usually these errors can be solved by moving the code a few lines up/down in the outline. Sometimes something like

Code: Select all

select ...
from ...
into :Table.Column

won't work anymore because of ambiguous references. Changing it to

Code: Select all

select ...
from ...
into :WindowHandle.TableClass.Column

brings it back to life. In these cases, I just shrug and wonder why it worked in the first place.

I cannot remember whether these strange happenings started before our conversion from 1.5.1 to 4.0 or after it. However, after we switched to 4.1, our application would crash
a) when a certain window was opened or
b) randomly.
I didn't have the time to look into this further (and frankly, I was too annoyed to do it in my spare time), so we switched back to 4.0. Never touched 4.2 as we didn't need any of the new features.

[niels]

I was not able to reproduce these crashes with TD4.0.
(EDIT: I meant Dave's repro cases.)

[jmcnamara]

Hi Neils,

Between V1.5.1 and 3.0 some leaks got fixed. I actually had a production application that connected, used, and disconnected a global sql handle - then used that handle several times latter in the app - without reconnecting!. Worked for years - until I upgraded to 3.0 when it finally caught me.

[niels]

Yeah, I stomped into those traps, too. But some of these mysterious things I mentioned above, happened waaaay after our conversion and still happen occasionally. May still have something to do with the bugfixes in TD, but I wonder why the compiler doesn't complain now and does when I move a few lines of code 6 months later. Leaves me puzzled every time, but nowadays I just shrug it off and fully qualify the offending references, instead of weeping onto my keyboard.

[Dave Rabelink]

Last time that I checked, huge comments (e.g. commented older versions of form windows) did have an impact on the size of the executable (TD4.0). Copying 21 form windows (commented out) from our main application to a small testprogram resulted in additional 4k in file size.

That should never be the case IMHO.

Comments must automatically be stripped out when building.

The only items which are in fact part of the build are descriptions which are exported.
So i believe when building AX/COM components, the descriptions are present in the build and they are for sure present
when the descripted item (like a function description) is made exported in dynalibs.
(they can be read when including them, so they must be part of the build).

And it is severe when the comments in the build (if they are mistakenly put into it) results in runtime crashes, which is proved by the reprocase in this thread.

[TerryP]

Hi All,

We had a bad experience a couple of months back with 4.1 ptf 2 where a previously stable version of an application started crashing at runtime after minor changes. The crashes only occurred when running the generated exe, and (of course) wouldn't happen when running the application through the IDE.

After much consternation and gnashing of teeth (and some extended trial/error debugging and code comparison), we found the problem was caused by a new instance variable that had been added to an existing class definition that included a multi-line end of line comment after the variable name (using ctrl+enter within the comment to wrap to a second line). We often use end-of-line comments to describe defined variables, but (afaik) never multi-line comments.

An instance of the class was created as a window variable on an MDI child form window, and fairly consistently would cause a crash when the form window was closed. Moving the instance of the class from the MDI child window to the MDI window (or to the global variables) moved the crash to when the MDI window itself was closed.

Removing the multiline comment from the end of the class instance variable definition entry resolved the problem. The new variable had been inserted as the first instance variable in the class definition. I don't know whether this made any difference, we were so happy to resolve the problem that we didn't try to re-create it! Of course, I doubt whether the problem can be re-created in a simple test application. If I get some time I'll try to do so.

Thought this scenario might also be interesting/relevant when investigating the problem with the comments at runtime issue.

Cheers,

[Dave Rabelink]

@Terry
This is very interesting info. Could be related or al least give an indication there are issues with comments in one way or the other.
I did not see this, but in these cases you have to stumble upon it and come up with a clear pinpoint of the issue.
Would be great if you could reproduce it, but I know it can be difficult to get a small reprocase. What I've seen that by trying, the issue vanishes.

[Dave Rabelink]

Some thoughts about why in some cases builds from a merged file result in more stable builds.

TD, when loading the sources, actually is filtering/stripping parts of the outline.
Ever noticed that commented top level windows from libraries are not shown in the main APT source when
loaded into TD ?

If you comment a class for instance in a library and you include the library in the main source, the commented text is shown there.
When commenting a form, this is not shown in the main source.

Also other parts from included libraries are not shown, like the application startup of formats section.

So, when TD loads a main source which includes libraries, some parts of the outline are filtered/stripped. But at the same time the filtered parts of the sources are still present in memory. So, when building the main application in this case, TD still has to strip the comments. If there is an issue in the procedure how TD filters out comments, the instable builds will be created.

Now, when you merge the main source and save it to disc, the filtered commented parts are really stripped from the merged source.
When loading it back into TD, there is no filtering/stripping of the outline, because there are no libraries included anymore. The source placed in the TD memory is as it is loaded from disc. When building from this merged file, TD does not have to strip/filter comments like in the case when the source is from several included libraries. As I have seen during testing, build from merged files have less runtime instabilities. Though in some cases the crashes are gone, even on some builds I still get crashes.
But for now, our developers are instructed to do a merge first, save it to disc, close TD and reopen the merged file before building.

Nice thing to mention. When merging the main source, you will have to save it to disc first, close TD and reopen the merged file.
If you do not use these steps, the instability remains. This is because when TD merges the source, TD already has a faulty internal outline. When building at that stage, the instability is still present. When you start with a fresh TD instance and load the merged file then, it seems TD handles the internal outline better which results in more stability of the builds.


During more investigations and trying to get more testcases I stumbled upon a situation where I can not solve the crashes. Here, there are no comments at all in the source, but the location of the top level window determines if the particular window is stable or not.
I could not pinpoint the reason. Could be another part in the outline which is causing the instability which I have not seen yet.

The next reprocase shows this. The two folders contain the same sample as in my previous testcases, except there are two windows in the source.
Technically, the samples are the same. The only difference is the location of the window in the outline.
When dlgServer is in front of dlgAnyWindow, there are no crashes on dlgServer but there is a crash in dlgAnyWindow.
When the windows are swapped in the outline, the crash is swapped also. In this case dlgServer is crashing.

When more windows are added, there is no clear prognosis which one is stable and which is not. But when changing the outline order, the instability just jumps from one to the other window.

[Matthias]

Hi,
I have near the same problem....

We have an little sample we have created an apd with an table and an application that will open this table.
If th user press ESC ENter INS or DEL or.... other ekys the applicatoin crashes.

Matthias

[Matthias]

Thanks Unify for fixing... with Patch EMP5032.
Matthias

[tlauzi]

Hi Matthias,

what is Patch EMP5032? (Is it included in an Service Pack? For which version?)

Regards,
Thomas L.

[Matthias]

Solved via supportcontract but solved!

Matthias

[chrisadam5]

But … to do this, you must understand the theory, so that you understand ...... The lack of maintenance will have especially dramatic effects


_________________________________________


Want to get-on Google's first page and loads of traffic to your website? Hire a SEO Specialist from Ocean Groups seo pecialist

[Ren]

Hi, I'm sorry to necro an 'old' thread, but this one struck a chord.

I've experienced a lot of the problems mentioned in this thread. The (multiline-)comment thing strikes every now and then, and the worst part is when you comment out functions/classes and end up crashing on compilation. This has been a problem several times over the three years I've been developing on TD.

The CLASSPROPS are used for several things, most obviously the 'last view' on development. For instance, every .APT file has CLASSPROPS that contain application folders, icon information and build names. Most of the stuff you can change from the GUI and in most circumstances you can basically delete the CLASSPROPS entirely and the file will work happily. What else are they used for? I honestly don't know. There is no documentation available on the subject and Unify has been tight-lipped about them before.

If you use a source control that shows DIFFs (who doesn't, these days?) on commit, you will basically always see changes in these CLASSPROPS on commit. This is because pretty much no one saves the window in the same 'view' as it was when the last person committed it. Personally I undo these changes with a comparison tool before committing most of the time. It saves time and trouble in problem situations. We have even been forced to reset all CLASSPROPS of all libraries two times, to fix/standardize them.

I have also tried to remove comments from application/library with a script, but it is mostly impossible due to the .winattr/.end/.data blocks mentioned above. Well, impossible to do simply, at least

It also annoys me that customer-per-customer based fixes are applied but not shared. Would it be so horrible to make these available for developers on a regular basis?