Getting a RtlSizeHeap exception/breakpoint traced back to ReadComplex

Remoting SDK
1

Hello,

When running my app (a RemObject SDK client usign SuperTCP channel) inside the debugger I get a lot of “non-user breakpoint” with the same info (from the Event Log window):

Process SMartis5Consultas.exe (3312)
Non-user Breakpoint at $775405BF. Process SMartis5Consultas.exe (3312)
Debug Output: HEAP[SMartis5Consultas.exe]: Process SMartis5Consultas.exe (3312)
Debug Output:
Invalid address specified to RtlSizeHeap( 006E0000, 049A41E8 )

The callstack at the point where the debugger stops is:

Any idea what can be causing this? It’s quite difficult to debug when I have to press F9 constantly to jump this breakpoint. Debugging in C++Builder is difficult per-se, this just makes things much more painful :smile:

I’ve stepped into the TGrabacion::ReadComplex function and the breakpoint happens, or so it seems, when the else { } block is finishing, I mean with this: it doesn’t happen when doing the Reading of the different elements of the structure, but when going out of scope.

Is this a known issue, somebody else experiences this?

I’m using C++Builder XE5 and RO-SDK version 8.1.85.1143.

Thanks

2

I can’t reproduce it.

Can you create a simple testcase that reproduces this case, pls?
You can attach it here or send to support@.

3

I will update to the latest version and try with it. If it still happens I will try to create a small test app that shows the issue.

Thanks for your reply.

4

I still get the error with the latest version. Are you trying with a C++Builder client? It might well be a problem with the templates (which are still not fixed, BTW) and the code generated for C++Builder.

I will try to get the time to create a test project to show this issue, but it would be in C++, and at least as far as I can see, the latest version still needs a lot of manual fixing to be usable in C++Builder.

5

I ignored the non-user breakpoints in the IDE config and it doesn’t stop anymore there, so unless there is a problem per se with cause for this (at the end it says that it’s an invalid address for the RtlSizeHeap function, which could indicate a problem somewhere else I guess?) I can live with it.

If you have the “ignore non-user breakpoints” enabled, maybe you can disable it and try again there?

Thanks

6

“ignore non-user breakpoints” option is disabled.
what data types are used in TGrabacion struct?

7

I have:
3 Guid
3 DateTime
2 Boolean
3 WideString
1 Int64
1 Double
2 Different Enums (declared in the same rodl)

8

