Access violation in "TsiLangRT.EditAll"

Jean-Paul Brassard · Post by **Jean-Paul Brassard** » Thu Jun 18, 2009 1:12 pm

We recently started to get a very weird AV errors when calling the "TsilLangRT.EditAll" method... Error is:

Access Violation at address 08029BA2 in module "GivenPlugin.dll".
Read of address 0000016C.

1) If I compile the same given Plugin (DLL) on my computer (TsiLang Full Source), then it runs OK on others PC. If I run on my computer the same DLL, but compiled on another computer (DCU only), then I also get the error!!!???

2) If I go back in our project archives and run an old version of the same DLL, there is no error at all.

3) I went on a computer that shows the problem and run the code in debugging mode to find the error. The error occurs inside the TsiLangRT.EditAll method.
To try to find more info about this problem, I temporarily installed on this computer the full source version of TsiLang. Strangely, the problem does not show up anymore !!!

4) I take the TsiLang DCUs on my computer (compiled from my Full Source) and put them on another computer (DCU Only version of TsiLang). Then I compiled that same Given Plugin (DLL) on this computer and we get the Access Violation error on both computers

.

All this is very very strange!
Why does the DLL compiled with Full Source works fine but not the the same DLL compiled with the DCU only version???
You once told me that both versions are not exactly the same.
Do you have an insight of which difference could explain this???

P.S. This error was not there until our IT Administrator started playing with admin rights of our users

. I need to solve this problem, or find a workaround without getting back to old admin config because some of our customers' config could produce the same error.

Post by **isiticov** » Fri Jun 19, 2009 3:02 pm

This is a very strange case (as you already noticed) and I can't think of any possible reason for that. The only one: are the IDE versions exactly similar on both PC (including updates and pathes)?

Jean-Paul Brassard · Post by **Jean-Paul Brassard** » Mon Jun 22, 2009 3:00 pm

For experiment #3, yes it was done on the same given computer.
The only change is switching from DCU only to Full Source version of TsiLang...

3) I went on a computer that shows the problem and run the code in debugging mode to find the error. The error occurs inside the TsiLangRT.EditAll method.
To try to find more info about this problem, I temporarily installed on this computer the full source version of TsiLang. Strangely, the problem does not show up anymore !!

Post by **isiticov** » Tue Jun 23, 2009 6:46 pm

Do you have the latest version installed? Because there was something similar with previous build under C++Builder IDE. But this was gone in 6.4 build.

Jean-Paul Brassard · Post by **Jean-Paul Brassard** » Tue Jun 23, 2009 6:55 pm

Yes, we are using the 6.4 version (Feb. 19, 2009) of TsiLang.

I am not sure that the problem was there with the previous version (6.3.0.2) of TsiLang. Should I go back and try if the problem vanishes?

Post by **isiticov** » Tue Jun 23, 2009 7:12 pm

No, please don't go back to previous version. The most strange thing is that compiled from sources on the same PC the problem goes away.
I even don't have any idea what to check more.

Jean-Paul Brassard · Post by **Jean-Paul Brassard** » Tue Jun 23, 2009 8:06 pm

OK.

Another test we could do is to compile an old version of our applications with the version 6.4 of TsiLang.

We already went back in our archives and tested the EXE of a version that was then compiled with the version 6.3.0.2 of TsiLang. That version does not show the problem, even if it was compiled with DCU only version of TsiLang.

If that old version of our application does not show any problem when compiled with 6.4, then there is something on our side that have changed and which induces the error in TsiLangRT.EditAll method...

If that old "OK" version of our application begins to show the Access Violation when we compile it with the newer version of Tsilang, then something has changed on your side that induces the error...

I will let you know when we have the answer.

Yves Anglade · Post by **Yves Anglade** » Thu Jul 02, 2009 8:56 pm

Hi,

I am a colleague of Mr. Brassard and I experienced the same Access Violation error in my application, that was built with version "6.4.0 binaries only" of TsiLang. However, when I build the same code with version "6.4.0 Full Source", the problem doesn't occur.

