SourceForge has been redesigned. Learn more.
Close

#26 string init in aggregate

closed-remind
5
2006-03-21
2006-03-02
No

(initiated by trombon:
https://sourceforge.net/forum/message.php?msg_id=3606700\)

This test fail (during memory deallocation):

#include <string>
using namespace std;

const string CON_ONE = "string_1";
const string CON_TWO = "string_2";

struct StrOne
{
string partOne;
string partTwo;
};

#define NUM_PARAMS 2

const StrOne general[NUM_PARAMS] = {
{string(CON_ONE), string(CON_TWO)},
{string(CON_ONE), string(CON_TWO)}
};

int main()
{
// string temp = general[0].partOne;

return 0;
}

Discussion

  • Petr Ovtchenkov

    Petr Ovtchenkov - 2006-03-02
    • status: open --> open-remind
     
  • Petr Ovtchenkov

    Petr Ovtchenkov - 2006-03-02

    Logged In: YES
    user_id=615813

    Not a compiler problem:

    > valgrind --tool=memcheck obj/gcc/shared-stlg/test
    ==22311== Memcheck, a memory error detector for x86-linux.
    ==22311== Copyright (C) 2002-2005, and GNU GPL'd, by
    Julian Seward et al.
    ==22311== Using valgrind-2.4.0, a program supervision
    framework for x86-linux.
    ==22311== Copyright (C) 2000-2005, and GNU GPL'd, by
    Julian Seward et al.
    ==22311== For more details, rerun with: -v
    ==22311==
    A( int )
    A( int )
    A( const A& )
    A( const A& )
    A( const A& )
    A( const A& )
    A( const A& )
    ~A()
    ==22311== Invalid free() / delete / delete[]
    ==22311== at 0x1B901B07: free (vg_replace_malloc.c:152)
    ==22311== by 0x1B9CCA20: operator delete(void*)
    (../../.././libstdc++-v3/libsupc++/del_op.cc:40)
    ==22311== by 0x804C280: stlpd_std::__stl_delete(void*)
    (/export/home/ptr/STLport.lab/STLport/stlport/stl/_new.h:92)
    ==22311== by 0x804C1C1: stlpd_std::__node_alloc<true,
    0>::deallocate(void*, unsigned)
    (/export/home/ptr/STLport.lab/STLport/stlport/stl/_alloc.h:311)
    ==22311== by 0x804C1A5:
    stlpd_std::allocator<char>::deallocate(char*, unsigned)
    (/export/home/ptr/STLport.lab/STLport/stlport/stl/_alloc.h:480)
    ==22311== by 0x804C14E: stlpd_std::_String_base<char,
    stlpd_std::allocator<char> >::_M_deallocate_block()
    (/export/home/ptr/STLport.lab/STLport/stlport/stl/_string_base.h:89)
    ==22311== by 0x804C0B7: stlpd_std::_String_base<char,
    stlpd_std::allocator<char> >::~_String_base()
    (/export/home/ptr/STLport.lab/STLport/stlport/stl/_string_base.h:143)
    ==22311== by 0x804C09F: stlpd_std::_NonDbg_str<char,
    stlpd_std::char_traits<char>, stlpd_std::allocator<char>
    >::~_NonDbg_str()
    (/export/home/ptr/STLport.lab/STLport/stlport/stl/_string.h:314)
    ==22311== by 0x804C04A: stlpd_std::basic_string<char,
    stlpd_std::char_traits<char>, stlpd_std::allocator<char>
    >::~basic_string()
    (/export/home/ptr/STLport.lab/STLport/stlport/stl/_numpunct.h:63)
    ==22311== by 0x804C5E8: StrOne::~StrOne() (in
    /export/home/ptr/workshop/explore/inquiry/STLport/string-static-array/obj/gcc/shared-stlg/test)
    ==22311== by 0x804B858: __tcf_5 (test.cc:42)
    ==22311== by 0x1BA5BE52: exit (in /lib/libc-2.2.5.so)
    ==22311== Address 0x69727473 is not stack'd, malloc'd or
    (recently) free'd
    ~A()
    ~A()
    ~A()
    ~A()
    ~A()
    ~A()
    ==22311==
    ==22311== ERROR SUMMARY: 4 errors from 1 contexts
    (suppressed: 5 from 2)
    ==22311== malloc/free: in use at exit: 136 bytes in 2 blocks.
    ==22311== malloc/free: 42 allocs, 44 frees, 8408 bytes
    allocated.
    ==22311== For counts of detected errors, rerun with: -v
    ==22311== searching for pointers to 2 not-freed blocks.
    ==22311== checked 258184 bytes.
    ==22311==
    ==22311== LEAK SUMMARY:
    ==22311== definitely lost: 0 bytes in 0 blocks.
    ==22311== possibly lost: 0 bytes in 0 blocks.
    ==22311== still reachable: 136 bytes in 2 blocks.
    ==22311== suppressed: 0 bytes in 0 blocks.
    ==22311== Reachable blocks (those to which a pointer was
    found) are not shown.
    ==22311== To see them, rerun with: --show-reachable=yes

    but with libcstd++:

    > valgrind --tool=memcheck obj/gcc/shared-g/test
    ==22512== Memcheck, a memory error detector for x86-linux.
    ==22512== Copyright (C) 2002-2005, and GNU GPL'd, by
    Julian Seward et al.
    ==22512== Using valgrind-2.4.0, a program supervision
    framework for x86-linux.
    ==22512== Copyright (C) 2000-2005, and GNU GPL'd, by
    Julian Seward et al.
    ==22512== For more details, rerun with: -v
    ==22512==
    A( int )
    A( int )
    A( const A& )
    A( const A& )
    A( const A& )
    A( const A& )
    A( const A& )
    ~A()
    ~A()
    ~A()
    ~A()
    ~A()
    ~A()
    ~A()
    ==22512==
    ==22512== ERROR SUMMARY: 0 errors from 0 contexts
    (suppressed: 5 from 2)
    ==22512== malloc/free: in use at exit: 136 bytes in 2 blocks.
    ==22512== malloc/free: 5 allocs, 3 frees, 180 bytes allocated.
    ==22512== For counts of detected errors, rerun with: -v
    ==22512== searching for pointers to 2 not-freed blocks.
    ==22512== checked 233608 bytes.
    ==22512==
    ==22512== LEAK SUMMARY:
    ==22512== definitely lost: 0 bytes in 0 blocks.
    ==22512== possibly lost: 0 bytes in 0 blocks.
    ==22512== still reachable: 136 bytes in 2 blocks.
    ==22512== suppressed: 0 bytes in 0 blocks.
    ==22512== Reachable blocks (those to which a pointer was
    found) are not shown.
    ==22512== To see them, rerun with: --show-reachable=yes

     
  • Petr Ovtchenkov

    Petr Ovtchenkov - 2006-03-10

    minimal test

     
  • Petr Ovtchenkov

    Petr Ovtchenkov - 2006-03-10

    Logged In: YES
    user_id=615813

    Minimal test added, see attached files here.

     
  • Petr Ovtchenkov

    Petr Ovtchenkov - 2006-03-10

    Logged In: YES
    user_id=615813

    The reason of crash is attempt to deallocate block that was
    never allocated in

    void _M_deallocate_block() (_string_base.h)

    The buffer is really _M_buffers._M_static_buf and contain
    valid string 'string_1' as expected (see attached test.cc).
    But why it treated as allocated in heap here?

     
  • tr0mbone

    tr0mbone - 2006-03-20

    Logged In: YES
    user_id=1465778

    Sorry about the long reply time. Personal reasons.

    The test program I wrote, as well as the test.cc program
    demonstrate the bug that I found when I tried to use the
    STLport with our larger software product. I made the proof
    because I can't send you guys internal code.

    We are allocating that array of strings (ours is much, much
    larger) on the stack and can't change our code to work
    around this bug.

    I assumed that since we can do this with the standard C++
    template library, we should be able to do it with the STLport.

    Good luck, if you have any questions, please ask. But I
    believe the proof programs should be enough.

     
  • Petr Ovtchenkov

    Petr Ovtchenkov - 2006-03-20
     
  • Petr Ovtchenkov

    Petr Ovtchenkov - 2006-03-20

    Logged In: YES
    user_id=615813

    not a bug in STLport, but bug in gcc (at least in 3.4.4). I
    will contact with gcc team ASAP. See test-rep.cc, that give
    something like

    0x8049b1c 0x8049b18
    -- 0
    0xbfd9a6a8 0xbfd9a6a4 // <----! 'this' and address of
    buff differ in constructor and destructor!
    0xbfd9a6b8 0xbfd9a6b4 // <----!
    -- 1
    0xbfd9a6a8 0xbfd9a6a4
    0xbfd9a6a8 0xbfd9a6a4
    -- 2
    0x8049b1c 0x8049b18

     
  • Petr Ovtchenkov

    Petr Ovtchenkov - 2006-03-21

    Logged In: YES
    user_id=615813

    Bug in Gcc:

    ------- Comment #1 from pinskia at gcc dot gnu dot org
    2006-03-20 22:35 -------
    Fixed in 4.0.0, 3.4.6 was the last release of 3.4.x.

    --

    pinskia at gcc dot gnu dot org changed:

    What |Removed |Added
    ----------------------------------------------------------------------------
    Status|UNCONFIRMED |RESOLVED
    Keywords| |wrong-code
    Known to fail| |3.0.4
    3.4.0 3.3.3
    Known to work| |2.95.3
    4.1.0 4.2.0 4.0.0
    Resolution| |FIXED
    Summary|array initialization |[3.4
    Regression] array
    | |
    initialization
    Target Milestone|--- |4.0.0

    http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26773

     
  • Petr Ovtchenkov

    Petr Ovtchenkov - 2006-03-21
    • status: open-remind --> closed-remind
     

Log in to post a comment.