- 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
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