tcmalloc crash

[LeventA]

Hi, 

I am compiling content_shell with "-Duse_aura=1 -Duse_ozone=1 -Dchromeos=1". If I set the allocator to none, things look ok. With tcmalloc I get a crash though (in every setting that I can think of). Has anyone seen anything like this? Tips, suggestions?

Thanks

Levent

PS: PTHREADS_CRASHES_IF_RUN_TOO_EARLY did not work, crash happens right after that, in the for loop .

387  // pthread_setspecific() if we are already inside pthread_setspecific().

Traceback (most recent call last):

  File "/opt/toolchains/stbgcc-4.8-1.4-x64/arm-linux-gnueabihf/sys-root/lib/libstdc++.so.6.0.19-gdb.py", line 59, in <module>

    from libstdcxx.v6.printers import register_libstdcxx_printers

ImportError: No module named libstdcxx.v6.printers

(gdb) bt

#0  tcmalloc::ThreadCache::CreateCacheIfNecessary () at ../../third_party/tcmalloc/chromium/src/thread_cache.cc:387

#1  0x02e18878 in GetCache () at ../../third_party/tcmalloc/chromium/src/thread_cache.h:416

#2  (anonymous namespace)::do_malloc (size=52) at ../../third_party/tcmalloc/chromium/src/tcmalloc.cc:1105

#3  0x02e1a050 in Allocate (type=<optimized out>, size=24) at ../../third_party/tcmalloc/chromium/src/debugallocation.cc:519

#4  DebugAllocate (type=<optimized out>, size=24) at ../../third_party/tcmalloc/chromium/src/debugallocation.cc:994

#5  debug_cpp_alloc (size=size@entry=24, new_type=-21308287, nothrow=false) at ../../third_party/tcmalloc/chromium/src/debugallocation.cc:1113

#6  0x05293dcc in tc_new (size=24) at ../../third_party/tcmalloc/chromium/src/debugallocation.cc:1227

#7  0x00313b78 in __gnu_cxx::new_allocator<std::_Rb_tree_node<std::pair<int const, unsigned long> > >::allocate (this=0x8e68b50, __n=1) at /opt/toolchains/stbgcc-4.8-1.4-x64/arm-linux-gnueabihf/include/c++/4.8.5/ext/new_allocator.h:104

#8  0x00312c40 in std::_Rb_tree<int, std::pair<int const, unsigned long>, std::_Select1st<std::pair<int const, unsigned long> >, std::less<int>, std::allocator<std::pair<int const, unsigned long> > >::_M_get_node (this=0x8e68b50)

    at /opt/toolchains/stbgcc-4.8-1.4-x64/arm-linux-gnueabihf/include/c++/4.8.5/bits/stl_tree.h:370

#9  0x00311230 in std::_Rb_tree<int, std::pair<int const, unsigned long>, std::_Select1st<std::pair<int const, unsigned long> >, std::less<int>, std::allocator<std::pair<int const, unsigned long> > >::_M_create_node<std::piecewise_construct_t const&, std::tuple<int const&>, std::tuple<> >(std::piecewise_construct_t const&, std::tuple<int const&>&&, std::tuple<>&&) (this=0x8e68b50)

    at /opt/toolchains/stbgcc-4.8-1.4-x64/arm-linux-gnueabihf/include/c++/4.8.5/bits/stl_tree.h:403

#10 0x0030fe40 in std::_Rb_tree<int, std::pair<int const, unsigned long>, std::_Select1st<std::pair<int const, unsigned long> >, std::less<int>, std::allocator<std::pair<int const, unsigned long> > >::_M_emplace_hint_unique<std::piecewise_construct_t const&, std::tuple<int const&>, std::tuple<> >(std::_Rb_tree_const_iterator<std::pair<int const, unsigned long> >, std::piecewise_construct_t const&, std::tuple<int const&>&&, std::tuple<>&&) (this=0x8e68b50, __pos=...)

    at /opt/toolchains/stbgcc-4.8-1.4-x64/arm-linux-gnueabihf/include/c++/4.8.5/bits/stl_tree.h:1669

#11 0x0030ee1c in std::__cxx1998::map<int, unsigned long, std::less<int>, std::allocator<std::pair<int const, unsigned long> > >::operator[] (this=0x8e68b50, __k=@0x73f9cdec: 7266)

    at /opt/toolchains/stbgcc-4.8-1.4-x64/arm-linux-gnueabihf/include/c++/4.8.5/bits/stl_map.h:465

#12 0x0030e3d6 in base::ThreadIdNameManager::RegisterThread (this=0x8e68b10, handle=1945752640, id=7266) at ../../base/threading/thread_id_name_manager.cc:46

#13 0x003006b6 in base::(anonymous namespace)::ThreadFunc (params=0x8eb9d00) at ../../base/threading/platform_thread_posix.cc:62

#14 0xb6eb7170 in start_thread (arg=0x73f9d440) at pthread_create.c:314

#15 0xb6a2920c in ?? () at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:97 from /opt/toolchains/stbgcc-4.8-1.4-x64/arm-linux-gnueabihf/sys-root/lib/libc.so.6

Backtrace stopped: previous frame identical to this frame (corrupt stack?)

[Primiano Tucci]

Which version of chrome are building? Line 387 thread_cache.cc is a comment and that code has not been touched in the last three years.

Also, from your log is not clear what is causing a crash. Is it a SEGV? ABRT? At which address?

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[David Matchey]

just going off "do_malloc (size=52) at ../../third_party/tcmalloc/chromium/src/tcmalloc.cc:1105", this may be related: https://github.com/dynamorio/drmemory/issues/321

and they seem to have fixed it

[LeventA]

I am getting a SIGSEGV running the 48.0.2564.41 tag. Unfortunately it is not trivial to move to a new version; so I could not try it on any other versions yet. Also line number was shifted due to the debug messages I have added. This one is the original:

=================

Core was generated by `/mnt/nfs//usr/local/bin/content48/content_shell'.

Program terminated with signal SIGSEGV, Segmentation fault.

#0  tcmalloc::ThreadCache::CreateCacheIfNecessary () at ../../third_party/tcmalloc/chromium/src/thread_cache.cc:375

375      if (h->tid_ == me) {

(gdb) p $_siginfo._sifields._sigfault

$1 = {si_addr = 0x32b8}

=================

I have verified the commit numbers in the DEPS file; it does not look like a repo mismatch and I could not think of any other obvious reasons. I am not sure; but I think I have seen this on 39 as well. I am wondering whether it has anything to do with the eglibc version on my platform.

[Zoltan Kuscsik]

you can try to set 'use_allocator': 0 in your GYP variables and use the native alocator.

Z

---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

--

Zoltan Kuscsik

Senior Software Developer, Linaro Digital Home Group

email: zoltan....@linaro.org

IRC: zoli_ on irc.linaro.org

[Primiano Tucci]

nit: use_allocator=none, not 0

[LeventA]

Yes, that is what I have ended up doing. But I am assuming that it comes with a performance penalty. If I can finish early, I will come back to this and try to find the root cause. Since I am the only one seeing it, I guess it has something to do with the eglibc version/configuration of my platform.

Thanks for the answers

[Primiano Tucci]

> I guess it has something to do with the eglibc version/configuration of my platform.

Oh yes that would definitely explain. tcmalloc does all sort of tricks to interpose itself with glibc. If you are using your special flavour of libc I'd just assume it won't work.