On Wednesday 30 April 2014 19:12:07 Rob Janssen wrote:
> SM0SVX wrote:
> > 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
It would be better if you could use the 13.12 branch directly instead of
copying files. Then I know we are testing exactly the same code.
svn co svn://svn.code.sf.net/p/svxlink/svn/branches/releases/13.12
> 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:
> (gdb) bt
> #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) at Macho.hpp:891
> #6 0x081705d8 in Macho::Link<Voter::SwitchActiveRx,
> Voter::SquelchOpen>::_deleteBox ( this=0xa5076a8, instance=...) at
> #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) at
> /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:84 #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) at /usr/include/sigc++-2.0/sigc++/functors/slot.h:137
> #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 notsvn
checkout svn://svn.code.sf.net/p/svxlink/svn/trunk svxlink-svn
Yes, it's probably so. There were two bugs. I have now fixed another bug which
caused the voter to crash. I do not get exactly the same stack trace as you
but I hope it's the same bug causing both the crashes.
Please try the new code out. I hope it will fix your crash problems.
> > 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?
109 is not a problem but too high values may be a problem. There is an upper
limit of 120 above which SvxLink will interpret it as a bogus value and
instead report a zero signal level. I'm not happy with this limitation but it
was introduced as a workaround for receivers where unsquelched audio is not
available. When the squelch close, SvxLink "hear" maximum silence and
interprets this as a very strong signal. The voter will then switch to this
receiver which of course is wrong. Since that is a special case, this behavior
should probably be turned on by configuration. It's presently hard coded.
> 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.
Yes, I've considered clamping it. That should be fine as long as we handle the
case described above.
73's de SM0SVX / Tobias