Seg fault on std::vector.insert - c++

I am having a weird error when calling the insert function on a vector of custom types (which are basically graph nodes). Following is the code that is generating the seg fault:
69 for (int i = 0; i < size; i++) {
70 PDTNode * node = arguments[i]->getNode();
71 //addChild(node);
72 children.insert(it, node); // children is vector <PDTNode*>
73 it++;
74 node->addParent(this);
75 }
I double check all inputs and everything is OK and is not NULL. Below is the gdb stack trace that I got for the seg fault:
#0 0x00007ffff4793202 in ?? () from /lib/libc.so.6
#1 0x00007ffff479163a in memmove () from /lib/libc.so.6
#2 0x00000000004289f1 in std::__copy_move<false, true, std::random_access_iterator_tag>::__copy_m<PDTNode*> (__first=0x100bd60, __last=0x10053c8,
__result=0x1001840) at /usr/include/c++/4.4/bits/stl_algobase.h:378
#3 0x00000000004289ab in std::__copy_move_a<false, PDTNode**, PDTNode**> (__first=0x100bd60, __last=0x10053c8, __result=0x1001840)
at /usr/include/c++/4.4/bits/stl_algobase.h:397
#4 0x0000000000428973 in std::__copy_move_a2<false, PDTNode**, PDTNode**> (__first=0x100bd60, __last=0x10053c8, __result=0x1001840)
at /usr/include/c++/4.4/bits/stl_algobase.h:436
#5 0x000000000042891d in std::copy<PDTNode**, PDTNode**> (__first=0x100bd60, __last=0x10053c8, __result=0x1001840)
at /usr/include/c++/4.4/bits/stl_algobase.h:468
#6 0x00000000004288dc in std::__uninitialized_copy<true>::uninitialized_copy<PDTNode**, PDTNode**> (__first=0x100bd60, __last=0x10053c8, __result=0x1001840)
at /usr/include/c++/4.4/bits/stl_uninitialized.h:93
#7 0x0000000000428847 in std::uninitialized_copy<PDTNode**, PDTNode**> (__first=0x100bd60, __last=0x10053c8, __result=0x1001840)
at /usr/include/c++/4.4/bits/stl_uninitialized.h:117
#8 0x00000000004287b8 in std::__uninitialized_copy_a<PDTNode**, PDTNode**, PDTNode*> (__first=0x100bd60, __last=0x10053c8, __result=0x1001840)
at /usr/include/c++/4.4/bits/stl_uninitialized.h:257
#9 0x0000000000428684 in std::__uninitialized_move_a<PDTNode**, PDTNode**, std::allocator<PDTNode*> > (__first=0x100bd60, __last=0x10053c8,
__result=0x1001840, __alloc=...) at /usr/include/c++/4.4/bits/stl_uninitialized.h:267
#10 0x000000000042812e in std::vector<PDTNode*, std::allocator<PDTNode*> >::_M_insert_aux (this=0x1002810, __position=..., __x=#0x7fffffffd538)
at /usr/include/c++/4.4/bits/vector.tcc:338
#11 0x000000000043c46d in std::vector<PDTNode*, std::allocator<PDTNode*> >::insert (this=0x1002810, __position=..., __x=#0x7fffffffd538)
at /usr/include/c++/4.4/bits/vector.tcc:126
#12 0x00000000004d3ea9 in PDTFunctionDec::setArguments (this=0x10027e0, arguments=...) at PDTFunction.cpp:72
Any help is highly appreciated.
Thank you

I guess it is an iterator, but by inserting an element you trigger a relocation of the elements in the container and therefore invalidate the iterator. That should be the cause of your segmentation fault.

Insertion into a vector can invalidate iterators:
children.insert(it, node); // this can invalidate `it', triggering a
// segfault during the next iteration

Related

Double free or corruption when keeping std::vector<std::weak_ptr>> in std::map

