[CXX-78] parse_number_test is failing with a segfault on travis clang build Created: 01/Mar/14  Updated: 09/Apr/14  Resolved: 08/Mar/14

Status: Closed
Project: C++ Driver
Component/s: None
Affects Version/s: None
Fix Version/s: legacy-0.8.0

Type: Bug Priority: Major - P3
Reporter: Andrew Morrow (Inactive) Assignee: Mira Carey
Resolution: Done Votes: 0
Labels: legacy-cxx
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

https://travis-ci.org/acmorrow/mongo-cxx-driver/jobs/19873161



 Comments   
Comment by Andrew Morrow (Inactive) [ 08/Mar/14 ]

Tyler fixed this in the 26compat stream by using a different boost PPA: https://github.com/mongodb/mongo-cxx-driver/commit/20bdfd9f0b13980097e36d33b44c40ed8bea08aa

Comment by Mira Carey [ 03/Mar/14 ]

I found a stack overflow question that pretty much mirrors our use case. In that case it was gcc built boost and intel's c++ compiler (on ubuntu 13.04), but the stack trace is basically identical

http://stackoverflow.com/questions/18927939/segfault-during-static-initialization-when-linking-gcc-built-boost-into-an-intel

#0  shared_count (r=..., this=0x7ffff7bbc5f8 <boost::exception_ptr boost::exception_detail::get_static_exception_object<boost::exception_detail::bad_exception_>()::ep+8>)
    at ./boost/smart_ptr/shared_ptr.hpp:328
#1  shared_ptr (this=0x7ffff7bbc5f0 <boost::exception_ptr boost::exception_detail::get_static_exception_object<boost::exception_detail::bad_exception_>()::ep>) at ./boost/smart_ptr/shared_ptr.hpp:328
#2  exception_ptr (ptr=..., this=0x7ffff7bbc5f0 <boost::exception_ptr boost::exception_detail::get_static_exception_object<boost::exception_detail::bad_exception_>()::ep>)
    at ./boost/exception/detail/exception_ptr.hpp:53
#3  boost::exception_detail::get_static_exception_object<boost::exception_detail::bad_exception_> () at ./boost/exception/detail/exception_ptr.hpp:130
#4  0x00007ffff79b02e1 in __static_initialization_and_destruction_0 (__initialize_p=<optimized out>, __priority=<optimized out>) at ./boost/exception/detail/exception_ptr.hpp:143
#5  _GLOBAL__sub_I_thread.cpp(void) () at libs/thread/src/pthread/thread.cpp:767
#6  0x00007ffff7de9876 in call_init (l=l@entry=0x7ffff7ff9a10, argc=argc@entry=1, argv=argv@entry=0x7fffffffe0b8, env=env@entry=0x7fffffffe0c8) at dl-init.c:84
#7  0x00007ffff7de9930 in call_init (env=<optimized out>, argv=<optimized out>, argc=<optimized out>, l=0x7ffff7ff9a10) at dl-init.c:55
#8  _dl_init (main_map=0x7ffff7ffe268, argc=1, argv=0x7fffffffe0b8, env=0x7fffffffe0c8) at dl-init.c:133
#9  0x00007ffff7ddb68a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#10 0x0000000000000001 in ?? ()
#11 0x00007fffffffe391 in ?? ()
#12 0x0000000000000000 in ?? ()

Comment by Andrew Morrow (Inactive) [ 03/Mar/14 ]

Bumping out until either travis has newer system images or we have some insight into why there could be an ABI incompatibility between the PPA boost binaries and clang generated code from the boost headers.

Comment by Mira Carey [ 03/Mar/14 ]

A relevant stack trace (repro-d with boost 1.55)

#0  shared_count (r=..., this=0x7ffff7953268) at ./boost/smart_ptr/detail/shared_count.hpp:377
#1  shared_ptr (this=0x7ffff7953260) at ./boost/smart_ptr/shared_ptr.hpp:328
#2  exception_ptr (ptr=..., this=0x7ffff7953260) at ./boost/exception/detail/exception_ptr.hpp:53
#3  boost::exception_detail::get_static_exception_object<boost::exception_detail::bad_exception_> ()
    at ./boost/exception/detail/exception_ptr.hpp:130
#4  0x00007ffff7748541 in __static_initialization_and_destruction_0 (__initialize_p=<optimized out>,
    __priority=<optimized out>) at ./boost/exception/detail/exception_ptr.hpp:143
#5  _GLOBAL__sub_I_thread.cpp(void) () at libs/thread/src/pthread/thread.cpp:767
#6  0x00007ffff7de9306 in ?? () from /lib64/ld-linux-x86-64.so.2
#7  0x00007ffff7de93df in ?? () from /lib64/ld-linux-x86-64.so.2
#8  0x00007ffff7ddb6ea in ?? () from /lib64/ld-linux-x86-64.so.2
#9  0x0000000000000001 in ?? ()
#10 0x00007fffffffe7a5 in ?? ()
#11 0x0000000000000000 in ?? ()

Generated at Wed Feb 07 21:58:08 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.