Why do we need to run `io.run` in both main thread and a new thread `t` within asico tutorial Timer.5 example? - boost

Reference: tuttimer5
coliru demo
Based on the tutorial, the main function looks like the following:
int main()
{
boost::asio::io_context io;
printer p(io);
boost::thread t(boost::bind(&boost::asio::io_context::run, &io));
io.run(); // Why do we need to call io.run() here?
t.join();
return 0;
}
I want to understand why we need to have two io.run(); in the main function.
Here is my test result:
Test 1 (call io.run() in main thread within main function):
main-Thread #32
printer-Thread #32
print1-Thread #32
Timer 1: 0
print2-Thread #32
Timer 2: 1
print1-Thread #32
Timer 1: 2
print2-Thread #32
Timer 2: 3
print1-Thread #32
Timer 1: 4
print2-Thread #32
Timer 2: 5
print1-Thread #32
Timer 1: 6
print2-Thread #32
Timer 2: 7
print1-Thread #32
Timer 1: 8
print2-Thread #32
Timer 2: 9
~printer-Thread #32
Final count is 10
Observation1: both print1 and print2 are called by main-thread.
Test 2 (NOT call io.run() in main thread within main function):
main-Thread #40
printer-Thread #40
print1-Thread #29
Timer 1: 0
print2-Thread #29
Timer 2: 1
print1-Thread #29
Timer 1: 2
print2-Thread #29
Timer 2: 3
print1-Thread #29
Timer 1: 4
print2-Thread #29
Timer 2: 5
print1-Thread #29
Timer 1: 6
print2-Thread #29
Timer 2: 7
print1-Thread #29
Timer 1: 8
print2-Thread #29
Timer 2: 9
~printer-Thread #40
Final count is 10
Observation2: Neither print1 and print2 are called by main-thread.
Note: the testing results are come from my local linux box(g++ (Ubuntu 11.1.0-1ubuntu1~18.04.1) 11.1.0)). The result looks a little different from coliru.
In that case io_context operates like a classic thread pool.
Asynchronous tasks are performed somewhere on the OS side, however
completion handlers are invoked on those threads where io_context::run
function is running. To be more precise: every completion handler is
invoked on a first free thread which io_context::run function is
running on.
Question> what is the main reason that we want to call io.run); in both main and a new thread in the original tutorial?
Thank you

None of it is required. It merely shows that tasks are distributed over all thread participating in running/polling the execution context.
In that sense, the code as written is simply the cheapest way to get 2 threads running the io context. In a more recent Boost version, one could argue that thread_pool is cleaner code, but results in 3 threads (counting the main thread):
int main()
{
report("main") << std::endl;
boost::asio::thread_pool io(2);
printer p(io.get_executor());
io.join();
}
Live On Coliru
#include <boost/asio.hpp>
#include <boost/bind/bind.hpp>
#include <iomanip>
#include <iostream>
#include <thread>
namespace asio = boost::asio;
std::ostream& report(const std::string& suffix_msg)
{
auto tid = std::hash<std::thread::id>{}(std::this_thread::get_id()) % 100;
return std::cout << suffix_msg << "-Thread #" << std::setw(2)
<< std::setfill('0') << tid;
}
class printer {
public:
printer(asio::any_io_executor ex)
: strand_(asio::make_strand(ex))
, count_(0)
{
report("printer") << std::endl;
timer1_.async_wait(
std::bind(&printer::print_callback, this, "Timer 1", std::ref(timer1_)));
timer2_.async_wait(
std::bind(&printer::print_callback, this, "Timer 2", std::ref(timer2_)));
}
~printer()
{
report("~printer") << "\tFinal count is " << count_ << std::endl;
}
void print_callback(std::string_view name, asio::steady_timer& timer)
{
if (count_ < 10) {
report("print_callback") << "\t" << name << ": " << count_ << std::endl;
++count_;
timer.expires_at(timer.expiry() + asio::chrono::seconds(1));
timer.async_wait(std::bind(&printer::print_callback, this, name,
std::ref(timer)));
}
}
private:
asio::any_io_executor strand_;
int count_ = 0;
asio::steady_timer timer1_{strand_, asio::chrono::seconds(1)};
asio::steady_timer timer2_{strand_, asio::chrono::seconds(1)};
};
int main()
{
report("main") << std::endl;
boost::asio::thread_pool io(2);
printer p(io.get_executor());
io.join();
}
Prints e.g.
main-Thread #59
printer-Thread #59
print_callback-Thread #06 Timer 1: 0
print_callback-Thread #06 Timer 2: 1
print_callback-Thread #74 Timer 1: 2
print_callback-Thread #74 Timer 2: 3
print_callback-Thread #74 Timer 1: 4
print_callback-Thread #74 Timer 2: 5
print_callback-Thread #74 Timer 1: 6
print_callback-Thread #74 Timer 2: 7
print_callback-Thread #74 Timer 1: 8
print_callback-Thread #74 Timer 2: 9
~printer-Thread #59 Final count is 10