Short: a (network) Client has a std::shared_ptr<Session>, when a client is destroyed, from ~Client the function queueSessionRemoval(const std::shared_ptr<Session> &session) is called, which adds it to std::map<std::chrono::seconds, std::vector<std::weak_ptr<Session>>> queuedSessionRemovals. This crashes with "double free or corruption".
Simplified code:
class Store
{
std::map<std::chrono::seconds, std::vector<std::weak_ptr<Session>>> queuedSessionRemovals;
std::mutex queuedSessionRemovalsMutex;
}
Client::~Client()
{
// removed irrelevant stuff.
// session is std::shared_ptr<Session>
store->queueSessionRemoval(session);
}
void Store::expireSessions()
{
std::lock_guard<std::mutex>(this->queuedSessionRemovalsMutex);
// Iterate over queuedSessionRemovals, etc, etc
// Removed; not important
}
void Store::queueSessionRemoval(const std::shared_ptr<Session> &session)
{
if (!session)
return;
auto removeAt = std::chrono::steady_clock::now() + std::chrono::seconds(session->getSessionExpiryInterval());
std::chrono::seconds secondsSinceEpoch = std::chrono::duration_cast<std::chrono::seconds>(removeAt.time_since_epoch());
std::lock_guard<std::mutex>(this->queuedSessionRemovalsMutex);
queuedSessionRemovals[secondsSinceEpoch].push_back(session);
}
The line that crashes is queuedSessionRemovals[secondsSinceEpoch].push_back(session);
#0 __GI_raise (sig=sig#entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007fc09ab93859 in __GI_abort () at abort.c:79
#2 0x00007fc09abfe29e in __libc_message (action=action#entry=do_abort, fmt=fmt#entry=0x7fc09ad28298 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#3 0x00007fc09ac0632c in malloc_printerr (str=str#entry=0x7fc09ad2a628 "double free or corruption (fasttop)") at malloc.c:5347
#4 0x00007fc09ac07c95 in _int_free (av=0x7fc084000020, p=0x7fc0842197b0, have_lock=0) at malloc.c:4266
#5 0x00005590242cfb82 in __gnu_cxx::new_allocator<std::weak_ptr<Session> >::deallocate (this=0x7fc08021eaf8, __p=0x7fc0842197c0) at /usr/include/c++/9/ext/new_allocator.h:128
#6 0x00005590242cfae2 in std::allocator_traits<std::allocator<std::weak_ptr<Session> > >::deallocate (__a=..., __p=0x7fc0842197c0, __n=4115453) at /usr/include/c++/9/bits/alloc_traits.h:469
#7 0x00005590242cfa3a in std::_Vector_base<std::weak_ptr<Session>, std::allocator<std::weak_ptr<Session> > >::_M_deallocate (this=0x7fc08021eaf8, __p=0x7fc0842197c0, __n=4115453) at /usr/include/c++/9/bits/stl_vector.h:351
#8 0x000055902430fe13 in std::vector<std::weak_ptr<Session>, std::allocator<std::weak_ptr<Session> > >::_M_realloc_insert<std::weak_ptr<Session> > (this=0x7fc08021eaf8,
__position=<error reading variable: Cannot access memory at address 0x119>) at /usr/include/c++/9/bits/vector.tcc:500
#9 0x000055902430c384 in std::vector<std::weak_ptr<Session>, std::allocator<std::weak_ptr<Session> > >::emplace_back<std::weak_ptr<Session> > (this=0x7fc08021eaf8) at /usr/include/c++/9/bits/vector.tcc:121
#10 0x00005590243091da in std::vector<std::weak_ptr<Session>, std::allocator<std::weak_ptr<Session> > >::push_back (this=0x7fc08021eaf8, __x=...) at /usr/include/c++/9/bits/stl_vector.h:1201
#11 0x0000559024304a3a in Store::queueSessionRemoval (this=0x559024648200, session=std::shared_ptr<class Session> (use count 2, weak count 2) = {...}) at /bla/store.cpp:726
#12 0x00005590242e41f7 in Client::~Client (this=0x55902482ca00, __in_chrg=<optimized out>) at /bla/client.cpp:91
There is nothing going on like putting a raw pointer in a shared or weak one. It's all properly managed and the session is created with std::make_shared.
So, __gnu_cxx::new_allocator<std::weak_ptr<Session> >::deallocate crashes. Probably related to re-balancing of the map.
Changing the std::weak_ptr to a std::shared_ptr in queuedSessionRemovals doesn't help. Using other containers doesn't help. Making the argument to queueSessionRemoval not a reference doesn't help.
When I use a std::list instead of a std::map and keep it sorted with std::upper_bound to find the position, very funky results happen, where an empty list has a size() > 0.
The only thing I can imagine is that it has something to do with calling this from a destructor, but at that point in time, the client::session is still a valid shared pointer, so I wouldn't know why.
Any thoughts?

