Date: Tue, 15 Mar 2016 19:52:23 +0100 From: Dimitry Andric <dimitry@andric.com> To: Willem Jan Withagen <wjw@digiware.nl> Cc: toolchain@freebsd.org Subject: Re: Crash in ostream <<operator Message-ID: <53A640CD-4F24-4242-8252-B27225A20071@andric.com> In-Reply-To: <56E7F4DB.2000404@digiware.nl> References: <56E7F4DB.2000404@digiware.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_48D33D00-7598-4A06-AC2B-D83CCA6237C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 15 Mar 2016, at 12:41, Willem Jan Withagen <wjw@digiware.nl> wrote: >=20 > While running Ceph tools I get a crash in > fr 10 > #10 0x00000000016d82ca in FileStore::omap_get_values(coll_t const&, = ghobject_t const&, std::__1::set<std::__1::basic_string<char, = std::__1::char_traits<char>, std::__1::allocator<char> >, = std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, = std::__1::allocator<char> > >, = std::__1::allocator<std::__1::basic_string<char, = std::__1::char_traits<char>, std::__1::allocator<char> > > > const&, = std::__1::map<std::__1::basic_string<char, std::__1::char_traits<char>, = std::__1::allocator<char> >, ceph::buffer::list, = std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, = std::__1::allocator<char> > >, = std::__1::allocator<std::__1::pair<std::__1::basic_string<char, = std::__1::char_traits<char>, std::__1::allocator<char> > const, = ceph::buffer::list> > >*) () > (gdb) l > 95 int preload_erasure_code() > 96 { > 97 string plugins =3D g_conf->osd_erasure_code_plugins; > 98 stringstream ss; > 99 int r =3D ErasureCodePluginRegistry::instance().preload( > 100 plugins, > 101 g_conf->erasure_code_dir, > 102 &ss); > 103 if (r) > 104 derr << ss.str() << dendl; > (gdb) > 105 else > 106 dout(10) << ss.str() << dendl; > 107 return r; > 108 } > 109 >=20 > All of this seems to be inlined since I'm not able to get at ss or r >=20 >=20 > #8 0x0000000000e16145 in std::__1::char_traits<char>::length = (__s=3D0x0) 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 >=20 > shows that strlen does not take 0x0 as pointer, so when we get here = with __s =3D 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. >=20 > 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 --Apple-Mail=_48D33D00-7598-4A06-AC2B-D83CCA6237C6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.29 iEYEARECAAYFAlboWe8ACgkQsF6jCi4glqMwbACdGt0cmUbBlB+BqNzj855qKCMS KQ0AoOIsIViuYUEDkMK29sf6COV4NzkL =2ZzA -----END PGP SIGNATURE----- --Apple-Mail=_48D33D00-7598-4A06-AC2B-D83CCA6237C6--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53A640CD-4F24-4242-8252-B27225A20071>