Re: Crash in ostream <

[Dimitry Andric]

On 15 Mar 2016, at 21:50, Willem Jan Withagen  wrote:
> 
> On 15-3-2016 19:52, Dimitry Andric wrote:
...
Most likely a bug in the Ceph code.  Try figuring out where the NULL
>> pointer originally came from.
> 
> I've started with compiling wit -O0 but that probably will still inline
> the pieces of code designated as such. Otherwise I'll have to resort to
> inserting asserts.
> 
> I'm now using gdb 7.1, loading lldb gives me a sort of strange
> commandline that looks like utf-8-ish???
> Would lldb give better analysis of the structures?

Maybe, but compiling at least some files with -O0 might help.  With
regards to the weird keyboard input, this was a problem (or bad side
effect) of a recent libedit import, in r296175.  Pedro Giffuni rolled it
back in r296435, after that lldb's line editor should work OK again.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Crash in ostream <

[Willem Jan Withagen]

On 15-3-2016 19:52, Dimitry Andric wrote:
> On 15 Mar 2016, at 12:41, Willem Jan Withagen  wrote:
>>
>> While running Ceph tools I get a crash in
>> fr 10
>> #10 0x016d82ca in FileStore::omap_get_values(coll_t const&, 
>> ghobject_t const&, std::__1::set> std::__1::char_traits, std::__1::allocator >, 
>> std::__1::less> std::__1::allocator > >, 
>> std::__1::allocator> std::__1::char_traits, std::__1::allocator > > > const&, 
>> std::__1::map> std::__1::allocator >, ceph::buffer::list, 
>> std::__1::less> std::__1::allocator > >, 
>> std::__1::allocator> std::__1::char_traits, std::__1::allocator > const, 
>> ceph::buffer::list> > >*) ()
>> (gdb) l
>> 95  int preload_erasure_code()
>> 96  {
>> 97string plugins = g_conf->osd_erasure_code_plugins;
>> 98stringstream ss;
>> 99int r = ErasureCodePluginRegistry::instance().preload(
>> 100 plugins,
>> 101 g_conf->erasure_code_dir,
>> 102 );
>> 103   if (r)
>> 104 derr << ss.str() << dendl;
>> (gdb)
>> 105   else
>> 106 dout(10) << ss.str() << dendl;
>> 107   return r;
>> 108 }
>> 109
>>
>> All of this seems to be inlined since I'm not able to get at ss or r
>>
>>
>> #8  0x00e16145 in std::__1::char_traits::length (__s=0x0) at 
>> /usr/include/c++/v1/string:640
>> 640 static inline size_t length(const char_type* __s) {return 
>> strlen(__s);}
> 
> What happened here is that something attempted to initialize a
> std::string with a NULL pointer, and that isn't allowed.  As you saw in
> the debugger, the constructor just runs strlen() on the incoming string,
> and that will segfault.
> 
> 
>> Looking at the strlen implementation in
>>/usr/srcs/head/src/lib/libc/string/strlen.c
>>
>> shows that strlen does not take 0x0 as pointer, so when we get here with __s 
>> = 0x0 all is lost.
>> So I tried running it through 3.7, but since this is in the libraries with 
>> the bintools/os, I'd expect
>> both versions to crash on this.
>>
>> Now the question I have to solve:
>>  is it the compiler/toolset/libraries
>>  is it a bug in the ceph code.
> 
> Most likely a bug in the Ceph code.  Try figuring out where the NULL
> pointer originally came from.

I've started with compiling wit -O0 but that probably will still inline
the pieces of code designated as such. Otherwise I'll have to resort to
inserting asserts.

I'm now using gdb 7.1, loading lldb gives me a sort of strange
commandline that looks like utf-8-ish???
Would lldb give better analysis of the structures?

--WjW


___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Crash in ostream <

[Dimitry Andric]

On 15 Mar 2016, at 12:41, Willem Jan Withagen  wrote:
> 
> While running Ceph tools I get a crash in
> fr 10
> #10 0x016d82ca in FileStore::omap_get_values(coll_t const&, 
> ghobject_t const&, std::__1::set std::__1::char_traits, std::__1::allocator >, 
> std::__1::less std::__1::allocator > >, 
> std::__1::allocator std::__1::allocator > > > const&, 
> std::__1::map std::__1::allocator >, ceph::buffer::list, 
> std::__1::less std::__1::allocator > >, 
> std::__1::allocator std::__1::char_traits, std::__1::allocator > const, 
> ceph::buffer::list> > >*) ()
> (gdb) l
> 95  int preload_erasure_code()
> 96  {
> 97string plugins = g_conf->osd_erasure_code_plugins;
> 98stringstream ss;
> 99int r = ErasureCodePluginRegistry::instance().preload(
> 100 plugins,
> 101 g_conf->erasure_code_dir,
> 102 );
> 103   if (r)
> 104 derr << ss.str() << dendl;
> (gdb)
> 105   else
> 106 dout(10) << ss.str() << dendl;
> 107   return r;
> 108 }
> 109
> 
> All of this seems to be inlined since I'm not able to get at ss or r
> 
> 
> #8  0x00e16145 in std::__1::char_traits::length (__s=0x0) at 
> /usr/include/c++/v1/string:640
> 640 static inline size_t length(const char_type* __s) {return 
> strlen(__s);}

What happened here is that something attempted to initialize a
std::string with a NULL pointer, and that isn't allowed.  As you saw in
the debugger, the constructor just runs strlen() on the incoming string,
and that will segfault.


> Looking at the strlen implementation in
>/usr/srcs/head/src/lib/libc/string/strlen.c
> 
> shows that strlen does not take 0x0 as pointer, so when we get here with __s 
> = 0x0 all is lost.
> So I tried running it through 3.7, but since this is in the libraries with 
> the bintools/os, I'd expect
> both versions to crash on this.
> 
> Now the question I have to solve:
>   is it the compiler/toolset/libraries
>   is it a bug in the ceph code.

Most likely a bug in the Ceph code.  Try figuring out where the NULL
pointer originally came from.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Crash in ostream <

[Willem Jan Withagen]

Hi,

While running Ceph tools I get a crash in
fr 10
#10 0x016d82ca in FileStore::omap_get_values(coll_t const&, 
ghobject_t const&, std::__1::set, 
std::__1::less >, 
std::__1::allocator > > const&, 
std::__1::map, ceph::buffer::list, 
std::__1::less >, 
std::__1::allocator const, 
ceph::buffer::list> > >*) ()

(gdb) l
95  int preload_erasure_code()
96  {
97string plugins = g_conf->osd_erasure_code_plugins;
98stringstream ss;
99int r = ErasureCodePluginRegistry::instance().preload(
100 plugins,
101 g_conf->erasure_code_dir,
102 );
103   if (r)
104 derr << ss.str() << dendl;
(gdb)
105   else
106 dout(10) << ss.str() << dendl;
107   return r;
108 }
109

All of this seems to be inlined since I'm not able to get at ss or r


#8  0x00e16145 in std::__1::char_traits::length (__s=0x0) 
at /usr/include/c++/v1/string:640
640 static inline size_t length(const char_type* __s) {return 
strlen(__s);}


Looking at the strlen implementation in
/usr/srcs/head/src/lib/libc/string/strlen.c

shows that strlen does not take 0x0 as pointer, so when we get here with 
__s = 0x0 all is lost.
So I tried running it through 3.7, but since this is in the libraries 
with the bintools/os, I'd expect

both versions to crash on this.

Now the question I have to solve:
is it the compiler/toolset/libraries
is it a bug in the ceph code.

--WjW
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"