How to get more information about an exception using GDB?

I have a multithreaded program, in which some thread causes an exception. I ran it in gdb, which gives the following output after the exception occurred and the program is terminated:
terminate called after throwing an instance of 'std::out_of_range'
what(): vector::_M_range_check: __n (which is 0) >= this->size() (which is 0)
Thread 46 "MyProgram" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fff3bfff700 (LWP 24491)]
0x00007ffff48f2428 in __GI_raise (sig=sig#entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
54 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) where
#0 0x00007ffff48f2428 in __GI_raise (sig=sig#entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1 0x00007ffff48f402a in __GI_abort () at abort.c:89
#2 0x00007ffff514d0d5 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x00007ffff514acc6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4 0x00007ffff514ad11 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5 0x00007ffff517719e in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00007ffff4c8e6ba in start_thread (arg=0x7fff3bfff700) at pthread_create.c:333
#7 0x00007ffff49c441d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
The output from where does not really help to find out which thread causes the problem.
Is there a way to get more information out of this situation?
When you see this output it is too late to find out what thread have thrown an exception because your program is already terminated. I guess what you need is to set catchpoint on std::out_of_range exception and continue running your program until this exception is thrown:
(gdb) catch throw out_of_range
When exception is thrown, gdb should stop and you can print backtrace of thread that causes an exception.
For those ones who go after us. I was come to the same issue:
And it text
Thread 1 "Auditor_Tst" hit Catchpoint 1 (exception thrown), 0xb6a07b48 in __cxa_throw () from /usr/lib/libstdc++.so.6
(gdb) bt
#0 0xb6a07b48 in __cxa_throw () from /usr/lib/libstdc++.so.6
#1 0xb6f3105e in Utils::(anonymous namespace)::getSubJson (j=..., key=...) at ../Src/Auditor/GetterJsonValue.cpp:61
#2 0xb6f31270 in Utils::getJsonValueByPath (json=..., keyList=...) at ../Src/Auditor/GetterJsonValue.cpp:132
#3 0xb6f42b76 in Utils::getJsonValueByPathAs<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > (json=..., keyList=...) at ../Src/Auditor/Helper/GetterJsonValue.hpp:136
#4 0xb6f5c852 in Utils::getJsonValueByPathAs<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > (json=..., keyList=..., defaultValue=...) at ../Src/Auditor/Helper/GetterJsonValue.hpp:155
#5 0xb6f80488 in Auditor::LogProcessor::extractBeginDate (message=..., isInvalid=#0xbefff2bd: false) at ../Src/Auditor/AuditorProcessor.cpp:320
#6 0xb6f7f9a6 in Auditor::LogProcessor::processHistory (this=0xbefff750, message=...) at ../Src/Auditor/AuditorProcessor.cpp:197
#7 0xb6f7f4ca in Auditor::LogProcessor::process (this=0xbefff750, message=...) at ../Src/Auditor/AuditorProcessor.cpp:135
#8 0x00106eb0 in Auditor::Processor_Test_requestEmptyHitoryJson_Test::TestBody (this=0x16fef8) at ../Tst/Auditor/AuditorProcessorTests.cpp:262
#9 0xb6b75fa2 in testing::internal::HandleSehExceptionsInMethodIfSupported<testing::Test, void> (object=0x16fef8, method=&virtual testing::Test::TestBody(), location=0xb6b86330 "the test body") at ../Tools/googletest/googletest/src/gtest.cc:2607
#10 0xb6b7054a in testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void> (object=0x16fef8, method=&virtual testing::Test::TestBody(), location=0xb6b86330 "the test body") at ../Tools/googletest/googletest/src/gtest.cc:2643
#11 0xb6b5092e in testing::Test::Run (this=0x16fef8) at ../Tools/googletest/googletest/src/gtest.cc:2682
#12 0xb6b51056 in testing::TestInfo::Run (this=0x160a00) at ../Tools/googletest/googletest/src/gtest.cc:2861
#13 0xb6b516f2 in testing::TestSuite::Run (this=0x160490) at ../Tools/googletest/googletest/src/gtest.cc:3015
#14 0xb6b5c820 in testing::internal::UnitTestImpl::RunAllTests (this=0x15dd90) at ../Tools/googletest/googletest/src/gtest.cc:5851
#15 0xb6b76d42 in testing::internal::HandleSehExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> (object=0x15dd90, method=(bool (testing::internal::UnitTestImpl::*)(testing::internal::UnitTestImpl * const)) 0xb6b5c571 <testing::internal::UnitTestImpl::RunAllTests()>, location=0xb6b86dbc "auxiliary test code (environments or event listeners)") at ../Tools/googletest/googletest/src/gtest.cc:2607
#16 0xb6b71136 in testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> (object=0x15dd90, method=(bool (testing::internal::UnitTestImpl::*)(testing::internal::UnitTestImpl * const)) 0xb6b5c571 <testing::internal::UnitTestImpl::RunAllTests()>, location=0xb6b86dbc "auxiliary test code (environments or event listeners)") at ../Tools/googletest/googletest/src/gtest.cc:2643
#17 0xb6b5b738 in testing::UnitTest::Run (this=0xb6ba6dd8 <testing::UnitTest::GetInstance()::instance>) at ../Tools/googletest/googletest/src/gtest.cc:5434
#18 0x0012a22a in RUN_ALL_TESTS () at ../Tools/googletest/googletest/include/gtest/gtest.h:2471
#19 0x0012a1b6 in main (argc=1, argv=0xbefffc54) at ../Tst/Auditor/AuditorMain.cpp:10
(gdb) frame 1
#1 0xb6f3105e in Utils::(anonymous namespace)::getSubJson (j=..., key=...) at ../Src/Auditor/GetterJsonValue.cpp:61
61 in ../Src/Auditor/GetterJsonValue.cpp
(gdb) info locals
error = {static npos = 4294967295, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x162940 "Key 'begin-date' not found in {\"msg-name\":\"get-audit-log\",\"msg-type\":\"req\",\"val\":12,\"res\":\"ok\"}."}, _M_string_length = 96, {_M_local_buf = "`\000\000\000\330\006\354\266\254\361\377\276`\221\377\266", _M_allocated_capacity = 96}}
__func__ = "getSubJson"
(gdb) p (char*)error
$6 = 0x162940 "Key 'begin-date' not found in {\"msg-name\":\"get-auditor-name\",\"msg-type\":\"req\",\"val\":12,\"res\":\"ok\"}."
last line shows what is passed to constructor of exception, this is what it would return from what()

