Watch, Follow, &
Connect with Us
Public Report
Report From: Delphi-BCB/Compiler/Delphi/RTTI    [ Add a report in this area ]  
Report #:  98261   Status: Closed
Compiler AV on $RTTI directive
Project:  Delphi Build #:  XE, ... XE5
Version:    19.2 Submitted By:   Eric Grange
Report Type:  Basic functionality failure Date Reported:  8/28/2011 11:36:55 PM
Severity:    Commonly encountered problem Last Updated: 4/15/2014 6:49:35 PM
Platform:    All platforms Internal Tracking #:   23323
Resolution: Fixed (Resolution Comments) Resolved in Build: : XE6
Duplicate of:  None
Voting and Rating
Overall Rating: No Ratings Yet
0.00 out of 5
Total Votes: 12
Description
See
http://stackoverflow.com/questions/7201817/enable-delphi-xe-rtti-only-for-some-classes

Added by Sysop
<<<<<<<<<<
I'm trying to have RTTI enabled only for a subset of my classes.

The reason is that for those classes for which I want RTTI, I want RTTI on public methods too, but if that is enabled project-wide, then all public methods from all classes get into the final executable. This basically turns off the smart-linking, as the compiler considers that every public method could be called at runtime, and thus ends up compiling pretty much everything and the kitchen sink into the executable...

I've tried several things:

    Turning off RTTI at the project level with {$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])} and then re-enabling it for the relevant units results in crashes at compile time (an AV somewhere in the compiler) on the $RTTI directive.
    Turning off RTTI at the project level and then enabling it class-by-class compiles, but at runtime it results in an unqualified AV deep in "Rtti.pas" when attempting to access the RTII for the exposed classes
    Controling RTTI via $RTTI directives embedded in the ".inc" all units use results in random AV at compile time (always at the line of the $RTTI directive, but not always for the same unit).

Any other ideas?
>>>>>>>>>>
Steps to Reproduce:
Added by Sysop
<<<<<<<
Runtime AV was caused by not having RTTI for some of the attributes on the classes with published RTTI. There is no compiler or error or warning, you just get an AV in RTTI.pas, Findctor.

You can reproduce it by having a class with RTTI active and an attribute, and with that attribute having RTTI inactive.

Compile time AV seem related to having the $RTTI directive happen before the "unit" statement in a unit, if the $RTTI directive is after, it works. It should be reproducible in any unit or project AFAICT.
>>>>>>>


Reproduceable on "LanguageTests" unit tests of DWScript.

Get the source from the SVN
http://code.google.com/p/dwscript/
Version at datetime 29/08/11 can be used to reproduce the issue.

In the LanguageTests.dpr, uncomment the $RTTI directive, build, run the RTTIExposeTests.

You can also try the alternatives mentioned in the StackOverflow post.
Workarounds
Enable RTTI project-wide, though that corresponds to basically turning off smart-linking, and poses security issues as all classes and methods and up accessible through RTTI exposition.
Attachment
Chromium.ZIP
Comments

Tomohiro Takahashi at 8/28/2011 11:56:43 PM -
What version(and build no) of Delphi do you use?

and, please write more detailed [Description], [Steps] to reproduce/verify/track your issue properly.

and, could you please attach sample project to confirm your issue?

Eric Grange at 8/29/2011 8:37:36 AM -
Version was already specified, see fields at top "Version" and "Build #".

Steps are described in the StackOverflow link.

Sample project can be downloaded at the provided GoogleCode SVN, you should be able to checkout SVN directly from Delphi, that was added in Delphi XE. Otherwise, you can use TortoiseSVN (http://tortoisesvn.tigris.org). SVN checkout instruction are at the provided GoogleCode page and also in the GoogleCode FAQ.

If you read the StackOverflow report, the issue was reported not reproducible on a basic project, so you'll need the whole project from SVN.

Tomohiro Takahashi at 8/29/2011 8:35:05 PM -
> Version was already specified, see fields at top "Version" and "Build #".
No, no.
Are you using Delph XE(Build No 15.0.3953.35171) ?
and, could you please attach sample project to reproduce your issue?

> Compiler AV ...
> ...
> If you read the StackOverflow report, ...
When posting QC report, please write details in [Description], [Steps] to verify/open/track your issue in our internal tracking system properly.
So, could you tell us more detail about the 'AV'?
Thanks.

Eric Grange at 8/30/2011 1:29:08 AM -
(5th attempt to post this comment)

Yes XE 15.0.3953.35171

Can't seem to attach by QC web interface.
QC app client crashed on attach.
I posted a ZIP of the SVN there: http://dwscript.googlecode.com/files/zip_for_qc98261.7z
Though you may only need it to confirm the fix.

(summary below, I lost detailed investigations during earlier post attempts...)

Runtime AV was caused by not having RTTI for some of the attributes on the classes with published RTTI. There is no compiler or error or warning, you just get an AV in RTTI.pas, Findctor.

You can reproduce it by having a class with RTTI active and an attribute, and with that attribute having RTTI inactive.

Compile time AV seem related to having the $RTTI directive happen before the "unit" statement in a unit, if the $RTTI directive is after, it works. It should be reproducible in any unit or project AFAICT.

Tomohiro Takahashi at 8/30/2011 4:38:49 AM -
> I posted a ZIP of the SVN there: http://dwscript.googlecode.com/files/zip_for_qc98261.7z
Could you please use Windows Native QC Client to attach a .zip file to your report?
The standalone client comes with Delphi.
Thanks.

Eric Grange at 8/30/2011 5:49:19 AM -
This is the one I referred by "QC app client", however it typically fails to start with a "server is unavailable" error, and when it starts at all, it is very slow and fails when trying to go to the QC or during attachment (connection lost error).

FWIW, the QC web interface is very problematic too for that matter and often fails, I have to hit refresh multiple times or submit comments multiple times, while the main site (www.embarcadero.com) responds and navigates fast.

But at least it works, while the standalone client just crashes has to be restarted from scratch after a connection loss.

Tomohiro Takahashi at 8/30/2011 7:32:19 PM -
> ...  it typically fails to start with a "server is unavailable" error, ...
Yesterday, QualityCentral server was down... But, it is running now.

ok,
Could you please upload sample project(as a .zip) to Discussion Forum? I will attach it to this report.
[Embarcadero Discussion Forums >> Attachments]
https://forums.embarcadero.com/forum.jspa?forumID=2

Eric Grange at 8/31/2011 12:19:34 AM -
Posted.

QC server doesn't seem much more stable today...

Tomohiro Takahashi at 8/31/2011 2:47:42 AM -
I attached it to this report.
Thanks.

Cesar Romero at 6/12/2013 6:46:46 AM -
I have the same issue, and it make me stop to use attributes, until it get fixed, it is a shame to have a feature like that and cannot be used in a complex project.

This another post in StackOverflow explains some cases like that
http://stackoverflow.com/questions/9499135/error-while-trying-to-access-class-attributes

Steffen Binas at 2/5/2014 1:41:53 AM -
The problem is still existent and very annoying. Tested with XE3 and XE5 Update 2.

Server Response from: ETNACODE01