Activity log for bug #758068

Date Who What changed Old value New value Message
2011-04-11 20:53:22 Patrick Crews bug added bug
2011-04-11 20:53:40 Patrick Crews drizzle: status New Confirmed
2011-04-11 20:53:49 Patrick Crews drizzle: importance Undecided High
2011-04-11 20:54:03 Patrick Crews drizzle: assignee David Shrewsbury (dshrews)
2011-04-11 20:54:13 Patrick Crews nominated for series drizzle/elliott
2011-04-11 20:54:13 Patrick Crews bug task added drizzle/elliott
2011-04-11 20:54:13 Patrick Crews nominated for series drizzle/fremont
2011-04-11 20:54:13 Patrick Crews bug task added drizzle/fremont
2011-04-27 14:04:08 David Shrewsbury drizzle/fremont: assignee David Shrewsbury (dshrews)
2013-08-08 06:40:06 Stewart Smith drizzle/7.0: status New Won't Fix
2019-03-28 09:33:12 nflfdglkfm b summary random slave crash on master crash + restart Buy Ambien Online Overnight: Diagnosis And Treatment Options
2019-03-28 09:33:33 nflfdglkfm b description When running the randgen test for master crash + recovery, we are seeing random instances where the slave crashes. This occurs ~1 in 20 times and I have seen several different stack traces for this. To repeat: ./dbqp --mode=randgen --randgen-path=/path/to/randgen --suite=slave_plugin multi_thread1_crash_recover --repeat=20 Backtrace: 110411 13:43:29 - drizzled got signal 6; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. read_buffer_size=131072 max_used_connections=2 connection_count=2 It is possible that drizzled could use up to (read_buffer_size + sort_buffer_size)*thread_count bytes of memory Hope that's ok; if not, decrease some variables in the equation. Number of stack frames obtained: 26 /drizzle/drizzled/.libs/lt-drizzled() [0x6b3b0c] () gsignal() abort() () () cfree() __gnu_cxx::new_allocator<char>::deallocate(char*, unsigned long) std::_Vector_base<char, std::allocator<char> >::_M_deallocate(char*, unsigned long) std::_Vector_base<char, std::allocator<char> >::~_Vector_base() /drizzle/drizzled/.libs/lt-drizzled() [0x50a1e5] __gnu_cxx::new_allocator<std::vector<char, std::allocator<char> > >::destroy(std::vector<char, std::allocator<char> >*) /drizzle/drizzled/.libs/lt-drizzled() [0x5484da] std::queue<std::vector<char, std::allocator<char> >, std::deque<std::vector<char, std::allocator<char> >, std::allocator<std::vector<char, std::allocator<char> > > > >::pop() /drizzle/drizzled/.libs/lt-drizzled() [0x5459ee] drizzled::Session::executeStatement() drizzled::Session::run() () () () () () thread_proxy() () clone() When running the randgen test for master crash + recovery, we are seeing random instances where the slave crashes. This occurs ~1 in 20 times and I have seen several different stack traces for this. https://yourrxpills.com/product-category/buy-ambien-online/ To repeat: ./dbqp --mode=randgen --randgen-path=/path/to/randgen --suite=slave_plugin multi_thread1_crash_recover --repeat=20 Backtrace: 110411 13:43:29 - drizzled got signal 6; This could be because you hit a bug. It is also possible that this binary  or one of the libraries it was linked against is corrupt, improperly built,  or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. read_buffer_size=131072 max_used_connections=2 connection_count=2 It is possible that drizzled could use up to (read_buffer_size + sort_buffer_size)*thread_count bytes of memory Hope that's ok; if not, decrease some variables in the equation. Number of stack frames obtained: 26 /drizzle/drizzled/.libs/lt-drizzled() [0x6b3b0c] () gsignal() abort() () () cfree() __gnu_cxx::new_allocator<char>::deallocate(char*, unsigned long) std::_Vector_base<char, std::allocator<char> >::_M_deallocate(char*, unsigned long) std::_Vector_base<char, std::allocator<char> >::~_Vector_base() /drizzle/drizzled/.libs/lt-drizzled() [0x50a1e5] __gnu_cxx::new_allocator<std::vector<char, std::allocator<char> > >::destroy(std::vector<char, std::allocator<char> >*) /drizzle/drizzled/.libs/lt-drizzled() [0x5484da] std::queue<std::vector<char, std::allocator<char> >, std::deque<std::vector<char, std::allocator<char> >, std::allocator<std::vector<char, std::allocator<char> > > > >::pop() /drizzle/drizzled/.libs/lt-drizzled() [0x5459ee] drizzled::Session::executeStatement() drizzled::Session::run() () () () () () thread_proxy() () clone()
2019-03-29 11:23:21 Colin Watson summary Buy Ambien Online Overnight: Diagnosis And Treatment Options random slave crash on master crash + restart
2019-03-29 11:23:31 Colin Watson description When running the randgen test for master crash + recovery, we are seeing random instances where the slave crashes. This occurs ~1 in 20 times and I have seen several different stack traces for this. https://yourrxpills.com/product-category/buy-ambien-online/ To repeat: ./dbqp --mode=randgen --randgen-path=/path/to/randgen --suite=slave_plugin multi_thread1_crash_recover --repeat=20 Backtrace: 110411 13:43:29 - drizzled got signal 6; This could be because you hit a bug. It is also possible that this binary  or one of the libraries it was linked against is corrupt, improperly built,  or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. read_buffer_size=131072 max_used_connections=2 connection_count=2 It is possible that drizzled could use up to (read_buffer_size + sort_buffer_size)*thread_count bytes of memory Hope that's ok; if not, decrease some variables in the equation. Number of stack frames obtained: 26 /drizzle/drizzled/.libs/lt-drizzled() [0x6b3b0c] () gsignal() abort() () () cfree() __gnu_cxx::new_allocator<char>::deallocate(char*, unsigned long) std::_Vector_base<char, std::allocator<char> >::_M_deallocate(char*, unsigned long) std::_Vector_base<char, std::allocator<char> >::~_Vector_base() /drizzle/drizzled/.libs/lt-drizzled() [0x50a1e5] __gnu_cxx::new_allocator<std::vector<char, std::allocator<char> > >::destroy(std::vector<char, std::allocator<char> >*) /drizzle/drizzled/.libs/lt-drizzled() [0x5484da] std::queue<std::vector<char, std::allocator<char> >, std::deque<std::vector<char, std::allocator<char> >, std::allocator<std::vector<char, std::allocator<char> > > > >::pop() /drizzle/drizzled/.libs/lt-drizzled() [0x5459ee] drizzled::Session::executeStatement() drizzled::Session::run() () () () () () thread_proxy() () clone() When running the randgen test for master crash + recovery, we are seeing random instances where the slave crashes. This occurs ~1 in 20 times and I have seen several different stack traces for this. To repeat: ./dbqp --mode=randgen --randgen-path=/path/to/randgen --suite=slave_plugin multi_thread1_crash_recover --repeat=20 Backtrace: 110411 13:43:29 - drizzled got signal 6; This could be because you hit a bug. It is also possible that this binary  or one of the libraries it was linked against is corrupt, improperly built,  or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. read_buffer_size=131072 max_used_connections=2 connection_count=2 It is possible that drizzled could use up to (read_buffer_size + sort_buffer_size)*thread_count bytes of memory Hope that's ok; if not, decrease some variables in the equation. Number of stack frames obtained: 26 /drizzle/drizzled/.libs/lt-drizzled() [0x6b3b0c] () gsignal() abort() () () cfree() __gnu_cxx::new_allocator<char>::deallocate(char*, unsigned long) std::_Vector_base<char, std::allocator<char> >::_M_deallocate(char*, unsigned long) std::_Vector_base<char, std::allocator<char> >::~_Vector_base() /drizzle/drizzled/.libs/lt-drizzled() [0x50a1e5] __gnu_cxx::new_allocator<std::vector<char, std::allocator<char> > >::destroy(std::vector<char, std::allocator<char> >*) /drizzle/drizzled/.libs/lt-drizzled() [0x5484da] std::queue<std::vector<char, std::allocator<char> >, std::deque<std::vector<char, std::allocator<char> >, std::allocator<std::vector<char, std::allocator<char> > > > >::pop() /drizzle/drizzled/.libs/lt-drizzled() [0x5459ee] drizzled::Session::executeStatement() drizzled::Session::run() () () () () () thread_proxy() () clone()