EInvalidPointer exception in TraLangInfoList.Destroy + $88

rbuser

I'm currently in the process of porting a project from Delphi
XE/ReportBuilder 12.05 to Delphi XE3/ReportBuilder 14.08. I now have
the problem that when I shut down my application it crashes ("XYZ has
stopped working" dialog from Windows). If I run it in the debugger I
see that there is an EInvalidPointer exception. The first and only
entry in the call stack that's not from the RTL is
TraLangInfoList.Destroy + $88. Looks like it's trying to free a
TStringList...

Lacking the source that would allow me to debug this myself, can you
give me a pointer (no pun intended) what I should be looking for? I
haven't changed any of our own (reporting-related) code since the
upgrade.

I have a unit with some custom functions that I register via
raRegisterFunction in the initialization section and unregister via
raUnregisterFunction in the uninitialization section. I also have raIDE
in the uses clause of another unit (a datamodule containing my report
component - note that the error also occurs even if I never instantiate
that component). A breakpoint set on the first of the unregister calls
never triggers.

Any ideas?

Were there any breaking changes between RB 12.05 and 14.08?

Cheers,

Oliver

nicocizik

Hi Oliver,

There should not be any breaking changes with regards to RAP between RB
12 and RB 14.

The first thing to try is set the
Report.PreviewFormSettings.SinglePageOnly to True and see if the new
threaded preview architecture is causing the issue. (If you are just
using a TppViewer, set the TppViewer.SinglePageOnly property to True).

Then as a test, try commenting out the custom RAP functions and the
associated RAP code to see if this is causing the problem. The
TraLangInfoList class is used to hold the available routines and types
in the code toolbox when using RAP.

rbuser

Thanks for replying!

I think I figured out the real problem now and it had nothing to do
with RAP or ReportBuilder.

I am now 99% sure this was a mere symptom of a complicated memory
corruption issue that was caused somewhere else entirely (note to self:
never use safecall on IUnknown-based interfaces unless you absolutely
know what you're doing ).

Cheers,

Oliver

nicocizik

Great! I'm glad you got the issue sorted.