> Now you have a fix in both Subversion trunk and the 13.12 branch which I hope
> will resolve the problem. I was able to quite easily provoke the system to
> crash when setting BUFFER_LENGTH to 100. The problem I fixed occurred when a
> receiver reported a signal strength lower than -100 in certain situations. It
> was some stupid code that assumed that a signal level below -100 could never
> be reported. That code is now fixed to be safe.
Thank you for your work!
I took the Voter.cpp and Voter.h from svn and compiled it in the 13.12 version, set the
buffer to 100 again but shortly afterwards it again crashed. After that it has been up for
another hour so it has not become worse.
This time it was the assertion error:
svxlink: Macho.hpp:891: void Macho::_SubstateInstance<S>::deleteBox() [with S = Voter::SwitchActiveRx]: Assertion `myBox' failed.
Last log messages are:
Wed Apr 30 18:01:13 2014: Voter: Switching from "NetRx_HVS" (0) to "Rx1" (22.2904)
Wed Apr 30 18:01:16 2014: Voter: Switching from "Rx1" (23.6051) to "NetRx_HVS" (114.441)
Wed Apr 30 18:01:22 2014: Voter: Switching from "NetRx_HVS" (0) to "Rx1" (23.6532)
Wed Apr 30 18:01:22 2014: Voter: The squelch is CLOSED (Rx1=41.7713)
Wed Apr 30 18:01:22 2014: Voter: The squelch is OPEN (Rx1=16.1715)
The crash was 18:01:24
This is the backtrace in gdb:
#0 0x00b92424 in __kernel_vsyscall ()
#1 0x00400b11 in raise () from /lib/libc.so.6
#2 0x004023ea in abort () from /lib/libc.so.6
#3 0x003f9e2b in __assert_fail_base () from /lib/libc.so.6
#4 0x003f9ee6 in __assert_fail () from /lib/libc.so.6
#5 0x0816f276 in Macho::_SubstateInstance<Voter::SwitchActiveRx>::deleteBox (this=0xa5075f8)
#6 0x081705d8 in Macho::Link<Voter::SwitchActiveRx, Voter::SquelchOpen>::_deleteBox (
this=0xa5076a8, instance=...) at Macho.hpp:1959
#7 0x0818f6d4 in Macho::_StateInstance::exit (this=0xa5075f8, next=...) at Macho.cpp:144
#8 0x0818fbaa in Macho::_MachineBase::rattleOn (this=0xa1a4d1c) at Macho.cpp:317
#9 0x081674a0 in Macho::Machine<Voter::Top>::dispatch (this=0xa1a4d1c, event=0xa55b760,
destroy=true) at Macho.hpp:1806
#10 0x081628ff in Voter::Top::eventTimerExpired (this=0xa1a7500, t=0xa1a754c) at Voter.cpp:794
#11 0x0816e3ec in sigc::bound_mem_functor1<void, Voter::Top, Async::Timer*>::operator() (
this=0xa1a75ec, _A_a1=@0xa560608) at /usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:1851
#12 0x0816d7db in sigc::adaptor_functor<sigc::bound_mem_functor1<void, Voter::Top, Async::Timer*> >::operator()<Async::Timer* const&> (this=0xa1a75e8, _A_arg1=@0xa560608)
#13 0x0816c6c5 in sigc::internal::slot_call1<sigc::bound_mem_functor1<void, Voter::Top, Async::Timer*>, void, Async::Timer*>::call_it (rep=0xa1a75d0, a_1=@0xa560608)
#14 0x002abd08 in sigc::internal::signal_emit1<void, Async::Timer*, sigc::nil>::emit (
impl=0xa1a4c88, _A_a1=@0xa560608) at /usr/include/sigc++-2.0/sigc++/signal.h:1006
#15 0x002ab3af in sigc::signal1<void, Async::Timer*, sigc::nil>::emit (this=0xa1a7550,
_A_a1=@0xa560608) at /usr/include/sigc++-2.0/sigc++/signal.h:2773
#16 0x002aaafa in sigc::signal1<void, Async::Timer*, sigc::nil>::operator() (this=0xa1a7550,
_A_a1=@0xa560608) at /usr/include/sigc++-2.0/sigc++/signal.h:2781
#17 0x002a9935 in Async::CppApplication::exec (this=0xbf901230) at AsyncCppApplication.cpp:228
#18 0x0810dd58 in main (argc=3, argv=0xbf901724) at svxlink.cpp:514
Note that we had 2 kinds of crashes, a segmentation violation and an assertion failure, and it may be that
one is now fixed and the other not yet.
> Have you properly calibrated the signal level measurements for all your
> receivers? If not, that could have been a reason for the system producing very
> low siglev values. Normally they should be within 0 to 100.
Ok it has been a theory in our group as well that the calibration has something to do with it. But it was not
completely pinpointed what the exact requirements are. We have recalibrated several times, and at the
moment the values sometimes are slightly below zero but not -100 anymore.
So while this may have been a factor, it probably is not the cause of the current problem. I sometimes see
values slightly above 100 (e.g. 109), is that a problem as well? Maybe the value can be clamped somewhere?
Our problem is that our sites are broadcast transmitter sites. The antenna of the secondary receiver we
are now testing is only about a meter from an FM broadcast transmitter antenna radiating several kilowatts.
In such an environment it is sometimes difficult to calibrate to a fixed noise floor.