stdcxx-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Sebor (JIRA)" <j...@apache.org>
Subject [jira] Commented: (STDCXX-87) [Sun C++ 5.9] RUI in std::set::insert()
Date Fri, 21 Mar 2008 01:23:24 GMT

    [ https://issues.apache.org/jira/browse/STDCXX-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580978#action_12580978
] 

Martin Sebor commented on STDCXX-87:
------------------------------------

I believe the RUI is due to a bug in the compiler (or dbx).

Here's a test case that reproduces the RUI using an explicit specialization of {{std::pair}}:

{noformat}
$ cat t.cpp && gmake t CPPOPTS=-D_RWSTD_NO_DEBUG_ITER LDOPTS=-g && dbx -q
t
#include <cassert>
#include <set>

typedef __rw::__ident<int, int> Ident;
typedef std::less<int> Less;
typedef std::allocator<int> Allocator;
typedef __rw::__rb_tree<int, int, Ident, Less, Allocator> Tree;

namespace std {

template <>
struct pair<Tree::iterator, bool> {
    typedef Tree::iterator first_type;
    typedef bool second_type;

    first_type first;
    second_type second;

    pair (): first (), second () { }

    pair (const first_type &x, const second_type &y)
        : first (x), second (y) { }

    template <class T, class U>
    pair (const pair <T, U> &rhs)
        : first (rhs.first), second (rhs.second) { }

#ifdef EXPLICIT_ASSIGNMENT
    pair& operator= (const pair &rhs) {
        first = rhs.first;
        second = rhs.second;
        return *this;
    }
#endif

};

}


int main ()
{
    Tree x;

    std::pair<Tree::iterator, bool> ret;

    x._C_insert (0, ret, false);

    assert (1 == x.size ());
}
CC -c -D_RWSTDDEBUG -mt -I/amd/devco/sebor/stdcxx/include -I/build/sebor/stdcxx-suncc-5.9-j1-15d/include
-I/amd/devco/sebor/stdcxx/examples/include -D_RWSTD_NO_DEBUG_ITER -library=%none -g +w -errtags
-erroff=hidef t.cpp
CC t.o -o t -library=%none -mt -L/build/sebor/stdcxx-suncc-5.9-j1-15d/lib -g -R/build/sebor/stdcxx-suncc-5.9-j1-15d/lib
-lstd15d -lm
(dbx) check -access
access checking - ON
(dbx) run
Running: t
(process id 13353)
RTC: Enabling Error Checking...
RTC: Running program...
Read from uninitialized (rui) on thread 1:
Attempting to read 3 bytes at address 0x80478a1
    which is 69 bytes above the current stack pointer
t@1 (l@1) stopped in std::pair<__rw::__rw_tree_iter<int,int,int*,int&,__rw::__rw_rb_tree_node<std::allocator<int>,int,int,__rw::__ident<int,int>
> >,bool>::operator= at 0x08052e92
0x08052e92: operator=+0x0012: hlt
(dbx) where
current thread: t@1
=>[1] std::pair<__rw::__rw_tree_iter<int,int,int*,int&,__rw::__rw_rb_tree_node<std::allocator<int>,int,int,__rw::__ident<int,int>
> >,bool>::operator=(0x804792c, 0x804789c, 0x8047940, 0xfeffa840, 0x0, 0x8065d30),
at 0x8052e92
  [2] __rw::__rb_tree<int,int,__rw::__ident<int,int>,std::less<int>,std::allocator<int>
>::_C_insert(this = 0x8047938, __v = 0, __ret = STRUCT, __dup = false), line 317 in "_tree.cc"
  [3] main(), line 47 in "t.cpp"
{noformat}

And here's the same test case that runs cleanly in dbx (i.e., with no RUI). The only difference
is that unlike in the first case where the explicitly specialized {{std::pair}} relies on
the compiler generated copy assignment operator, the second case provides an explicit definition
of the copy assignment.

{noformat}
$ gmake t CPPOPTS="-D_RWSTD_NO_DEBUG_ITER -DEXPLICIT_ASSIGNMENT" LDOPTS=-g && dbx
-q t
CC -c -D_RWSTDDEBUG -mt -I/amd/devco/sebor/stdcxx/include -I/build/sebor/stdcxx-suncc-5.9-j1-15d/include
-I/amd/devco/sebor/stdcxx/examples/include -D_RWSTD_NO_DEBUG_ITER -DEXPLICIT_ASSIGNMENT -library=%none
-g +w -errtags -erroff=hidef t.cpp
CC t.o -o t -library=%none -mt -L/build/sebor/stdcxx-suncc-5.9-j1-15d/lib -g -R/build/sebor/stdcxx-suncc-5.9-j1-15d/lib
-lstd15d -lm
(dbx) check -access
access checking - ON
(dbx) run
Running: t
(process id 14472)
RTC: Enabling Error Checking...
RTC: Running program...

execution completed, exit code is 0
{noformat}


> [Sun C++ 5.9] RUI in std::set::insert()
> ---------------------------------------
>
>                 Key: STDCXX-87
>                 URL: https://issues.apache.org/jira/browse/STDCXX-87
>             Project: C++ Standard Library
>          Issue Type: Bug
>          Components: 23. Containers
>    Affects Versions: 4.1.2, 4.1.3, 4.1.4
>         Environment: SunPro 5.7, 5.9/Solaris 10
>            Reporter: Martin Sebor
>            Assignee: Martin Sebor
>             Fix For: 4.2.1
>
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> This test case was distilled from the one posted in this thread:
> http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200512.mbox/%3c4FA4B7B3231C5D459E7BAD020213A94201F5F481@bco-exchange.bco.roguewave.com%3e
> $ cat t.cpp && nice gmake t && dbx -q t
> #include <set>
> int main()
> {
>     std::set<int>().insert (0);
> }
> generating dependencies for t.cpp
> CC -c -D_RWSTDDEBUG    -D_RWSTD_USE_CONFIG -I/build/sebor/sunpro-5.7.j4-11s/include -I/build/sebor/dev/stdlib/include
-I/build/sebor/dev/stdlib/examples/include  -library=%none -g  +w  t.cpp
> CC t.o -o t -library=%none -L/build/sebor/sunpro-5.7.j4-11s/lib   -L/build/sebor/sunpro-5.7.j4-11s/lib
-lstd11s   -lm
> ^C^Chave seen 2 interrupts
> dbx: warning: wait for process 24188 failed -- Interrupted system call
> dbx: dbx interrupted!
> (dbx) check -all
> access checking - ON
> memuse checking - ON
> (dbx) run
> Running: t 
> (process id 24234)
> RTC: Enabling Error Checking...
> RTC: Running program...
> Read from uninitialized (rui):
> Attempting to read 3 bytes at address 0xffbff821
>     which is 265 bytes above the current stack pointer
> stopped in std::pair<__rw::__rw_debug_iter<__rw::__rb_tree<int,int,__rw::__ident<int,int>,std::less<int>,std::allocator<int>
>,__rw::__rw_tree_iter<int,int,int*,int&,__rw::__rw_rb_tree_node<std::allocator<int>,int,int,__rw::__ident<int,int>
> >,__rw::__rw_tree_iter<int,int,int*,int&,__rw::__rw_rb_tree_node<std::allocator<int>,int,int,__rw::__ident<int,int>
> > >,bool>::operator= at 0x0001cd3c
> 0x0001cd3c: operator=+0x0024:   ba,a     0x00049b3c     ! 0x49b3c

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message