Related

core dump stack indicates SIGSEGV due to vector<vector<int>> usage

I have a code snippet that is behaving weirdly. The code is simply aiming to implement radix and bucket sort. When I comment in the main one of either sort and run it works perfectly. But when I enable both of them i am getting a core dump. And the weird part is core dump as indicated by the stack is crossing over into the stl_vector.h.
The code reference is here:- https://rextester.com/RUUDP10453
When i enable only one of the sorts like below in main it works fine.
//doRadixSort(arr, size);
doBucketSort(arr, size);
or
doRadixSort(arr, size);
//doBucketSort(arr, size);
But when both are enabled there is segmentation fault after both sorts are completed as indicated by the
cout << "i am here at exit" << endl;
The core dump stack indicates some reference/hint at vector of vector buckets. But i have properly allocated and reserved it the required memory. so why this is happening i need some expertise to dig out. I have tried debugging this in eclipse CDT C++ for about 2 hrs with no lead.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 _int_free (av=0x7f66d702eb00 <main_arena>, p=0xf98020, have_lock=0) at malloc.c:3976
3976 >= ((char *) av->top + chunksize(av->top)), 0))
(gdb) where
#0 _int_free (av=0x7f66d702eb00 <main_arena>, p=0xf98020, have_lock=0) at malloc.c:3976
#1 0x00007f66d6cf33dc in __GI___libc_free (mem=<optimized out>) at malloc.c:2966
#2 0x00000000004030fa in __gnu_cxx::new_allocator<std::vector<int, std::allocator<int> > >::deallocate (this=0x7fffc6ffa060, __p=0xf98030) at /usr/include/c++/6.3.1/ext/new_allocator.h:110
#3 0x0000000000402d23 in std::allocator_traits<std::allocator<std::vector<int, std::allocator<int> > > >::deallocate (__a=..., __p=0xf98030, __n=10) at /usr/include/c++/6.3.1/bits/alloc_traits.h:442
#4 0x00000000004027ac in std::_Vector_base<std::vector<int, std::allocator<int> >, std::allocator<std::vector<int, std::allocator<int> > > >::_M_deallocate (this=0x7fffc6ffa060, __p=0xf98030, __n=10)
at /usr/include/c++/6.3.1/bits/stl_vector.h:178
#5 0x00000000004025e4 in std::_Vector_base<std::vector<int, std::allocator<int> >, std::allocator<std::vector<int, std::allocator<int> > > >::~_Vector_base (this=0x7fffc6ffa060, __in_chrg=<optimized out>)
at /usr/include/c++/6.3.1/bits/stl_vector.h:160
#6 0x000000000040211d in std::vector<std::vector<int, std::allocator<int> >, std::allocator<std::vector<int, std::allocator<int> > > >::~vector (this=0x7fffc6ffa060, __in_chrg=<optimized out>)
at /usr/include/c++/6.3.1/bits/stl_vector.h:427
#7 0x0000000000401d4b in doBucketSort (arr=0x7fffc6ffa100, size=#0x7fffc6ffa0f8: 12) at tako.cpp:97
#8 0x0000000000401e29 in main (argc=1, argv=0x7fffc6ffa218) at tako.cpp:141
(gdb)
Alternatively, I found the below also works which is equivalent to the resize function.
vector<vector<int>> buckets;
constexpr size_t size=10, bucketSize=10;
buckets.reserve(bucketSize);
for(unsigned int i=0; i<=bucketSize; ++i)
buckets.push_back({ });
for(unsigned int i=0; i<=bucketSize; ++i)
buckets[i].reserve(size);

