[Ace-users] Re: Access violation if handling a structure containing an octet sequence length > 2604 bytes

arne.berger at gmx.de arne.berger at gmx.de
Wed Aug 22 04:58:10 CDT 2007


Hallo Douglas,

I've already wrote this to Johnny Willemsen:

I could not reproduce this affect with a small sample. However with
using the codeguard tool I found out that the allocation and
deallocation is done from different RTL's. Here are the messages from
codeguard:


------------------------------------------
Error 00059. 0x340010 (r) (Thread 0x0D8C):
Resource from different RTL:
delete[](0x019FC090)

Call Tree:
   0x00625D07(=TAO_BD.DLL:0x01:004D07) ..\tao/
Unbounded_Value_Allocation_Traits_T.h#45
   0x00625CF7(=TAO_BD.DLL:0x01:004CF7) ..\tao/
Unbounded_Octet_Sequence_T.h#250
   0x00625CDA(=TAO_BD.DLL:0x01:004CDA) ..\tao/
Unbounded_Octet_Sequence_T.h#76
   0x00683BFA(=TAO_BD.DLL:0x01:062BFA) ..\tao/
Unbounded_Octet_Sequence_T.h#264
   0x00489961(=PhysicsDataMng.exe:0x01:088961) D:\Programme\Borland\BDS
\4.0\ACETAO\\include\tao/Unbounded_Sequence_CDR_T.h#119
   0x00489872(=PhysicsDataMng.exe:0x01:088872) sourcescpp
\sim_common_c.cpp#3397

The object array (0x019FC090) [size: 2604 bytes] was created with
new[]
Call Tree:
   0x004492CC(=PhysicsDataMng.exe:0x01:0482CC) D:\Programme\Borland\BDS
\4.0\ACETAO\\include\tao/Unbounded_Value_Allocation_Traits_T.h#40
   0x00441318(=PhysicsDataMng.exe:0x01:040318) D:\Programme\Borland\BDS
\4.0\ACETAO\\include\tao/Unbounded_Octet_Sequence_T.h#247
   0x004350EC(=PhysicsDataMng.exe:0x01:0340EC) D:\Programme\Borland\BDS
\4.0\ACETAO\\include\tao/Unbounded_Octet_Sequence_T.h#57
   0x004898E2(=PhysicsDataMng.exe:0x01:0888E2) D:\Programme\Borland\BDS
\4.0\ACETAO\\include\tao/Unbounded_Sequence_CDR_T.h#111
   0x00489872(=PhysicsDataMng.exe:0x01:088872) sourcescpp
\sim_common_c.cpp#3397
   0x00489AAF(=PhysicsDataMng.exe:0x01:088AAF) sourcescpp
\sim_common_c.cpp#3425

------------------------------------------
Error 00058. 0x340010 (r) (Thread 0x0D8C):
Resource from different RTL:
delete[](0x01A0CAD0)

Call Tree:
   0x00625D07(=TAO_BD.DLL:0x01:004D07) ..\tao/
Unbounded_Value_Allocation_Traits_T.h#45
   0x00625CF7(=TAO_BD.DLL:0x01:004CF7) ..\tao/
Unbounded_Octet_Sequence_T.h#250
   0x00625CDA(=TAO_BD.DLL:0x01:004CDA) ..\tao/
Unbounded_Octet_Sequence_T.h#76
   0x00683BFA(=TAO_BD.DLL:0x01:062BFA) ..\tao/
Unbounded_Octet_Sequence_T.h#264
   0x00489961(=PhysicsDataMng.exe:0x01:088961) D:\Programme\Borland\BDS
\4.0\ACETAO\\include\tao/Unbounded_Sequence_CDR_T.h#119
   0x00489872(=PhysicsDataMng.exe:0x01:088872) sourcescpp
\sim_common_c.cpp#3397

The object array (0x01A0CAD0) [size: 2606 bytes] was created with
new[]
Call Tree:
   0x004492CC(=PhysicsDataMng.exe:0x01:0482CC) D:\Programme\Borland\BDS
\4.0\ACETAO\\include\tao/Unbounded_Value_Allocation_Traits_T.h#40
   0x00441318(=PhysicsDataMng.exe:0x01:040318) D:\Programme\Borland\BDS
\4.0\ACETAO\\include\tao/Unbounded_Octet_Sequence_T.h#247
   0x004350EC(=PhysicsDataMng.exe:0x01:0340EC) D:\Programme\Borland\BDS
\4.0\ACETAO\\include\tao/Unbounded_Octet_Sequence_T.h#57
   0x004898E2(=PhysicsDataMng.exe:0x01:0888E2) D:\Programme\Borland\BDS
\4.0\ACETAO\\include\tao/Unbounded_Sequence_CDR_T.h#111
   0x00489872(=PhysicsDataMng.exe:0x01:088872) sourcescpp
\sim_common_c.cpp#3397
   0x00489AAF(=PhysicsDataMng.exe:0x01:088AAF) sourcescpp
\sim_common_c.cpp#3425


Codeguard avoids the access violation. Without linking the codeguard
library the server program crashes if more than 2604 bytes was
received.