Since we didn't have the problem before using 6.4.0. I have decided to do the test with the code of an old version of our application dated in December 2008. Again, when I build that code with TsiLang "6.4.0 binaries only" I get the Access violation, and there is no problem when I build it with "6.4.0 Full Source".

Finally, I have decided to revert back to an older version of TsiLang (6.3.0.2 binaries only) and to build both the recent version of our application and the one dated in December 2008. With both versions of of our code, there is no problem.

The problem seems to be specifically with TsiLang "6.4.0 binaries only".

The same result was obtained when building on several machines. Executables and dlls were also run on other machines with the same results.

Details:
- Code built with Delphi 7 VCL in Windows XP SP2 environment.

Thanks,
YA

Post by **isiticov** » Mon Jul 06, 2009 4:00 pm

Hi,

Thank you for the detailed investigations. As far as I understood, if you build your project using the Full Source then it works just fine but when your build it with using the DCU-Only thn you get this error. The most strange thing is that DCUs are compiled automatically from the same sources which included into the release. I can only advise the following to try: distribute TsiLang DCUs from the PC with sources to the PCs with DCU-Only installed and then try to re-build your DLL.
Please let me know if this helped.

Jean-Paul Brassard · Post by **Jean-Paul Brassard** » Mon Jul 13, 2009 5:59 pm

isiticov wrote:As far as I understood, if you build your project using the Full Source then it works just fine but when your build it with using the DCU-Only thn you get this error.

Exact (new problem with 6.4, does not occurs with 6.3.0.2).

isiticov wrote:The most strange thing is that DCUs are compiled automatically from the same sources which included into the release. I can only advise the following to try: distribute TsiLang DCUs from the PC with sources to the PCs with DCU-Only installed and then try to re-build your DLL.

I already tried that and the same problem occurs !?!?!?

So it could be caused by a compiler directive that differs for DCU versus Full-Source version?

Post by **isiticov** » Tue Jul 14, 2009 7:14 am

I already tried that and the same problem occurs !?!?!?

No, there is no ANY compiler directive to differ between DCU and Full source. So if you create TsiLang DCUs on your PC with full sources then just copy them (TsiLang DCU files) onto another PCs and re-build the DLL there. If this doesn't help (since linker just links the SAME DCU files) then there could be some problem on the PCs where the problem is reproducible. May be to try to re-install Delphi?

Jean-Paul Brassard · Post by **Jean-Paul Brassard** » Mon Jul 20, 2009 11:14 pm

Yeh !!! Finally found it

The problem was not a wrong DCU in the DCU Only 6.4 Version. It is a wrong DFM. For example, the new "ToolButton27" component in "siTransEditor.dfm" is missing in the DCU Only DFM.

In fact, the 6.4 DCU Only version of TsiLang is shipped with the 6.3.0.2 version of the siTransEditor.dfm, while the Full Source is shipped with the new DFM. Comparing the DFM files proves it. Moreover all the DFM shipped with the 6.4 DCU Only version are obsolete.

When running the 6.4 DCU Only version, the creation of siTransEditor Form does not instanciate some components, such as tbClose. Then, when SetWasChanged is called, we got an Access Violation because btClose is still "nil".

Post by **isiticov** » Tue Jul 21, 2009 1:57 pm

Hello,

Thank you very much for discovering this! This is very strange and we will try to find a reason of failure in our build/release script. We will prepare and release the updated build shortly.
Thank you again for reporting this!

Jean-Paul Brassard · Post by **Jean-Paul Brassard** » Tue Jul 21, 2009 2:27 pm

It was indeed very tricky

Should I post another dedicated thread to advise other TsiLang users of that problem?

Post by **isiticov** » Tue Jul 21, 2009 3:34 pm

Should I post another dedicated thread to advise other TsiLang users of that problem?

Sure, your help is very appreciated!