C++ glibc detected corrupted double-linked list error C++

I have the following declaration for a 2D dynamic integer linked list in Population.cpp:
sectionProf = new int*[section_count]; //list of professor for each section declaration
It is defined in Population.h as:
int ** sectionProf; //list of professor for each section
It is then filled from a file as such, again in Population.cpp, later on:
sectionProf[section] = new int[professors + 1];
sectionProf[section][0] = professors;
if (professors > 0) {
for (int x = 1; x < professors + 1; ++x) {
sectionProf[section][x] = stoi(tokenizedVersion[x + 1]);
}
}
Then, in the destructor, I destroy it as follows:
if(sectionProf){
for(int i = 0; i < section_count; ++i){
delete [] sectionProf[i];
}
delete [] sectionProf;
}
However, upon execution, I keep getting the following error:
* glibc detected * ./research_scheduling_backend: corrupted double-linked list: 0x00000000020b78c0 ***
Here is the gdb backtrace (#17 is referring to the 'delete [] sectionProf' line):
#0 __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:93
#1 0x00007ffff7085f61 in _L_lock_10611 () at malloc.c:5249
#2 0x00007ffff7083c87 in __GI___libc_malloc (bytes=140737341265696) at malloc.c:2921
#3 0x00007ffff7de7900 in _dl_map_object_deps (map=0x7ffff7fdd4e0, preloads=<optimized out>, npreloads=<optimized out>, trace_mode=0, open_mode=-2147483648) at dl-deps.c:517
#4 0x00007ffff7ded8a9 in dl_open_worker (a=0x7fffffffbb00) at dl-open.c:262
#5 0x00007ffff7de9176 in _dl_catch_error (objname=0x7fffffffbb48, errstring=0x7fffffffbb50, mallocedp=0x7fffffffbb5f, operate=0x7ffff7ded700 <dl_open_worker>, args=0x7fffffffbb00) at dl-error.c:178
#6 0x00007ffff7ded31a in _dl_open (file=0x7ffff717a858 "libgcc_s.so.1", mode=-2147483647, caller_dlopen=0x7ffff710bea5, nsid=-2, argc=3, argv=<optimized out>, env=0x7fffffffeac8) at dl-open.c:639
#7 0x00007ffff7131bb2 in do_dlopen (ptr=0x7fffffffbd00) at dl-libc.c:89
#8 0x00007ffff7de9176 in _dl_catch_error (objname=0x7fffffffbd30, errstring=0x7fffffffbd20, mallocedp=0x7fffffffbd3f, operate=0x7ffff7131b70 <do_dlopen>, args=0x7fffffffbd00) at dl-error.c:178
#9 0x00007ffff7131c74 in dlerror_run (args=0x7fffffffbd00, operate=0x7ffff7131b70 <do_dlopen>) at dl-libc.c:48
#10 __GI___libc_dlopen_mode (name=<optimized out>, mode=<optimized out>) at dl-libc.c:165
#11 0x00007ffff710bea5 in init () at ../sysdeps/x86_64/../ia64/backtrace.c:53
#12 0x00007ffff6df1400 in pthread_once () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_once.S:104
#13 0x00007ffff710bfc4 in __GI___backtrace (array=<optimized out>, size=64) at ../sysdeps/x86_64/../ia64/backtrace.c:104
#14 0x00007ffff707505f in __libc_message (do_abort=2, fmt=0x7ffff717f560 "*** glibc detected *** %s: %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:180
#15 0x00007ffff707f846 in malloc_printerr (action=3, str=0x7ffff717be4c "corrupted double-linked list", ptr=<optimized out>) at malloc.c:5047
#16 0x00007ffff7080b1b in _int_free (av=0x7ffff73b9720, p=0x627dd0, have_lock=0) at malloc.c:4125
#17 0x0000000000404b7e in Population::~Population (this=0x7fffffffc910, __in_chrg=<optimized out>) at Population.cpp:91
#18 0x0000000000403919 in main (argc=3, argv=0x7fffffffeaa8) at Scheduler.cpp:101
At absolutely no place in the code is the sectionProf array ever modified. It is only used to check values. Can someone please tell me why I might be getting this error? I have looked all over the place about glibc double-linked list errors and I understand that it is because in some way I am corrupting the symbol table(?) somehow...
For anyone who lands on this problem, here is what is wrong in my specific problem. I was reading garbage value for section index that were out of range (section_count) when I was generating the array. That is, in the for loop,
sectionProf[section] = new int[professors + 1];
sectionProf[section][0] = professors;
if (professors > 0) {
for (int x = 1; x < professors + 1; ++x) {
sectionProf[section][x] = stoi(tokenizedVersion[x + 1]);
}
}
my value for section was not in the range of 0 and section_count, the index used in the delete loop. Hence why I was causing the corruption of memory.
Lesson: Check for PEBKAC errors generated in input files.

Segmentation fault in my php extension

I wrote a php extension but couldn't find the reason why it reported segmentation fault.
related code:
char *tkey = (char *)emalloc(sizeof(char)*(result_pair[num-1].length+1));
std::memcpy(tkey, (text+i),result_pair[num-1].length);
tkey[result_pair[num-1].length]='\0';
if (zend_hash_find(HASH_OF(return_value), tkey, result_pair[num-1].length+1, (void**)&origval) == SUCCESS) {
ZVAL_LONG(*origval, Z_LVAL_P(*origval)+1);
zend_hash_update(HASH_OF(return_value), tkey, result_pair[num-1].length+1, origval, sizeof(origval), NULL);
} else {
add_assoc_long(return_value, tkey, 1);
}
efree(tkey);
num--;
The following were from gdb
Program received signal SIGSEGV, Segmentation fault.
_zend_mm_alloc_int (heap=0x1ca07750, size=32) at /php-5.3.3/Zend/zend_alloc.c:1825
1825 heap->cache[index] = best_fit->prev_free_block;
Current language: auto; currently c
(gdb) bt
#0 _zend_mm_alloc_int (heap=0x1ca07750, size=32) at /php-5.3.3/Zend/zend_alloc.c:1825
#1 0x0000000000729160 in add_assoc_long_ex (arg=0x1cc29380, key=0x20 <Address 0x20 out of bounds>, key_len=2, n=2) at /php-5.3.3/Zend/zend_API.c:1117
#2 0x00002b2ebee6552e in zif_xs_search (ht=<value optimized out>, return_value=0x1cc29380, return_value_ptr=<value optimized out>,
this_ptr=<value optimized out>, return_value_used=<value optimized out>) at /release/xsplit_t/xsplit.cpp:1007
#3 0x000000000076b489 in zend_do_fcall_common_helper_SPEC (execute_data=0x2b2ebf070050) at /php-5.3.3/Zend/zend_vm_execute.h:316
#4 0x0000000000741cae in execute (op_array=0x1cc26378) at /php-5.3.3/Zend/zend_vm_execute.h:107
#5 0x000000000071e5c9 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /php-5.3.3/Zend/zend.c:1194
#6 0x00000000006cc8b8 in php_execute_script (primary_file=0x7fffb5324230) at /php-5.3.3/main/main.c:2260
#7 0x00000000007a897e in main (argc=2, argv=0x7fffb53244a8) at /php-5.3.3/sapi/cli/php_cli.c:1192
(gdb) frame 2
#2 0x00002b2ebee6552e in zif_xs_search (ht=<value optimized out>, return_value=0x1cc29380, return_value_ptr=<value optimized out>,
this_ptr=<value optimized out>, return_value_used=<value optimized out>) at /release/xsplit_t/xsplit.cpp:1007
1007 add_assoc_long(return_value, tkey, 1);
Current language: auto; currently c++
I figured out that the problem was add_assoc_long function, 'tkey' is declared as:
char *tkey = (char *)emalloc(sizeof(char)*(result_pair[num-1].length+1));
Segfault only occurred under some circumstances but not always, but I thought tkey wouldn't have any problems. Any help is appreciated, thanks a lot~
Your memcpy is not copying the NUL character, you need a +1 for the number of bytes to be copied:
std::memcpy(tkey, (text+i),result_pair[num-1].length+1);
^^