In my large project I firstly build a static library from all IDL
generated cpp files. This library is linked to the server process
without using the option "Use dynamic RTL". If I build all (the
library and the server.exe) with this option no errors occur. If I
directly add the IDL generated CPP files to the server project file
without using the library it works fine too. Also the error from
codeguard tool is lost.

It seems to me a version without using of dynamic RTL is not possible
with usage of BDS2006 ?? Now I had to change all projects and to set
the option "Use dynamic RTL" to be sure the TAO unbounded sequences
are working correctly. Or do you have a different idea?


Additional information for you Douglas: I could not compile the
version ACE+TAO 5.5.10 with BDS2006 because of missing include paths.
Compilation breaks because diverse PIDL files are not found. I had no
time to correct it ut to now.


Thanks for help

Best regards
Arne Berger


On Aug 17, 5:11 pm, schm... at dre.vanderbilt.edu (Douglas C. Schmidt)
wrote:
> Hi Arne,
>
> Thanks very much for usin gthe PRF.
>
> >    ACE VERSION:
> >        5.5.4
>
> I recommend you do two things:
>
> 1. Please upgrade to ACE+TAO+CIAO x.5.10 (i.e., ACE 5.5.10, TAO 1.5.10, and
>    CIAO 0.5.10), which you can download from
>
>    http://download.dre.vanderbilt.edu
>
>    under the heading: "Latest Beta Kit".
>
> 2. If the problem still persists use a memory corruption tool like
>    Purify to BoundsChecker to see if there's a memory corruption going
>    on somewhere.
>
> The DOC groups at Washington University, UC Irvine, and Vanderbilt
> University only provide "best effort" support for non-sponsors for the
> latest release, as described in
>
> http://www.dre.vanderbilt.edu/~schmidt/DOC_ROOT/ACE/docs/ACE-bug-proc...
>
> Thus, if you need more "predictable" help for earlier versions of
> ACE+TAO, I recommend that you check out
>
> http://www.dre.vanderbilt.edu/support.html
>
> for a list of companies that will provide you with ACE+TAO commercial
> support.
>
> Thanks,
>
>         Doug
>
>
>
> >    HOST MACHINE and OPERATING SYSTEM:
> >        Intel(R) Core(TM)2 and Windows XP Prof. V2002 SP2
>
> >    COMPILER NAME AND VERSION (AND PATCHLEVEL):
> >        Borland Developer Studio for Microsoft=C2=AE Windows=E2=84=A2 Versi=
> >on
> >10.0.2288.42451 Update 2
>
> >    THE $ACE_ROOT/ace/config.h FILE
> >        config-win32.h
>
> >    AREA/CLASS/EXAMPLE AFFECTED:
> >        TAO::template <typename stream>
> >        bool demarshal_sequence(stream & strm,
> >TAO::unbounded_value_sequence <CORBA::Short> & target)
> >        and
> >        TAO::details::template<typename T, bool dummy>
> >        struct unbounded_value_allocation_traits::freebuf(value_type
> >*)
>
> >    DOES THE PROBLEM AFFECT:
> >        COMPILATION: no
> >        LINKING: no
> >        EXECUTION: yes
> >        OTHER: no
>
> >    SYNOPSIS:
> >        Access violation if handling a structure containing an octet
> >sequence length > 2604 bytes
>
> >    DESCRIPTION:
> >        I've implemented a server interface contains a method with a
> >        structured "in" parameter. The structure consists of several
> >sequences
> >        (key-value-pairs like string-long, string-double, string-
> >binary data and so on).
> >        The entries of the binary data sequences is defined as
> >            struct SimBinary
> >            {
> >              string          key;     // identifier
> >              sequence<octet> value;   // the binary data
> >            };
> >            typedef sequence<SimBinary> SimBinarySeq;
> >        If any of these octet sequences contains more than 2604 bytes
> >an
> >        access violation occurs in
> >            TAO::details::template<typename T, bool dummy>
> >            struct
> >unbounded_value_allocation_traits::freebuf(value_type *buffer)
> >            {
> >              delete [] buffer;  // access violation
> >            }
> >        Within template
> >            TAO::template <typename stream>
> >            bool demarshal_sequence(stream & strm,
> >TAO::unbounded_value_sequence <CORBA::Short> & target)
> >            {
> >              ...
> >             sequence tmp(new_length);
> >              ...
> >            }
> >        a temporary instance "tmp" is created. At the end of function
> >block the destructor
> >            ~unbounded_value_sequence<CORBA::Octet>();
> >        is called and invokes
> >            freebuf(buffer);
>
> >        Until length of 2604 bytes no problems occur. Is there a limit
> >I've to look after?
> >        Nevertheless an access violation should not occur!
>
> >    REPEAT BY:
> >        See description. After first exception thread is died.
>
> >    SAMPLE FIX/WORKAROUND:
> >        I will produce an example if necessary. A workaround is not
> >possible.
>
> >Thanks if anyone can promp help me.
>
> >Best regards
> >Arne Berger
>
> --
> Dr. Douglas C. Schmidt                       Professor and Associate Chair
> Electrical Engineering and Computer Science  TEL: (615) 343-8197
> Vanderbilt University                        WEB:www.dre.vanderbilt.edu/~schmidt
> Nashville, TN 37203                          NET: d.schm... at vanderbilt.edu




More information about the Ace-users mailing list