Menu
▾
▴
jsoncpp-devel
|
From: Scott S. <sis...@gm...> - 2009-10-14 01:27:42
|
Looks like other.cstr_ should be checked as well.
#0 0x00212bd8 in strcmp () from /lib/libc.so.6
#1 0x0012ed2f in Json::Value::CZString::operator< (this=0x8317300,
other=@0xbfffeeac)
at src/lib_json/json_value.cpp:221
#2 0x001361b0 in std::less<Json::Value::CZString>::operator()
(this=0x83173a0, __x=@0x8317300,
__y=@0xbfffeeac)
at /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/bits/stl_function.h:230
#3 0x00136101 in std::_Rb_tree<Json::Value::CZString,
std::pair<Json::Value::CZString const, Json::Value>,
std::_Select1st<std::pair<Json::Value::CZString const, Json::Value> >,
std::less<Json::Value::CZString>,
std::allocator<std::pair<Json::Value::CZString const, Json::Value> >
>::_M_lower_bound (this=0x83173a0,
__x=0x83172f0, __y=0x83173a4, __k=@0xbfffeeac)
at /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/bits/stl_tree.h:986
#4 0x001348da in std::_Rb_tree<Json::Value::CZString,
std::pair<Json::Value::CZString const, Json::Value>,
std::_Select1st<std::pair<Json::Value::CZString const, Json::Value> >,
std::less<Json::Value::CZString>,
std::allocator<std::pair<Json::Value::CZString const, Json::Value> >
>::find (this=0x83173a0, __k=@0xbfffeeac)
at /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/bits/stl_tree.h:1421
#5 0x0013383a in std::map<Json::Value::CZString, Json::Value,
std::less<Json::Value::CZString>,
std::allocator<std::pair<Json::Value::CZString const, Json::Value> >
>::find (this=0x83173a0, __x=@0xbfffeeac)
at /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/bits/stl_map.h:659
#6 0x00131779 in Json::Value::operator[] (this=0x8317280,
key=0xbfffef74 "col1")
at src/lib_json/json_value.cpp:1055
#7 0x00131ba8 in Json::Value::isMember (this=0x8317280, key=0xbfffef74 "col1")
at src/lib_json/json_value.cpp:1169
#8 0x0805cf4d in CFG::CFG_Fetch_Raw (this=0x825846c,
section=0x8317280, key=0xbfffef74 "col1", defval=0x0)
at CFG.cpp:48
#9 0x08050e5b in Generic::CFGSetup (this=0x825846c, k=0x8255e2c
"display_qt") at Generic.cpp:89
#10 0x0804df6a in LCDControl::ConfigSetup (this=0xbffff2a8) at LCDControl.cpp:81
#11 0x0804d93b in LCDControl::Start (this=0xbffff2a8, argc=1,
argv=0xbffff404) at LCDControl.cpp:15
#12 0x0804f224 in main (argc=1, argv=0xbffff404) at Main.cpp:7
bool
Value::CZString::operator<( const CZString &other ) const
{
if ( cstr_ )
return strcmp( cstr_, other.cstr_ ) < 0; //src/lib_json/json_value.cpp:221
return index_ < other.index_;
}
|
|
From: Scott S. <sis...@gm...> - 2009-10-14 01:42:43
|
I had opened a question about this on Stackoverflow. Someone pointed out
that the other value wasn't being checked, but he followed up with the
following comments later on.
"That's not the problem, however, since other is not null in this case.
Rather it looks like the other object may have been deleted. How are you
managing the lifetimes of the objects in the std::map container? Is it
possible that one of the values was deleted without being removed from the
map?"
On Tue, Oct 13, 2009 at 8:27 PM, Scott Sibley <sis...@gm...> wrote:
> Looks like other.cstr_ should be checked as well.
>
> #0 0x00212bd8 in strcmp () from /lib/libc.so.6
> #1 0x0012ed2f in Json::Value::CZString::operator< (this=0x8317300, other=@0xbfffeeac)
>
> at src/lib_json/json_value.cpp:221
> #2 0x001361b0 in std::less<Json::Value::CZString>::operator() (this=0x83173a0, __x=@0x8317300,
> __y=@0xbfffeeac)
>
> at /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/bits/stl_function.h:230
> #3 0x00136101 in std::_Rb_tree<Json::Value::CZString, std::pair<Json::Value::CZString const, Json::Value>, std::_Select1st<std::pair<Json::Value::CZString const, Json::Value> >, std::less<Json::Value::CZString>, std::allocator<std::pair<Json::Value::CZString const, Json::Value> > >::_M_lower_bound (this=0x83173a0,
>
> __x=0x83172f0, __y=0x83173a4, __k=@0xbfffeeac)
>
> at /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/bits/stl_tree.h:986
> #4 0x001348da in std::_Rb_tree<Json::Value::CZString, std::pair<Json::Value::CZString const, Json::Value>, std::_Select1st<std::pair<Json::Value::CZString const, Json::Value> >, std::less<Json::Value::CZString>, std::allocator<std::pair<Json::Value::CZString const, Json::Value> > >::find (this=0x83173a0, __k=@0xbfffeeac)
>
> at /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/bits/stl_tree.h:1421
> #5 0x0013383a in std::map<Json::Value::CZString, Json::Value, std::less<Json::Value::CZString>, std::allocator<std::pair<Json::Value::CZString const, Json::Value> > >::find (this=0x83173a0, __x=@0xbfffeeac)
>
> at /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/bits/stl_map.h:659
> #6 0x00131779 in Json::Value::operator[] (this=0x8317280, key=0xbfffef74 "col1")
> at src/lib_json/json_value.cpp:1055
> #7 0x00131ba8 in Json::Value::isMember (this=0x8317280, key=0xbfffef74 "col1")
> at src/lib_json/json_value.cpp:1169
> #8 0x0805cf4d in CFG::CFG_Fetch_Raw (this=0x825846c, section=0x8317280, key=0xbfffef74 "col1", defval=0x0)
> at CFG.cpp:48
> #9 0x08050e5b in Generic::CFGSetup (this=0x825846c, k=0x8255e2c "display_qt") at Generic.cpp:89
> #10 0x0804df6a in LCDControl::ConfigSetup (this=0xbffff2a8) at LCDControl.cpp:81
> #11 0x0804d93b in LCDControl::Start (this=0xbffff2a8, argc=1, argv=0xbffff404) at LCDControl.cpp:15
> #12 0x0804f224 in main (argc=1, argv=0xbffff404) at Main.cpp:7
>
> bool
> Value::CZString::operator<( const CZString &other ) const
> {
> if ( cstr_ )
>
> return strcmp( cstr_, other.cstr_ ) < 0; //src/lib_json/json_value.cpp:221
>
> return index_ < other.index_;
> }
>
>
|
|
From: Scott S. <sis...@gm...> - 2009-10-14 05:43:14
|
Turns out this was my fault. I freed a pointer in the wrong scope, which on
the next pass was garbage.
On Tue, Oct 13, 2009 at 8:35 PM, Scott Sibley <sis...@gm...> wrote:
> I had opened a question about this on Stackoverflow. Someone pointed out
> that the other value wasn't being checked, but he followed up with the
> following comments later on.
>
> "That's not the problem, however, since other is not null in this case.
> Rather it looks like the other object may have been deleted. How are you
> managing the lifetimes of the objects in the std::map container? Is it
> possible that one of the values was deleted without being removed from the
> map?"
>
>
> On Tue, Oct 13, 2009 at 8:27 PM, Scott Sibley <sis...@gm...> wrote:
>
>> Looks like other.cstr_ should be checked as well.
>>
>> #0 0x00212bd8 in strcmp () from /lib/libc.so.6
>> #1 0x0012ed2f in Json::Value::CZString::operator< (this=0x8317300, other=@0xbfffeeac)
>>
>>
>> at src/lib_json/json_value.cpp:221
>> #2 0x001361b0 in std::less<Json::Value::CZString>::operator() (this=0x83173a0, __x=@0x8317300,
>> __y=@0xbfffeeac)
>>
>> at /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/bits/stl_function.h:230
>>
>> #3 0x00136101 in std::_Rb_tree<Json::Value::CZString, std::pair<Json::Value::CZString const, Json::Value>, std::_Select1st<std::pair<Json::Value::CZString const, Json::Value> >, std::less<Json::Value::CZString>, std::allocator<std::pair<Json::Value::CZString const, Json::Value> > >::_M_lower_bound (this=0x83173a0,
>>
>>
>> __x=0x83172f0, __y=0x83173a4, __k=@0xbfffeeac)
>>
>> at /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/bits/stl_tree.h:986
>>
>> #4 0x001348da in std::_Rb_tree<Json::Value::CZString, std::pair<Json::Value::CZString const, Json::Value>, std::_Select1st<std::pair<Json::Value::CZString const, Json::Value> >, std::less<Json::Value::CZString>, std::allocator<std::pair<Json::Value::CZString const, Json::Value> > >::find (this=0x83173a0, __k=@0xbfffeeac)
>>
>>
>> at /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/bits/stl_tree.h:1421
>>
>> #5 0x0013383a in std::map<Json::Value::CZString, Json::Value, std::less<Json::Value::CZString>, std::allocator<std::pair<Json::Value::CZString const, Json::Value> > >::find (this=0x83173a0, __x=@0xbfffeeac)
>>
>>
>> at /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/bits/stl_map.h:659
>>
>> #6 0x00131779 in Json::Value::operator[] (this=0x8317280, key=0xbfffef74 "col1")
>> at src/lib_json/json_value.cpp:1055
>>
>> #7 0x00131ba8 in Json::Value::isMember (this=0x8317280, key=0xbfffef74 "col1")
>> at src/lib_json/json_value.cpp:1169
>>
>> #8 0x0805cf4d in CFG::CFG_Fetch_Raw (this=0x825846c, section=0x8317280, key=0xbfffef74 "col1", defval=0x0)
>> at CFG.cpp:48
>>
>> #9 0x08050e5b in Generic::CFGSetup (this=0x825846c, k=0x8255e2c "display_qt") at Generic.cpp:89
>> #10 0x0804df6a in LCDControl::ConfigSetup (this=0xbffff2a8) at LCDControl.cpp:81
>>
>> #11 0x0804d93b in LCDControl::Start (this=0xbffff2a8, argc=1, argv=0xbffff404) at LCDControl.cpp:15
>> #12 0x0804f224 in main (argc=1, argv=0xbffff404) at Main.cpp:7
>>
>>
>> bool
>> Value::CZString::operator<( const CZString &other ) const
>>
>> {
>> if ( cstr_ )
>>
>> return strcmp( cstr_, other.cstr_ ) < 0; //src/lib_json/json_value.cpp:221
>>
>>
>> return index_ < other.index_;
>> }
>>
>>
>
|
|
From: Baptiste L. <bl...@us...> - 2009-10-15 07:43:59
|
This is strange. The only way other.c_str_ can be null is for other to be an array index:
Value::CZString::CZString( int index )
: cstr_( 0 )
, index_( index )
{
}
But trying to access an objectValue or an arrayValue with the "wrong" type should be detected before we even go to the comparison level:
Value &
Value::operator[]( const char *key )
{
return resolveReference( key, false );
}
Value &
Value::resolveReference( const char *key,
bool isStatic )
{
JSON_ASSERT( type_ == nullValue || type_ == objectValue );
Do you have any idea what is content of you value and what access you are doing?
----- Original Message -----
From: Scott Sibley
To: jso...@li...
Sent: Wednesday 14 October 2009 03:27
Subject: [Jsoncpp-devel] Bug?
Looks like other.cstr_ should be checked as well.#0 0x00212bd8 in strcmp () from /lib/libc.so.6#1 0x0012ed2f in Json::Value::CZString::operator< (this=0x8317300, other=@0xbfffeeac)
at src/lib_json/json_value.cpp:221
#2 0x001361b0 in std::less<Json::Value::CZString>::operator() (this=0x83173a0, __x=@0x8317300, __y=@0xbfffeeac)
at /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/bits/stl_function.h:230
#3 0x00136101 in std::_Rb_tree<Json::Value::CZString, std::pair<Json::Value::CZString const, Json::Value>, std::_Select1st<std::pair<Json::Value::CZString const, Json::Value> >, std::less<Json::Value::CZString>, std::allocator<std::pair<Json::Value::CZString const, Json::Value> > >::_M_lower_bound (this=0x83173a0,
__x=0x83172f0, __y=0x83173a4, __k=@0xbfffeeac)
at /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/bits/stl_tree.h:986
#4 0x001348da in std::_Rb_tree<Json::Value::CZString, std::pair<Json::Value::CZString const, Json::Value>, std::_Select1st<std::pair<Json::Value::CZString const, Json::Value> >, std::less<Json::Value::CZString>, std::allocator<std::pair<Json::Value::CZString const, Json::Value> > >::find (this=0x83173a0, __k=@0xbfffeeac)
at /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/bits/stl_tree.h:1421
#5 0x0013383a in std::map<Json::Value::CZString, Json::Value, std::less<Json::Value::CZString>, std::allocator<std::pair<Json::Value::CZString const, Json::Value> > >::find (this=0x83173a0, __x=@0xbfffeeac)
at /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/bits/stl_map.h:659
#6 0x00131779 in Json::Value::operator[] (this=0x8317280, key=0xbfffef74 "col1") at src/lib_json/json_value.cpp:1055
#7 0x00131ba8 in Json::Value::isMember (this=0x8317280, key=0xbfffef74 "col1") at src/lib_json/json_value.cpp:1169
#8 0x0805cf4d in CFG::CFG_Fetch_Raw (this=0x825846c, section=0x8317280, key=0xbfffef74 "col1", defval=0x0) at CFG.cpp:48
#9 0x08050e5b in Generic::CFGSetup (this=0x825846c, k=0x8255e2c "display_qt") at Generic.cpp:89#10 0x0804df6a in LCDControl::ConfigSetup (this=0xbffff2a8) at LCDControl.cpp:81
#11 0x0804d93b in LCDControl::Start (this=0xbffff2a8, argc=1, argv=0xbffff404) at LCDControl.cpp:15#12 0x0804f224 in main (argc=1, argv=0xbffff404) at Main.cpp:7
boolValue::CZString::operator<( const CZString &other ) const
{ if ( cstr_ )
return strcmp( cstr_, other.cstr_ ) < 0; //src/lib_json/json_value.cpp:221
return index_ < other.index_;
}
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
------------------------------------------------------------------------------
_______________________________________________
Jsoncpp-devel mailing list
Jso...@li...
https://lists.sourceforge.net/lists/listinfo/jsoncpp-devel
|
|
From: Scott S. <sis...@gm...> - 2009-10-15 07:52:25
|
I figured it out. I had deleted the root object. I left a comment in the
code below explaining.
for(unsigned int row = 0; row < LROWS; row++ ) {
sprintf(str, "row%d", row);
Json::Value *cfg_row = CFG_Fetch_Raw(layout, (const char*)str);
if(!cfg_row)
continue;
for(unsigned int col = 0; col < LCOLS; col++ ) {
sprintf(str, "col%d", col);
Json::Value *cfg_col = CFG_Fetch_Raw(cfg_row, (const
char*)str);
if(!cfg_col || !cfg_col->isString()) {
// right here I had deleted cfg_row, so the next pass
gave CFG_Fetch_Raw garbage for its root Json::Value.
// The first step CFG_Fetch_Raw does is to check if str
is a member of cfg_row. That's where the crash came in.
if(cfg_col) delete cfg_col;
continue;
}
//std::cout << cfg_col->asCString() << std::endl;
widget_template w = widget_template();
w.key = (char *)malloc(cfg_col->asString().size() + 1);
memcpy((void *)w.key, (void *)const_cast<char
*>(cfg_col->asCString()),
cfg_col->asString().capacity() + 1);
w.row = row;
w.col = col;
widget_templates[layouts[i]].push_back(w);
delete cfg_col;
}
delete cfg_row;
}
On Thu, Oct 15, 2009 at 2:43 AM, Baptiste Lepilleur <
bl...@us...> wrote:
> This is strange. The only way other.c_str_ can be null is for other to be
> an array index:
>
> Value::CZString::CZString( int index )
>
> : cstr_( 0 )
>
> , index_( index )
>
> {
>
> }
>
>
>
> But trying to access an objectValue or an arrayValue with the "wrong" type
> should be detected before we even go to the comparison level:
>
> Value &
>
> Value::operator[]( const char *key )
>
> {
>
> return resolveReference( key, false );
>
> }
>
>
>
>
>
> Value &
>
> Value::resolveReference( const char *key,
>
> bool isStatic )
>
> {
>
> *JSON_ASSERT( type_ == nullValue || type_ == objectValue );*
>
>
>
> Do you have any idea what is content of you value and what access you are
> doing?
>
>
>
> ----- Original Message -----
> *From:* Scott Sibley <sis...@gm...>
> *To:* jso...@li...
> *Sent:* Wednesday 14 October 2009 03:27
> *Subject:* [Jsoncpp-devel] Bug?
>
> Looks like other.cstr_ should be checked as well.
>
> #0 0x00212bd8 in strcmp () from /lib/libc.so.6
> #1 0x0012ed2f in Json::Value::CZString::operator< (this=0x8317300, other=@0xbfffeeac)
>
> at src/lib_json/json_value.cpp:221
> #2 0x001361b0 in std::less<Json::Value::CZString>::operator() (this=0x83173a0, __x=@0x8317300,
> __y <__y=@0xbfffeeac>=@0xbfffeeac)
>
> at /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/bits/stl_function.h:230
> #3 0x00136101 in std::_Rb_tree<Json::Value::CZString, std::pair<Json::Value::CZString const, Json::Value>, std::_Select1st<std::pair<Json::Value::CZString const, Json::Value> >, std::less<Json::Value::CZString>, std::allocator<std::pair<Json::Value::CZString const, Json::Value> > >::_M_lower_bound (this=0x83173a0,
>
> __x=0x83172f0, __y=0x83173a4, __k=@0xbfffeeac)
>
> at /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/bits/stl_tree.h:986
> #4 0x001348da in std::_Rb_tree<Json::Value::CZString, std::pair<Json::Value::CZString const, Json::Value>, std::_Select1st<std::pair<Json::Value::CZString const, Json::Value> >, std::less<Json::Value::CZString>, std::allocator<std::pair<Json::Value::CZString const, Json::Value> > >::find (this=0x83173a0, __k=@0xbfffeeac)
>
> at /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/bits/stl_tree.h:1421
> #5 0x0013383a in std::map<Json::Value::CZString, Json::Value, std::less<Json::Value::CZString>, std::allocator<std::pair<Json::Value::CZString const, Json::Value> > >::find (this=0x83173a0, __x=@0xbfffeeac)
>
> at /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/bits/stl_map.h:659
> #6 0x00131779 in Json::Value::operator[] (this=0x8317280, key=0xbfffef74 "col1")
> at src/lib_json/json_value.cpp:1055
> #7 0x00131ba8 in Json::Value::isMember (this=0x8317280, key=0xbfffef74 "col1")
> at src/lib_json/json_value.cpp:1169
> #8 0x0805cf4d in CFG::CFG_Fetch_Raw (this=0x825846c, section=0x8317280, key=0xbfffef74 "col1", defval=0x0)
> at CFG.cpp:48
> #9 0x08050e5b in Generic::CFGSetup (this=0x825846c, k=0x8255e2c "display_qt") at Generic.cpp:89
> #10 0x0804df6a in LCDControl::ConfigSetup (this=0xbffff2a8) at LCDControl.cpp:81
> #11 0x0804d93b in LCDControl::Start (this=0xbffff2a8, argc=1, argv=0xbffff404) at LCDControl.cpp:15
> #12 0x0804f224 in main (argc=1, argv=0xbffff404) at Main.cpp:7
>
> bool
> Value::CZString::operator<( const CZString &other ) const
> {
> if ( cstr_ )
>
> return strcmp( cstr_, other.cstr_ ) < 0; //src/lib_json/json_value.cpp:221
>
> return index_ < other.index_;
> }
>
> ------------------------------
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
>
> ------------------------------
>
> _______________________________________________
> Jsoncpp-devel mailing list
> Jso...@li...
> https://lists.sourceforge.net/lists/listinfo/jsoncpp-devel
>
>
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X