Problem in running boost eample blocking_udp_echo_client on MacOSX

I am trying to run blocking_udp_echo_client on MacOS X
http://www.boost.org/doc/libs/1_35_0/doc/html/boost_asio/example/echo/blocking_udp_echo_client.cpp
I run it with argument 'localhost 9000'
But the program crashes and this is the line in the source which crashes:
`udp::socket s(io_service, udp::endpoint(udp::v4(), 0));'
this is the stack trace:
#0 0x918c3e42 in __kill
#1 0x918c3e34 in kill$UNIX2003
#2 0x9193623a in raise
#3 0x91942679 in abort
#4 0x940d96f9 in __gnu_debug::_Error_formatter::_M_error
#5 0x0000e76e in
__gnu_debug::_Safe_iterator::op_base*> >,
__gnu_debug_def::list::op_base*>,
std::allocator::op_base*> > >
>::_Safe_iterator at safe_iterator.h:124
#6 0x00014729 in boost::asio::detail::hash_map::op_base*>::bucket_type::bucket_type
at hash_map.hpp:277
#7 0x00019e97 in std::_Construct::op_base*>::bucket_type,
boost::asio::detail::hash_map::op_base*>::bucket_type> at
stl_construct.h:81
#8 0x0001a457 in
std::__uninitialized_fill_n_aux::op_base*>::bucket_type*,
__gnu_norm::vector::op_base*>::bucket_type,
std::allocator::op_base*>::bucket_type> >
>, unsigned long, boost::asio::detail::hash_map::op_base*>::bucket_type> at
stl_uninitialized.h:194
#9 0x0001a4e1 in
std::uninitialized_fill_n::op_base*>::bucket_type*,
__gnu_norm::vector::op_base*>::bucket_type,
std::allocator::op_base*>::bucket_type> >
>, unsigned long, boost::asio::detail::hash_map::op_base*>::bucket_type> at
stl_uninitialized.h:218
#10 0x0001a509 in
std::__uninitialized_fill_n_a::op_base*>::bucket_type*,
__gnu_norm::vector::op_base*>::bucket_type,
std::allocator::op_base*>::bucket_type> >
>, unsigned long, boost::asio::detail::hash_map::op_base*>::bucket_type,
boost::asio::detail::hash_map::op_base*>::bucket_type> at
stl_uninitialized.h:310
#11 0x0001aa34 in
__gnu_norm::vector::op_base*>::bucket_type,
std::allocator::op_base*>::bucket_type>
>::_M_fill_insert at vector.tcc:365
#12 0x0001acda in
__gnu_norm::vector::op_base*>::bucket_type,
std::allocator::op_base*>::bucket_type>
>::insert at stl_vector.h:658
#13 0x0001ad81 in
__gnu_norm::vector::op_base*>::bucket_type,
std::allocator::op_base*>::bucket_type>
>::resize at stl_vector.h:427
#14 0x0001ae3a in
__gnu_debug_def::vector::op_base*>::bucket_type,
std::allocator::op_base*>::bucket_type>
>::resize at vector:169
#15 0x0001b7be in boost::asio::detail::hash_map::op_base*>::rehash at
hash_map.hpp:221
#16 0x0001bbeb in boost::asio::detail::hash_map::op_base*>::hash_map at
hash_map.hpp:67
#17 0x0001bc74 in
boost::asio::detail::reactor_op_queue::reactor_op_queue at
reactor_op_queue.hpp:42
#18 0x0001bd24 in
boost::asio::detail::kqueue_reactor::kqueue_reactor at
kqueue_reactor.hpp:86
#19 0x0001c000 in
boost::asio::detail::service_registry::use_service
> at service_registry.hpp:109
#20 0x0001c14d in
boost::asio::use_service >
at io_service.ipp:195
#21 0x0001c26d in
boost::asio::detail::reactive_socket_service >::reactive_socket_service
at reactive_socket_service.hpp:111
#22 0x0001c344 in
boost::asio::detail::service_registry::use_service > > at
service_registry.hpp:109
#23 0x0001c491 in
boost::asio::use_service > > at io_service.ipp:195
#24 0x0001c4d5 in
boost::asio::datagram_socket_service::datagram_socket_service
at datagram_socket_service.hpp:95
#25 0x0001c59e in
boost::asio::detail::service_registry::use_service
> at service_registry.hpp:109
#26 0x0001c6eb in
boost::asio::use_service
> at io_service.ipp:195
#27 0x0001c711 in
boost::asio::basic_io_object
>::basic_io_object at basic_io_object.hpp:72
#28 0x0001c783 in boost::asio::basic_socket
>::basic_socket at basic_socket.hpp:108
#29 0x0001c865 in
boost::asio::basic_datagram_socket
>::basic_datagram_socket at basic_datagram_socket.hpp:107
#30 0x000027bc in main at main.cpp:32
This is the gdb output:
(gdb) continue
/Developer/SDKs/MacOSX10.5.sdk/usr/include/c++/4.0.0/debug/safe_iterator.h:127:
error: attempt to copy-construct an iterator from a singular iterator.
Objects involved in the operation:
iterator "this" # 0x0x100420 {
type = N11__gnu_debug14_Safe_iteratorIN10__gnu_norm14_List_iteratorISt4pairIiPN5boost4asio6detail16reactor_op_queueIiE7op_baseEEEEN15__gnu_debug_def4listISB_SaISB_EEEEE
(mutable iterator);
state = singular;
}
iterator "other" # 0x0xbfffe8a4 {
type = N11__gnu_debug14_Safe_iteratorIN10__gnu_norm14_List_iteratorISt4pairIiPN5boost4asio6detail16reactor_op_queueIiE7op_baseEEEEN15__gnu_debug_def4listISB_SaISB_EEEEE
(mutable iterator);
state = singular;
}
Program received signal: “SIGABRT”.
(gdb) continue
Program received signal: “?”.
Does someone has any idea why this example does not work on mac osx?
Thank you.
Looks like a bug in the boost::asio library. Here is the corresponding bug report.