`gdb` unable to unwind a stack

Consider following (broken) code:
#include <iostream>
#include <memory>
using namespace std;
class Test {
public:
unique_ptr<string> s;
Test() : s(NULL) {
}
void update(string& st) {
s = unique_ptr<string>(&(st));
}
};
void update(Test& t) {
string s("Hello to you");
t.update(s);
}
int main() {
Test t;
update(t);
cout << *t.s << endl;
}
Here we have error in method Test::update() we do not make a uniq copy of an object. So when the program is run under macOS, you'll get:
$ ./test
Hello t��E]�
test(44981,0x7fff99ba93c0) malloc: *** error for object 0x7fff5d45b690: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
[1] 44981 abort ./test
I've been able to to debug this case successfully using lldb. Even without setting a breakpoint in malloc_error_break, just running application until it gets caught in SIGABRT handler.
lldb ./test
(lldb) target create "./test"
Current executable set to './test' (x86_64).
(lldb) run
Process 44993 launched: './test' (x86_64)
Hello t��_�
test(44993,0x7fff99ba93c0) malloc: *** error for object 0x7fff5fbff680: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Process 44993 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
frame #0: 0x00007fff90d6cd42 libsystem_kernel.dylib`__pthread_kill + 10
libsystem_kernel.dylib`__pthread_kill:
-> 0x7fff90d6cd42 <+10>: jae 0x7fff90d6cd4c ; <+20>
0x7fff90d6cd44 <+12>: movq %rax, %rdi
0x7fff90d6cd47 <+15>: jmp 0x7fff90d65caf ; cerror_nocancel
0x7fff90d6cd4c <+20>: retq
Target 0: (test) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
* frame #0: 0x00007fff90d6cd42 libsystem_kernel.dylib`__pthread_kill + 10
frame #1: 0x00007fff90e5a457 libsystem_pthread.dylib`pthread_kill + 90
frame #2: 0x00007fff90cd2420 libsystem_c.dylib`abort + 129
frame #3: 0x00007fff90dc1fe7 libsystem_malloc.dylib`free + 530
frame #4: 0x0000000100001f7b test`Test::~Test() [inlined] std::__1::default_delete<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >::operator(this=0x00007fff5fbff730, __ptr="\a\x94\x99�\x7f\0\0��_�\x7f\0\0\x80�_�\x7f\0\00�_�\x7f\0\00�_�\x7f\0\00�_�\x7f\0\00�_�\x7f\0\00�_�\x7f\0\0��_�\x7f\0\0\x15\x1e\0\0\x01\0\0\0\x80�_�\x7f\0\n0")(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*) const at memory:2397
frame #5: 0x0000000100001f46 test`Test::~Test() [inlined] std::__1::unique_ptr<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::default_delete<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >::reset(this=0x00007fff5fbff730, __p="") at memory:2603
frame #6: 0x0000000100001ef3 test`Test::~Test() [inlined] std::__1::unique_ptr<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::default_delete<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >::~unique_ptr(this=0x00007fff5fbff730) at memory:2571
frame #7: 0x0000000100001ef3 test`Test::~Test() [inlined] std::__1::unique_ptr<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::default_delete<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >::~unique_ptr(this=0x00007fff5fbff730) at memory:2571
frame #8: 0x0000000100001ef3 test`Test::~Test(this=0x00007fff5fbff730) at main.cpp:6
frame #9: 0x0000000100001e15 test`Test::~Test(this=0x00007fff5fbff730) at main.cpp:6
frame #10: 0x0000000100001ab6 test`main at main.cpp:28
frame #11: 0x00007fff90c3e235 libdyld.dylib`start + 1
Now I see that the problem is in Test destructor, and from here it's a piece of cake.
Unfortunately, trying to debug this case using gdb under macOS was a total failure. Here is what I've done:
$ gdb ./test
GNU gdb (GDB) 8.0.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin16.7.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from test...Reading symbols from /Users/bazhenov/Developer/linear-counter/tests/test/test.dSYM/Contents/Resources/DWARF/test...done.
done.
(gdb) run
Starting program: /Users/bazhenov/Developer/linear-counter/tests/test/test
[New Thread 0x1403 of process 45204]
warning: unhandled dyld version (15)
Hello tQ�_�
test(45204,0x7fff99ba93c0) malloc: *** error for object 0x7fff5fbff650: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Thread 2 received signal SIGABRT, Aborted.
0x00007fff90d6cd42 in ?? ()
(gdb) bt
#0 0x00007fff90d6cd42 in ?? ()
#1 0x00007fff90e5a457 in ?? ()
#2 0x00007fff5fbff590 in ?? ()
#3 0x0000030700000000 in ?? ()
#4 0x00007fff5fbff590 in ?? ()
#5 0x00007fff5fbff650 in ?? ()
#6 0x00007fff5fbff5a0 in ?? ()
#7 0x00007fff90cd2420 in ?? ()
#8 0xffffffff00000018 in ?? ()
#9 0x00007fff5fbff5b0 in ?? ()
#10 0x00007fffffffffdf in ?? ()
#11 0x00000001000c4000 in ?? ()
#12 0x00007fff5fbff5f0 in ?? ()
#13 0x00007fff90dc1fe7 in ?? ()
#14 0x378b45e65b700074 in ?? ()
#15 0x00007fff99ba00ac in ?? ()
#16 0x0000000000000000 in ?? ()
(gdb)
The question is: why gdb fails to unwind the stack correctly and what options do I have if I need to get correct backtrace using gdb?
why gdb fails to unwind the stack correctly
There are some problems on Mac OS X Sierra with gdb, see this post and gdb bug report.
what options do I have if I need to get correct backtrace using gdb
You can try to downgrade Mac OS (don't know whether is it possible) or try to apply temporary hack patch from above bug report.

set watchpoint on pthread's thread-local storage in gdb

Is it possible to set a watchpoint on pthread's thread-local storage using GDB? I have a program that runs:
struct stored_type *res = pthread_getspecific(tls_key);
...and after a few thousand calls it returns 0 instead of a valid pointer. I'd really love to figure out what's setting that value to 0. I've tried setting breakpoints on pthread_setspecific and pthread_delete_key (the only things I could think of that would reasonably cause the key to change value) and those breakpoints aren't getting hit, so I'm thinking there's some kind of overrun happening.
I'm using Linux x86_64 with glibc 2.23.
... the only things I could think of that would reasonably cause the key to change value
The most likely reasons for pthread_getspecific to return NULL:
you are in fact executing in a new thread, one in which pthread_setspecific hasn't been called,
you are calling pthread_getspecific while current thread is in the process of being destroyed (i.e. pthread_exit is somewhere on the stack),
you are calling pthread_getspecific in a signal handler (none of pthread_* functions are async-signal safe).
Assuming none of the above reasons are true in your case, on with the show.
First we need a test case to demonstrate on.
#include <assert.h>
#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
pthread_key_t key;
void *thrfn(void *p) {
int rc = pthread_setspecific(key, &p);
assert(rc == 0);
sleep(60);
rc = pthread_setspecific(key, (void*)0x112233);
assert(rc == 0);
return p;
}
int main()
{
pthread_t thr;
int rc = pthread_key_create(&key, NULL);
assert(rc == 0);
rc = pthread_create(&thr, NULL, thrfn, NULL);
assert(rc == 0);
sleep(90);
return 0;
}
gcc -g -pthread t.c
gdb -q ./a.out
(gdb) start
Now, it helps very much to have GLIBC that is compiled with debug info. Most distributions provide a libc-dbg or similar package, which supplies that. Looking at pthread_setspecific source, you can see that inside the thread descriptor (self) there is a specific_1stblock array, where the space for first PTHREAD_KEY_2NDLEVEL_SIZE == 32 key slots is pre-allocated (32 distinct keys is usually more than enough).
The value that we pass will be stored in self->specific_1stblock[key].data, and that's exactly the location you'll want to set the watchpoint on.
In our sample program, key == 0 (as this is the very first key). Putting it all together:
Starting program: /tmp/a.out
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Temporary breakpoint 1, main () at t.c:21
21 int rc = pthread_key_create(&key, NULL);
(gdb) b pthread_setspecific
Breakpoint 2 at 0x7ffff7bc9460: file pthread_setspecific.c, line 28.
(gdb) c
Continuing.
[New Thread 0x7ffff77f6700 (LWP 58683)]
[Switching to Thread 0x7ffff77f6700 (LWP 58683)]
Breakpoint 2, __GI___pthread_setspecific (key=0, value=0x7ffff77f5ef8) at pthread_setspecific.c:28
28 pthread_setspecific.c: No such file or directory.
(gdb) n
35 in pthread_setspecific.c
(gdb) n
28 in pthread_setspecific.c
(gdb) p self
$1 = (struct pthread *) 0x7ffff77f6700
(gdb) watch -l self.specific_1stblock[key].data
Hardware watchpoint 3: -location self.specific_1stblock[key].data
(gdb) c
Continuing.
Hardware watchpoint 3: -location self.specific_1stblock[key].data
Old value = (void *) 0x0
New value = (void *) 0x7ffff77f5ef8
__GI___pthread_setspecific (key=<optimized out>, value=0x7ffff77f5ef8) at pthread_setspecific.c:89
89 in pthread_setspecific.c
Note that the new value is exactly the value that we passed to pthread_setspecific.
(gdb) c
Continuing.
Breakpoint 2, __GI___pthread_setspecific (key=0, value=0x112233) at pthread_setspecific.c:28
28 in pthread_setspecific.c
(gdb) c
Continuing.
Hardware watchpoint 3: -location self.specific_1stblock[key].data
Old value = (void *) 0x7ffff77f5ef8
New value = (void *) 0x112233
__GI___pthread_setspecific (key=<optimized out>, value=0x112233) at pthread_setspecific.c:89
89 in pthread_setspecific.c
This is our second pthread_setspecific call
(gdb) c
Continuing.
Hardware watchpoint 3: -location self.specific_1stblock[key].data
Old value = (void *) 0x112233
New value = (void *) 0x0
__nptl_deallocate_tsd () at pthread_create.c:152
152 pthread_create.c: No such file or directory.
And this is thread destruction, which deallocates the thread descriptor itself.
(gdb) c
Continuing.
[Thread 0x7ffff77f6700 (LWP 58683) exited]
[Inferior 1 (process 58677) exited normally]

Segmentation fault on using boost syslog and cpp-netlib

After adding boost syslog into source code, segmentation fault appears inside cpp-netlib library.
I was able to prepare minimum working code snippet to reproduce the problem.
#include <boost/network/protocol/http/client.hpp>
#include <boost/log/utility/setup/file.hpp>
#include <boost/log/sinks/syslog_backend.hpp>
#include <iostream>
using namespace boost::network;
using namespace boost::network::http;
namespace sinks = boost::log::sinks;
int main()
{
client::request request_("http://www.boost.org/");
client client_;
client::response response_ = client_.get(request_);
std::string body_ = body(response_);
std::cout << "body: " << body_;
using syslog_sinkT = sinks::synchronous_sink <sinks::syslog_backend>;
boost::shared_ptr <sinks::syslog_backend> backend = boost::make_shared <sinks::syslog_backend> ();
boost::shared_ptr<syslog_sinkT> sink = boost::make_shared <syslog_sinkT> (backend);
}
When last 2 lines are commented, segmentation fault disappears and everything works fine.
gdb stack trace (approximately, may vary):
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xf7c29b40 (LWP 19874)]
0x00000000 in ?? ()
(gdb) where
#0 0x00000000 in ?? ()
#1 0x083c376c in boost::asio::detail::task_io_service_operation::complete (bytes_transferred=260, ec=..., owner=...,
this=0xf6900710)
at /home/kostidov/prj/third_party-master/boost/boost_1_60_0/__public__/v0/Linux-libc6/include/boost/asio/detail/task_io_service_o$
eration.hpp:38
#2 boost::asio::detail::task_io_service::do_run_one (ec=..., this_thread=..., lock=..., this=<optimized out>)
at /home/kostidov/prj/third_party-master/boost/boost_1_60_0/__public__/v0/Linux-libc6/include/boost/asio/detail/impl/task_io_serv$
ce.ipp:372
#3 boost::asio::detail::task_io_service::run (ec=..., this=0x84ea280)
at /home/kostidov/prj/third_party-master/boost/boost_1_60_0/__public__/v0/Linux-libc6/include/boost/asio/detail/impl/task_io_serv$
ce.ipp:149
#4 boost::asio::io_service::run (this=0x84e9a94)
at /home/kostidov/prj/third_party-master/boost/boost_1_60_0/__public__/v0/Linux-libc6/include/boost/asio/impl/io_service.ipp:59
#5 0x083b5766 in boost::_mfi::mf0<unsigned int, boost::asio::io_service>::operator() (p=<optimized out>, this=<optimized out>)
at /home/kostidov/prj/third_party-master/boost/boost_1_60_0/__public__/v0/Linux-libc6/include/boost/bind/mem_fn_template.hpp:49
#6 boost::_bi::list1<boost::_bi::value<boost::asio::io_service*> >::operator()<unsigned int, boost::_mfi::mf0<unsigned int, boost::a$
io::io_service>, boost::_bi::list0> (a=<synthetic pointer>, f=..., this=0x84ea94c)
at /home/kostidov/prj/third_party-master/boost/boost_1_60_0/__public__/v0/Linux-libc6/include/boost/bind/bind.hpp:249
#7 boost::_bi::bind_t<unsigned int, boost::_mfi::mf0<unsigned int, boost::asio::io_service>, boost::_bi::list1<boost::_bi::value<boo$
t::asio::io_service*> > >::operator() (this=0x84ea944)
at /home/kostidov/prj/third_party-master/boost/boost_1_60_0/__public__/v0/Linux-libc6/include/boost/bind/bind.hpp:1222
#8 boost::detail::thread_data<boost::_bi::bind_t<unsigned int, boost::_mfi::mf0<unsigned int, boost::asio::io_service>, boost::_bi::$
ist1<boost::_bi::value<boost::asio::io_service*> > > >::run (this=0x84ea828)
at /home/kostidov/prj/third_party-master/boost/boost_1_60_0/__public__/v0/Linux-libc6/include/boost/thread/detail/thread.hpp:116
#9 0x0840a4f8 in boost::(anonymous namespace)::thread_proxy (param=0x84ea828) at libs/thread/src/pthread/thread.cpp:167
#10 0xf7de1f70 in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#11 0xf7d18bee in clone () from /lib/i386-linux-gnu/libc.so.6
Problem exists on Ubuntu 14.04 with cpp-netlib 0.11.2 and both boost versions 1_58_0 and 1_60_0. Boost, cpp-netlib and my application are compiled with -std=c++11.
Note 1. Segmentation fault appears inside cpp-netlib before reaching syslog_backend creation. Only presence of last 2 lines guarantees SIGSEGV reproduction.
Note 2. Reproduces only with syslog_backend. Any other logging targets (file, consol) work fine.
The best idea I have is the problem may lay inside boost during static variables initialisation, but I have no proves regarding this version.
Any suggestions?
Seems like I used too many compile options for building both boost and cpp-netlib.
I prepared new build for both boost and cpp-netlib once again, but this time I used as less additional options as possible.
And it works fine.
EDIT: I found the key which causes the error. It's BOOST_ASIO_ENABLE_HANDLER_TRACKING It was defined during the boost compilation, but wasn't defined during compilation of cpp-netlib and my application.
https://svn.boost.org/trac/boost/ticket/11945