I’ve tested with XE7 C++ Builder and original problem with RtlSizeHeap exception still isn’t reporduced, but I’ve found and fixed problem with passing enums (#70814).

Extract file from Templates.zip (38.2 KB) archive into …\RemObjects SDK for Delphi\Source\CodeGen2\Templates and recompile RemObjects_Server_IDE_DXX.dpk

about original problem, seems it is “common” problem inside _VarToWStr: http://www.borlandtalk.com/invalid-address-specified-to-rtlsizeheap-vt1099.html

9

Hello Evgeny,

I guess the enum problem is one of the ones I reported a while back, I already have code to fix that. There are lot’s of other stuff needed for C++ compatibility, and IIRC I have sent back my changes before. With the latest version I still had to do a lot of manual fixing, even if one of the issues I reported was marked as fixed.

There is a special problem with strings, IIRC, that need (or that was the solution I found) a Delphi class to wrap and return the correct type being used. I sent it to support a while back.

Just for reference, the issue numbers that I registered of the problems with C++ were: 67955, 68054, 68226. The last two are not fixed yet.

I can live with the slowness while debugging of the app while it’s catching and ignoring these exceptions. I will try to create a test case to send directly just so you can check the exception and say if it’s harmless or it’s something that should be taken into account. It might well be some of the changes I did to the code to be able to work with C++Builder, but I don’t really know.

Thanks,

Rodrigo

10

according to #68226:

  1. In the uRODL.hpp header, around line 68, the definition for TRODLUseList is before the
    forward definitions of the used type (TRODLUse). As this is a Delphi bug with the
    generation of the header file and the odds of Embarcadero fixing this are quite small, you
    can add an HPPEMIT which just does a forward def of that type, TRODLUse, and be done with
    this.

fixed

  1. In the uROBaseSuperHttpChannel.hpp header, around line 147, there is an inline
    “InvokeRequest” which fails to compile bacause of an ambiguity:

fixed

  1. The Synsock.hpp header is still defining several consts and so on that are not needed
    in C++ and just generate problems when building it.

not yet. you can use Indy-based channels instaed

  1. The templates: the _Intf are still missing the code to generate correctly Enums.

fixed. now it registers enums in initialization section. Templates.zip (38.3 KB)

  1. The _Intf still use the “old” macros to get the PTypeInfo, which as far as I can see
    won’t work correctly for most of the native (Delphi) types.
  2. I haven’t checked this, but for the differences in the code it doesn’t appear that the
    use of the correct header if one includes DataAbstract4 in the RODL was done.

can you describe these in more details, pls?

11
  1. The _Intf still use the “old” macros to get the PTypeInfo, which as far as I can see
    won’t work correctly for most of the native (Delphi) types.

Right now, in the _Intf file generated, you are using some macros to get the PTypeInfo in the serialization of the structures (for instance, in ReadComplex, or the functions that write the parameters on the __Message and later read them.

These macros don’t work for several of the Delphi types, as they are executed by the C++ runtime (or so I guess) and then the PType returned is different from the one expected in the Delphi RO-SDK code. IIRC this was the case for instance for strings. This makes the serialization of the parameters and the results incorrect, maybe even make it crash at some point.

To fix this I created a simple PAS unit and included it in some of the RO packages that replaces the macros (for instance, __GetboolInfo or __GetWideStringInfo) with functions that are Delphi code and thus return the correctly PTypeInfo. IIRC I explained all this in some of the emails I sent to support a while back. The unit name was uROTypeInfoHelpers and it creates a HPP with the functions and the #defines needed to replace the old macros. I’m attaching the unit here, in case it got lost somewhere.

uROTypeInfoHelpers.pas (2.8 KB)

I added this unit to the RemObjects_Core package. It should be usable in any modern version, I believe, but I haven’t tried in anything but XE5.

Regarding number 6, I don’t remember exactly what is the problem there. I’m not using DA right now, just RO-SDK, so I haven’t had a chance to see if the headers are still being included incorrectly. I think the problem was that if you included DataAbstract4 in a RODL, then when generating the CPP code the DataAbstract4 header was not included and it made it impossible to compile the generated code. And as these units are regenerated with each build fixing them by hand was not possible. I would have to check directly what was the issue, but something along these lines IIRC.

I believe there are some other issues I have found with some other headers, which are fixed more or less easily, but if it was possible to have them working from the beginning it would certainly make things much more easy.

On a side not, also, recompiling the packages to enable C++ is somewhat awful, specially as you have to setup the header output location and so on. And this for each platform. I recommend that you change the fixed locations in each platform to use the $(Platform) macro and move the locations to the base project.

Thanks!

12

Just to complete:

The macros are created in the _Intf.h header, below a /* Simple type holders */ comment where you explain how is it working.

You still need the code for the types declared in the RODL (and they work there as they are defined in C++), but all the others native types should be on a Delphi unit.

I don’t know if this works like it’s now when not using runtime packages and RTL, I always work with runtime packages and dynamic RTL enabled.

13

thx. Logged as 70830 for reviewing.

14

bugs://70835 got closed with status fixed.

15

bugs://70836 got closed with status fixed.

16

bugs://71111 got closed with status fixed.

17

bugs://70830 got closed with status fixed.

18

Hello,

I have just implemented a client that consumes the services described here, and I get the similar issues under the debugger, but more problematic: the app crashes when NOT running under the debugger.

Under the debugger I get a “Invalid address specified to RtlSizeHeap”, traced back to a ReadComplex, but I can continue. But when running outside the debugger Windows just shuts down the app.

Here is the callstack under the debugger:

This happens on a Windows 7 machine. On a Windows 8 apparently works, i.e., the process finishes and Windows doesn’t make any big deal about this. But I can’t find anything special on this Win7 installation for it to fail, and as such, I don’t know if it will fail with my customers or not, or under what circumstances.

19

from the latest callstack, looks like you are using packages.
if you disable packages, will it fail?

20

I haven’t tried that way. I would need to create a small test app to do that, as converting my app is impossible.

I will try later and let you know what happens.