[Ace-users] Re: [tao-bugs] run out of memory caused by bounded
recursive sequence
Johnny Willemsen
jwillemsen at remedy.nl
Mon Aug 13 04:40:45 CDT 2007
Hi,
Please file the regression test with all the details to bugzilla, (see
http://deuce.doc.wustl.edu/bugzilla/index.cgi)
Johnny
> -----Original Message-----
> From: Stanislaw Trytek [mailto:tryteks at pit.edu.pl]
> Sent: Monday, August 13, 2007 11:25 AM
> To: Johnny Willemsen
> Cc: tao-bugs at cs.wustl.edu
> Subject: Re: [tao-bugs] run out of memory caused by bounded
> recursive sequence
>
> Hi,
> Thank you for quick reply.
> I have done another test
>
> typedef sequence<octet, 8192> ValueContent;
> struct Node {
> sequence <ValueContent, 2560000> nodes;
> };
>
>
> At the creation time it does not crash but uses up all memory
> resources.
> You are right, it seems that bounded sequences are allocated
> up to the
> maximum limit (declared in IDL), no matter what is the lenght of the
> sequence. Having many large bounded sequences can cause
> serious problem.
>
> > anywhere in TAO at this moment. Please deliver a test program as
> > reproducer
> You mean I should mail the test to tao-bugs at cs.wustl.edu?
> Regards,
> Stanislaw Trytek
>
>
>
> On Mon, 13 Aug 2007 10:22:38 +0200, Johnny Willemsen
> <jwillemsen at remedy.nl> wrote:
>
> > Hi,
> >
> > Having looked briefly at the code, it looks like the
> bounded sequences do
> > allocate the data for all its values at creation time, with
> a recursive
> > definition this then leads to a stack recursion. This seems
> not to be
> > tested
> > anywhere in TAO at this moment. Please deliver a test program as
> > reproducer
> > (extend one of the existing ones) and file this problem in
> bugzilla (see
> > http://deuce.doc.wustl.edu/bugzilla/index.cgi). We welcome
> patches to fix
> > this issue.
> >
> > Regards,
> >
> > Johnny Willemsen
> > Remedy IT
> > Postbus 101
> > 2650 AC Berkel en Rodenrijs
> > The Netherlands
> > www.theaceorb.nl / www.remedy.nl
> >
> > *** Integrated compile and test statistics see
> > http://scoreboard.theaceorb.nl ***
> > *** Commercial service and support for ACE/TAO/CIAO ***
> > *** See http://www.theaceorb.nl/en/support.html ***
> >
> > "Stanislaw Trytek" <tryteks at pit.edu.pl> wrote in message
> > news:<mailman.1794.1186991942.5286.tao-bugs at mail.cse.wustl.edu>...
> >>
> >> TAO VERSION: 1.5.10
> >> ACE VERSION: 5.5.10
> >>
> >> HOST MACHINE and OPERATING SYSTEM:
> >> linux debian sarge
> >>
> >> COMPILER NAME AND VERSION (AND PATCHLEVEL): gcc-3.3
> >>
> >> THE $ACE_ROOT/include/makeinclude/platform_macros.GNU FILE
> >> threads = 0
> >>
> >> AREA/CLASS/EXAMPLE AFFECTED:
> >> bounded sequence
> >>
> >>
> >> DOES THE PROBLEM AFFECT:
> >> EXECUTION
> >>
> >> SYNOPSIS:
> >> Definition of bounded recursive sequence causes
> segmentation fault
> >>
> >> DESCRIPTION:
> >> We are moving from x.4.2 version to 5.5.10 and have encountered
> > strange
> >> behaviour.
> >> The problem concerns only bounded sequences ( unbounded
> work fine).
> > This
> >> new feature because
> >> in version x.4.2 it worked fine. Has something changed
> in this case?
> >>
> >> This is simple idl file to picture the problem:
> >> __________________________________
> >> module Test{
> >> struct Node {
> >> sequence <Node, 256> nodes;
> >> };
> >>
> >> }
> >> __________________________________
> >>
> >>
> >> As defined
> >>
> >> Test::Node node;
> >>
> >> it tries to allocate recursively the whole memory, so
> that finally
> > it
> >> runs out of memory and causes segmentation fault.
> >>
> >> That is gdb output:
> >> (gdb) where
> >> #0 0x4051883f in mallopt () from /lib/tls/libc.so.6
> >> #1 0x40517c43 in malloc () from /lib/tls/libc.so.6
> >> #2 0x404532fe in operator new () from /usr/lib/libstdc++.so.5
> >> #3 0x4045342f in operator new[] () from /usr/lib/libstdc++.so.5
> >> #4 0x4002e8ad in _tao_seq_Test_Node__256 (this=0x300c58fc) at
> >> Bounded_Value_Allocation_Traits_T.h:39
> >> #5 0x4002e8c8 in _tao_seq_Test_Node__256 (this=0x300c44f4) at
> >> Bounded_Value_Allocation_Traits_T.h:40
> >> #6 0x4002e8c8 in _tao_seq_Test_Node__256 (this=0x300c30ec) at
> >> Bounded_Value_Allocation_Traits_T.h:40
> >> #7 0x4002e8c8 in _tao_seq_Test_Node__256 (this=0x300c1ce4) at
> >> Bounded_Value_Allocation_Traits_T.h:40
> >> #8 0x4002e8c8 in _tao_seq_Test_Node__256 (this=0x300c08dc) at
> >> Bounded_Value_Allocation_Traits_T.h:40
> >> #9 0x4002e8c8 in _tao_seq_Test_Node__256 (this=0x300bf4d4) at
> >> Bounded_Value_Allocation_Traits_T.h:40
> >> #10 0x4002e8c8 in _tao_seq_Test_Node__256 (this=0x300be0cc) at
> >> Bounded_Value_Allocation_Traits_T.h:40
> >> #11 0x4002e8c8 in _tao_seq_Test_Node__256 (this=0x300bccc4) at
> >> Bounded_Value_Allocation_Traits_T.h:40
> >> #12 0x4002e8c8 in _tao_seq_Test_Node__256 (this=0x300bb8bc) at
> >> Bounded_Value_Allocation_Traits_T.h:40
> >> #13 0x4002e8c8 in _tao_seq_Test_Node__256 (this=0x300ba4b4) at
> >> Bounded_Value_Allocation_Traits_T.h:40
> >> #14 0x4002e8c8 in _tao_seq_Test_Node__256 (this=0x300b90ac) at
> >> Bounded_Value_Allocation_Traits_T.h:40
> >> #15 0x4002e8c8 in _tao_seq_Test_Node__256 (this=0x300b7ca4) at
> >> Bounded_Value_Allocation_Traits_T.h:40
> >> #16 0x4002e8c8 in _tao_seq_Test_Node__256 (this=0x300b689c) at
> >> Bounded_Value_Allocation_Traits_T.h:40
> >> #17 0x4002e8c8 in _tao_seq_Test_Node__256 (this=0x300b5494) at
> >> Bounded_Value_Allocation_Traits_T.h:40
> >> #18 0x4002e8c8 in _tao_seq_Test_Node__256 (this=0x300b408c) at
> >> Bounded_Value_Allocation_Traits_T.h:40
> >> etc. .........
> >>
> >>
> >> Stanislaw Trytek
> >>
> >> --
> >> _________________________________________
> >> PRZEMYSLOWY INSTYTUT TELEKOMUNIKACJI
> >> TELECOMMUNICATIONS RESEARCH INSTITUTE
> >> ul. Poligonowa 30, 04-051 Warszawa, Poland
> >> tel: +48 (22) 48 65 232
> >> fax: +48 (22) 48 65 494
> >> e-mail: tryteks at pit.edu.pl
> >>
> >
>
>
>
> --
> _________________________________________
> PRZEMYSŁOWY INSTYTUT TELEKOMUNIKACJI
> TELECOMMUNICATIONS RESEARCH INSTITUTE
> ul. Poligonowa 30, 04-051 Warszawa, Poland
> tel: +48 (22) 48 65 232
> fax: +48 (22) 48 65 494
> e-mail: tryteks at pit.edu.pl
>
More information about the Ace-users
mailing list