Why are concrete function implementations in traits compiled to bridge methods in Scala 2.9.x but not in 2.8.x?

In Scala versions prior to 2.9.0, concrete function implementations in traits were compiled as normal methods. From 2.9.x onward, they are compiled as bridge methods. I'm trying to find the reasoning behind this change, because it negatively affects users of many popular Java frameworks like Spring and Jersey.
Consider the following Scala code:
trait Speaks {
def speak() = {
println("woof")
}
}
class Dog extends Speaks {
def wag() = {
println("wag wag")
}
}
When the Dog class is compiled with scalac version 2.8.1 and decompiled with javap, the result for the "speak" and "wag" functions look like this:
public void speak();
flags: ACC_PUBLIC
Code:
stack=1, locals=1, args_size=1
0: aload_0
1: invokestatic #11 // Method Speaks$class.speak:(LSpeaks;)V
4: return
LineNumberTable:
line 7: 0
public void wag();
flags: ACC_PUBLIC
Code:
stack=2, locals=1, args_size=1
0: getstatic #18 // Field scala/Predef$.MODULE$:Lscala/Predef$;
3: ldc #20 // String wag wag
5: invokevirtual #24 // Method scala/Predef$.println:(Ljava/lang/Object;)V
8: return
LineNumberTable:
line 9: 0
When Dog is compiled with scalac version 2.9.1 and again decompiled, the same two functions look like:
public void speak();
flags: ACC_PUBLIC, ACC_BRIDGE
Code:
stack=1, locals=1, args_size=1
0: aload_0
1: invokestatic #11 // Method Speaks$class.speak:(LSpeaks;)V
4: return
LineNumberTable:
line 7: 0
public void wag();
flags: ACC_PUBLIC
Code:
stack=2, locals=1, args_size=1
0: getstatic #18 // Field scala/Predef$.MODULE$:Lscala/Predef$;
3: ldc #20 // String wag wag
5: invokevirtual #24 // Method scala/Predef$.println:(Ljava/lang/Object;)V
8: return
LineNumberTable:
line 9: 0
The problematic part is the addition of the ACC_BRIDGE flag to the speak() function. Frameworks like Jersey and Spring intentionally do not recognize bridge methods in many cases as workarounds for other issues.
So can anyone explain or point to a good explanation of why this change was made in Scala 2.9.x?
As a followup, is there a way to disable this behavior through a function annotation, compiler flag, etc?
OK it sounds like there is no explanation as to why because it wasn't an intentional change. See this thread:
http://groups.google.com/group/scala-language/browse_thread/thread/67f8884081d46912
And the solution is to use the newest snapshot, or, if the future has arrived as you read this, Scala 2.10

Resources