Error in voter

classic Classic list List threaded Threaded
45 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Error in voter

PE1RJV
Since the last week we added a second receiver to our repeater system.
More or less once a day svxlink quits with an error:

svxlink: Voter.cpp:1118: virtual void Voter::Receiving::timerExpired(): Assertion `bestSrx() != 0' failed.

It seems to be a problem with a buffer overflow on the remotetrx site, but I'm not sure.
Any clues on how to fix this ?

Best 73s, Paul
Reply | Threaded
Open this post in threaded view
|

Re: Error in voter

Tobias Blomberg
On Sunday 12 January 2014 23:21:28 PE1RJV wrote:
> Since the last week we added a second receiver to our repeater system.
> More or less once a day svxlink quits with an error:
>
> svxlink: Voter.cpp:1118: virtual void Voter::Receiving::timerExpired():
> Assertion `bestSrx() != 0' failed.

Did you change any of the default config for the Voter?  Can you post the config
for the Voter and the receivers.

73's de SM0SVX / Tobias

>
> It seems to be a problem with a buffer overflow on the remotetrx site, but
> I'm not sure.
> Any clues on how to fix this ?
>
> Best 73s, Paul
>
>
>
> -----
> PI3UTR


------------------------------------------------------------------------------
WatchGuard Dimension instantly turns raw network data into actionable
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Error in voter

PE1RJV
SvxLink:
 
[Voter]
TYPE=Voter
RECEIVERS=Rx1,NetRx1,NetRx2,NetRx3
VOTING_DELAY=100
BUFFER_LENGTH=0
REVOTE_INTERVAL=1000
HYSTERESIS=50
RX_SWITCH_DELAY=500
SQL_CLOSE_REVOTE_DELAY=500
 
[Rx1]
TYPE=Local
AUDIO_DEV=alsa:plughw:0,0
AUDIO_CHANNEL=0
SQL_DET=SERIAL
#SQL_DET=CTCSS
#SQL_DET=SIGLEV
SQL_START_DELAY=0
SQL_DELAY=40
SQL_HANGTIME=50
#SQL_EXTENDED_HANGTIME=500
#SQL_EXTENDED_HANGTIME_THRESH=15
SQL_TIMEOUT=900
#VOX_FILTER_DEPTH=20
#VOX_THRESH=1000
#CTCSS_MODE=2
CTCSS_FQ=77.0
#CTCSS_SNR_OFFSET=0
#CTCSS_OPEN_THRESH=15
#CTCSS_CLOSE_THRESH=9
#CTCSS_BPF_LOW=60
#CTCSS_BPF_HIGH=230
SERIAL_PORT=/dev/ttyS0
SERIAL_PIN=DCD:SET
#SERIAL_SET_PINS=DTR
#EVDEV_DEVNAME=/dev/input/by-id/usb-SYNIC_SYNIC_Wireless_Audio-event-if03
#EVDEV_OPEN=1,163,1
#EVDEV_CLOSE=1,163,0
SIGLEV_DET=NOISE
SIGLEV_SLOPE=110.99
SIGLEV_OFFSET=-720.05
#TONE_SIGLEV_MAP=100,84,60,50,37,32,28,23,19,8
SIGLEV_OPEN_THRESH=30
SIGLEV_CLOSE_THRESH=10
DEEMPHASIS=0
SQL_TAIL_ELIM=100
#PREAMP=6
PEAK_METER=0
#DTMF_DEC_TYPE=S54S
#DTMF_SERIAL=/dev/ttyS0
#DTMF_DEC_TYPE=INTERNAL
DTMF_DEC_TYPE=NONE
DTMF_MUTING=1
DTMF_HANGTIME=200
DTMF_MAX_FWD_TWIST=8
DTMF_MAX_REV_TWIST=4
1750_MUTING=1
#SEL5_DEC_TYPE=INTERNAL
#SEL5_TYPE=ZVEI1
RemoteTRX:
 
[Rx1]
TYPE=Local
AUDIO_DEV=alsa:plughw:0
AUDIO_CHANNEL=0
#SQL_DET=CTCSS
SQL_DET=SIGLEV
SQL_START_DELAY=50
SQL_DELAY=40
SQL_HANGTIME=200
SQL_EXTENDED_HANGTIME=500
SQL_EXTENDED_HANGTIME_THRESH=10
SQL_TIMEOUT=600
#VOX_FILTER_DEPTH=20
#VOX_THRESH=1000
#CTCSS_MODE=2
CTCSS_FQ=77.0
CTCSS_SNR_OFFSET=-23.50
CTCSS_OPEN_THRESH=15
CTCSS_CLOSE_THRESH=9
CTCSS_BPF_LOW=60
CTCSS_BPF_HIGH=270
#SERIAL_PORT=/dev/ttyS0
#SERIAL_PIN=CTS:SET
#SERIAL_SET_PINS=DTR
#EVDEV_DEVNAME=/dev/input/by-id/usb-SYNIC_SYNIC_Wireless_Audio-event-if03
#EVDEV_OPEN=1,163,1
#EVDEV_CLOSE=1,163,0
SIGLEV_DET=NOISE
SIGLEV_SLOPE=30.70
SIGLEV_OFFSET=-88.75
#TONE_SIGLEV_MAP=100,84,60,50,37,32,28,23,19,8
SIGLEV_OPEN_THRESH=30
SIGLEV_CLOSE_THRESH=10
DEEMPHASIS=0
SQL_TAIL_ELIM=200
#PREAMP=6
PEAK_METER=1
#DTMF_DEC_TYPE=S54S
#DTMF_SERIAL=/dev/ttyS0
#DTMF_DEC_TYPE=INTERNAL
DTMF_DEC_TYPE=NONE
DTMF_MUTING=1
DTMF_HANGTIME=200
#DTMF_MAX_FWD_TWIST=8
#DTMF_MAX_REV_TWIST=4
1750_MUTING=1
#SEL5_DEC_TYPE=INTERNAL
#SEL5_TYPE=ZVEI1
 
73s, Paul

Sent: Tuesday, January 28, 2014 9:56 PM
Subject: Re: Error in voter

On Sunday 12 January 2014 23:21:28 PE1RJV wrote:
> Since the last week we added a second receiver to our repeater system.
> More or less once a day svxlink quits with an error:
>
> svxlink: Voter.cpp:1118: virtual void Voter::Receiving::timerExpired():
> Assertion `bestSrx() != 0' failed.

Did you change any of the default config for the Voter?  Can you post the config
for the Voter and the receivers.

73's de SM0SVX / Tobias

>
> It seems to be a problem with a buffer overflow on the remotetrx site, but
> I'm not sure.
> Any clues on how to fix this ?
>
> Best 73s, Paul
>
>
>
> -----
> PI3UTR

------------------------------------------------------------------------------
WatchGuard Dimension instantly turns raw network data into actionable
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel



If you reply to this email, your message will be added to the discussion below:
http://svxlink.996268.n3.nabble.com/Error-in-voter-tp3254p3273.html
To start a new topic under svxlink-devel, email [hidden email]
To unsubscribe from SvxLink, click here.
NAML
Reply | Threaded
Open this post in threaded view
|

Re: Error in voter

Tobias Blomberg
Cannot see anything strange there. I'll dig into the source code to see what's
wrong.

73's de SM0SVX / Tobias


On Wednesday 29 January 2014 00:01:54 PE1RJV wrote:

> SvxLink:
>
> [Voter]
> TYPE=Voter
> RECEIVERS=Rx1,NetRx1,NetRx2,NetRx3
> VOTING_DELAY=100
> BUFFER_LENGTH=0
> REVOTE_INTERVAL=1000
> HYSTERESIS=50
> RX_SWITCH_DELAY=500
> SQL_CLOSE_REVOTE_DELAY=500
>
> [Rx1]
> TYPE=Local
> AUDIO_DEV=alsa:plughw:0,0
> AUDIO_CHANNEL=0
> SQL_DET=SERIAL
> #SQL_DET=CTCSS
> #SQL_DET=SIGLEV
> SQL_START_DELAY=0
> SQL_DELAY=40
> SQL_HANGTIME=50
> #SQL_EXTENDED_HANGTIME=500
> #SQL_EXTENDED_HANGTIME_THRESH=15
> SQL_TIMEOUT=900
> #VOX_FILTER_DEPTH=20
> #VOX_THRESH=1000
> #CTCSS_MODE=2
> CTCSS_FQ=77.0
> #CTCSS_SNR_OFFSET=0
> #CTCSS_OPEN_THRESH=15
> #CTCSS_CLOSE_THRESH=9
> #CTCSS_BPF_LOW=60
> #CTCSS_BPF_HIGH=230
> SERIAL_PORT=/dev/ttyS0
> SERIAL_PIN=DCD:SET
> #SERIAL_SET_PINS=DTR
> #EVDEV_DEVNAME=/dev/input/by-id/usb-SYNIC_SYNIC_Wireless_Audio-event-if03
> #EVDEV_OPEN=1,163,1
> #EVDEV_CLOSE=1,163,0
> SIGLEV_DET=NOISE
> SIGLEV_SLOPE=110.99
> SIGLEV_OFFSET=-720.05
> #TONE_SIGLEV_MAP=100,84,60,50,37,32,28,23,19,8
> SIGLEV_OPEN_THRESH=30
> SIGLEV_CLOSE_THRESH=10
> DEEMPHASIS=0
> SQL_TAIL_ELIM=100
> #PREAMP=6
> PEAK_METER=0
> #DTMF_DEC_TYPE=S54S
> #DTMF_SERIAL=/dev/ttyS0
> #DTMF_DEC_TYPE=INTERNAL
> DTMF_DEC_TYPE=NONE
> DTMF_MUTING=1
> DTMF_HANGTIME=200
> DTMF_MAX_FWD_TWIST=8
> DTMF_MAX_REV_TWIST=4
> 1750_MUTING=1
> #SEL5_DEC_TYPE=INTERNAL
> #SEL5_TYPE=ZVEI1
>
> RemoteTRX:
>
> [Rx1]
> TYPE=Local
> AUDIO_DEV=alsa:plughw:0
> AUDIO_CHANNEL=0
> #SQL_DET=CTCSS
> SQL_DET=SIGLEV
> SQL_START_DELAY=50
> SQL_DELAY=40
> SQL_HANGTIME=200
> SQL_EXTENDED_HANGTIME=500
> SQL_EXTENDED_HANGTIME_THRESH=10
> SQL_TIMEOUT=600
> #VOX_FILTER_DEPTH=20
> #VOX_THRESH=1000
> #CTCSS_MODE=2
> CTCSS_FQ=77.0
> CTCSS_SNR_OFFSET=-23.50
> CTCSS_OPEN_THRESH=15
> CTCSS_CLOSE_THRESH=9
> CTCSS_BPF_LOW=60
> CTCSS_BPF_HIGH=270
> #SERIAL_PORT=/dev/ttyS0
> #SERIAL_PIN=CTS:SET
> #SERIAL_SET_PINS=DTR
> #EVDEV_DEVNAME=/dev/input/by-id/usb-SYNIC_SYNIC_Wireless_Audio-event-if03
> #EVDEV_OPEN=1,163,1
> #EVDEV_CLOSE=1,163,0
> SIGLEV_DET=NOISE
> SIGLEV_SLOPE=30.70
> SIGLEV_OFFSET=-88.75
> #TONE_SIGLEV_MAP=100,84,60,50,37,32,28,23,19,8
> SIGLEV_OPEN_THRESH=30
> SIGLEV_CLOSE_THRESH=10
> DEEMPHASIS=0
> SQL_TAIL_ELIM=200
> #PREAMP=6
> PEAK_METER=1
> #DTMF_DEC_TYPE=S54S
> #DTMF_SERIAL=/dev/ttyS0
> #DTMF_DEC_TYPE=INTERNAL
> DTMF_DEC_TYPE=NONE
> DTMF_MUTING=1
> DTMF_HANGTIME=200
> #DTMF_MAX_FWD_TWIST=8
> #DTMF_MAX_REV_TWIST=4
> 1750_MUTING=1
> #SEL5_DEC_TYPE=INTERNAL
> #SEL5_TYPE=ZVEI1
>
> 73s, Paul
>
>
> From: SM0SVX [via SvxLink]
> Sent: Tuesday, January 28, 2014 9:56 PM
> To: PE1RJV
> Subject: Re: Error in voter
>
> On Sunday 12 January 2014 23:21:28 PE1RJV wrote:
> > Since the last week we added a second receiver to our repeater system.
> > More or less once a day svxlink quits with an error:
> >
> > svxlink: Voter.cpp:1118: virtual void Voter::Receiving::timerExpired():
> > Assertion `bestSrx() != 0' failed.
>
> Did you change any of the default config for the Voter?  Can you post the
> config for the Voter and the receivers.
>
> 73's de SM0SVX / Tobias
>
> > It seems to be a problem with a buffer overflow on the remotetrx site, but
> > I'm not sure.
> > Any clues on how to fix this ?
> >
> > Best 73s, Paul
> >
> >
> >
> > -----
> > PI3UTR


------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Error in voter

Tobias Blomberg
Paul,

Try latest Subversion trunk now.

73's de SM0SVX / Tobias


On Monday 03 February 2014 08:51:20 SM0SVX wrote:

> Cannot see anything strange there. I'll dig into the source code to see
> what's wrong.
>
> 73's de SM0SVX / Tobias
>
> On Wednesday 29 January 2014 00:01:54 PE1RJV wrote:
> > SvxLink:
> >
> > [Voter]
> > TYPE=Voter
> > RECEIVERS=Rx1,NetRx1,NetRx2,NetRx3
> > VOTING_DELAY=100
> > BUFFER_LENGTH=0
> > REVOTE_INTERVAL=1000
> > HYSTERESIS=50
> > RX_SWITCH_DELAY=500
> > SQL_CLOSE_REVOTE_DELAY=500
> >
> > [Rx1]
> > TYPE=Local
> > AUDIO_DEV=alsa:plughw:0,0
> > AUDIO_CHANNEL=0
> > SQL_DET=SERIAL
> > #SQL_DET=CTCSS
> > #SQL_DET=SIGLEV
> > SQL_START_DELAY=0
> > SQL_DELAY=40
> > SQL_HANGTIME=50
> > #SQL_EXTENDED_HANGTIME=500
> > #SQL_EXTENDED_HANGTIME_THRESH=15
> > SQL_TIMEOUT=900
> > #VOX_FILTER_DEPTH=20
> > #VOX_THRESH=1000
> > #CTCSS_MODE=2
> > CTCSS_FQ=77.0
> > #CTCSS_SNR_OFFSET=0
> > #CTCSS_OPEN_THRESH=15
> > #CTCSS_CLOSE_THRESH=9
> > #CTCSS_BPF_LOW=60
> > #CTCSS_BPF_HIGH=230
> > SERIAL_PORT=/dev/ttyS0
> > SERIAL_PIN=DCD:SET
> > #SERIAL_SET_PINS=DTR
> > #EVDEV_DEVNAME=/dev/input/by-id/usb-SYNIC_SYNIC_Wireless_Audio-event-if03
> > #EVDEV_OPEN=1,163,1
> > #EVDEV_CLOSE=1,163,0
> > SIGLEV_DET=NOISE
> > SIGLEV_SLOPE=110.99
> > SIGLEV_OFFSET=-720.05
> > #TONE_SIGLEV_MAP=100,84,60,50,37,32,28,23,19,8
> > SIGLEV_OPEN_THRESH=30
> > SIGLEV_CLOSE_THRESH=10
> > DEEMPHASIS=0
> > SQL_TAIL_ELIM=100
> > #PREAMP=6
> > PEAK_METER=0
> > #DTMF_DEC_TYPE=S54S
> > #DTMF_SERIAL=/dev/ttyS0
> > #DTMF_DEC_TYPE=INTERNAL
> > DTMF_DEC_TYPE=NONE
> > DTMF_MUTING=1
> > DTMF_HANGTIME=200
> > DTMF_MAX_FWD_TWIST=8
> > DTMF_MAX_REV_TWIST=4
> > 1750_MUTING=1
> > #SEL5_DEC_TYPE=INTERNAL
> > #SEL5_TYPE=ZVEI1
> >
> > RemoteTRX:
> >
> > [Rx1]
> > TYPE=Local
> > AUDIO_DEV=alsa:plughw:0
> > AUDIO_CHANNEL=0
> > #SQL_DET=CTCSS
> > SQL_DET=SIGLEV
> > SQL_START_DELAY=50
> > SQL_DELAY=40
> > SQL_HANGTIME=200
> > SQL_EXTENDED_HANGTIME=500
> > SQL_EXTENDED_HANGTIME_THRESH=10
> > SQL_TIMEOUT=600
> > #VOX_FILTER_DEPTH=20
> > #VOX_THRESH=1000
> > #CTCSS_MODE=2
> > CTCSS_FQ=77.0
> > CTCSS_SNR_OFFSET=-23.50
> > CTCSS_OPEN_THRESH=15
> > CTCSS_CLOSE_THRESH=9
> > CTCSS_BPF_LOW=60
> > CTCSS_BPF_HIGH=270
> > #SERIAL_PORT=/dev/ttyS0
> > #SERIAL_PIN=CTS:SET
> > #SERIAL_SET_PINS=DTR
> > #EVDEV_DEVNAME=/dev/input/by-id/usb-SYNIC_SYNIC_Wireless_Audio-event-if03
> > #EVDEV_OPEN=1,163,1
> > #EVDEV_CLOSE=1,163,0
> > SIGLEV_DET=NOISE
> > SIGLEV_SLOPE=30.70
> > SIGLEV_OFFSET=-88.75
> > #TONE_SIGLEV_MAP=100,84,60,50,37,32,28,23,19,8
> > SIGLEV_OPEN_THRESH=30
> > SIGLEV_CLOSE_THRESH=10
> > DEEMPHASIS=0
> > SQL_TAIL_ELIM=200
> > #PREAMP=6
> > PEAK_METER=1
> > #DTMF_DEC_TYPE=S54S
> > #DTMF_SERIAL=/dev/ttyS0
> > #DTMF_DEC_TYPE=INTERNAL
> > DTMF_DEC_TYPE=NONE
> > DTMF_MUTING=1
> > DTMF_HANGTIME=200
> > #DTMF_MAX_FWD_TWIST=8
> > #DTMF_MAX_REV_TWIST=4
> > 1750_MUTING=1
> > #SEL5_DEC_TYPE=INTERNAL
> > #SEL5_TYPE=ZVEI1
> >
> > 73s, Paul
> >
> >
> > From: SM0SVX [via SvxLink]
> > Sent: Tuesday, January 28, 2014 9:56 PM
> > To: PE1RJV
> > Subject: Re: Error in voter
> >
> > On Sunday 12 January 2014 23:21:28 PE1RJV wrote:
> > > Since the last week we added a second receiver to our repeater system.
> > > More or less once a day svxlink quits with an error:
> > >
> > > svxlink: Voter.cpp:1118: virtual void Voter::Receiving::timerExpired():
> > > Assertion `bestSrx() != 0' failed.
> >
> > Did you change any of the default config for the Voter?  Can you post the
> > config for the Voter and the receivers.
> >
> > 73's de SM0SVX / Tobias
> >
> > > It seems to be a problem with a buffer overflow on the remotetrx site,
> > > but
> > > I'm not sure.
> > > Any clues on how to fix this ?
> > >
> > > Best 73s, Paul
> > >
> > >
> > >
> > > -----
> > > PI3UTR
>
> ----------------------------------------------------------------------------
> -- Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
> _______________________________________________
> Svxlink-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/svxlink-devel


------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Error in voter

PE1RJV
I updated the system today, in about a week I will report if the results.
TIA !
Reply | Threaded
Open this post in threaded view
|

Re: Error in voter

Tobias Blomberg
On Monday 24 February 2014 03:35:33 PE1RJV wrote:
> I updated the system today, in about a week I will report if the results.

Any feedback on this?

73's de SM0SVX / Tobias


> TIA !
>
>
>
> -----
> PI3UTR


------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Error in voter

PE1RJV
Hi,

Not a solid feedback unfortunately, it still is not working ok.
It seems to be triggered by some buffer under- or overflow in the remotetrx, I still have to investigate it further.
Finding the time to do so is my issue...

73s, Paul

On 22-3-2014 16:31, SM0SVX [via SvxLink] wrote:
On Monday 24 February 2014 03:35:33 PE1RJV wrote:
> I updated the system today, in about a week I will report if the results.

Any feedback on this?

73's de SM0SVX / Tobias


> TIA !
>
>
>
> -----
> PI3UTR


------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel



If you reply to this email, your message will be added to the discussion below:
http://svxlink.996268.n3.nabble.com/Error-in-voter-tp3254p3398.html
To start a new topic under svxlink-devel, email [hidden email]
To unsubscribe from SvxLink, click here.
NAML

Reply | Threaded
Open this post in threaded view
|

Re: Error in voter

Rob Janssen
I am helping Paul with debugging this problem.
I started svxlink 13.12 in interactive mode and with core dumping enabled, and printed the
call backtrace in gdb.   It is included as attachment.  When you require the core file
or want me to print other info from gdb please mention it.

We have a setup, mainly for testing, where two receivers are connected, one remote
and one local.  But the remote receiver is close by, and many stations are received on
both receivers.

What appears to be happening is when the station ends transmitting, both the local and
remote receiver squelch close at "the same time", and a race condition appears to exist
when it is handling the "squelch off" event for one receiver, finding the next receiver to
use, and then finding that one is closing the squelch as well.  The crashes always occur
at the end of a transmission from a station.  It can work for a few hours or it can crash in
a couple of minutes.

I cannot imagine that race conditions like this would not have been foreseen in the design
of svxlink, so I first show you the stackdump before I start to investigate very deeply how
this can happen and how svxlink handles serialization in general.
(which I have not yet done)

Rob PE1CHL


------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel

gdb.txt (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Error in voter

Rob Janssen
In reply to this post by PE1RJV
Here are a couple more crashdumps from the same repeater.
The first 3 are apparently a different situation that ends in an Abort (signal 6),
the last one is again a Segmentation Violation (signal 11) and looks much like the first.

Rob PE1CHL

------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel

gdb.txt (20K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Error in voter

Tobias Blomberg
On Sunday 13 April 2014 18:13:23 Rob Janssen wrote:
> Here are a couple more crashdumps from the same repeater.
> The first 3 are apparently a different situation that ends in an Abort
> (signal 6), the last one is again a Segmentation Violation (signal 11) and
> looks much like the first.

Thanks for helping to solve this problem and thanks for the dumps. I'll have a
look at them.


> I try to debug the Voter problem discussed on the list, and my suspicion is
> that it is a simple race condition resulting from the use of asynchronous
> timers in code with no protection of shared variables.
>
> However, I cannot believe that is really the case, as the software appears
> to be written by knowledgeable people and is in wide use, and issues like
> this should have been found long ago or avoided altogether.
>
> So my basic question is: what is the general mechanism that protects the
> code against interruption by timer signals at places where this causes
> unwanted change of variables?  Is there some protection offered by C++ or
> by constructs in the program that I have not yet found?>
> For example, we see the code SEGV at line 361 in Macho.cpp, this code
fragment:

>                  if (myPendingEvent) {
>                  
>                          _IEventBase * event = myPendingEvent;
>                          myPendingEvent = 0;
>                          event->dispatch(*myCurrentState); <--- line 361
>                          delete event;
>                  
>                  }
>
> I think it means that "event" or "myCurrentState" is a NULL pointer.
> However, both of those have been checked for NULL shortly before.
> So I suspect that between the check and the use, a timer signal has been
> handled that sets them.
>
> Is that possible?  Or am I completely on the wrong track here...

SvxLink does not use threads or UNIX signals so there really is only one
program flow. Well, that's almost true. There are some small parts that use
threads/signals but they should be isolated from the rest of the code using a
safe interface. Timers in SvxLink are implemented using the "pselect" system
call. Timer events are generated from AsyncCppApplication.cpp as are all other
events. There is no way for a timer to interrupt the code above.

73's de SM0SVX / Tobias


>
> Rob PE1CHL


------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Error in voter

Rob Janssen
SM0SVX wrote:
> On Sunday 13 April 2014 18:13:23 Rob Janssen wrote:
>> Here are a couple more crashdumps from the same repeater.
>> The first 3 are apparently a different situation that ends in an Abort
>> (signal 6), the last one is again a Segmentation Violation (signal 11) and
>> looks much like the first.
> Thanks for helping to solve this problem and thanks for the dumps. I'll have a
> look at them.
>

I am again trying to debug it and I noticed that the "assertion failed" messages never appear
anywhere.   I found it is caused by the re-routing of stderr to a pipe during startup when
--logfile is present.
Normally this is nice because it will cause stderr messages to be time-stamped in the logfile,
but when those assert errors occur the C library will print the message to stderr and then
close everything and raise a signal 6, which means the main loop that gets the message
from the pipe and writes it to the log is not executed anymore.

I put a "if (daemonize)" around the redirection of stderr so I can have the assert errors while
debugging (and running the program on the console under a program that re-starts it when
it exits with signal 6 or 11, so the users of the repeater do not suffer).
However, it appears that a lot of output is in fact written to stderr.

I think it needs a decision, whether to send error output to stdout, or to open the logfile on
stderr and not use the redirect pipe trick on stderr.   Of course that means that stderr output
will not be timestamped in the log.
Maybe it could also be fixed by catching the SIGABRT signal and flushing the error pipe
before resetting the signal and raising it again?

I also noticed this fragment at the end of main (in svxlink.cpp):

   if (sigaction(SIGHUP, &sighup_oldact, NULL) == -1)
   {
     perror("sigaction");
   }

   if (sigaction(SIGHUP, &sigterm_oldact, NULL) == -1)
   {
     perror("sigaction");
   }

   if (sigaction(SIGHUP, &sigint_oldact, NULL) == -1)
   {
     perror("sigaction");
   }

I think the last to SIGHUP should be SIGTERM and SIGINT respectively.
Of course this fixes no problems, in fact this part could be removed completely without
any effect.

Rob

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Error in voter

Rob Janssen
In reply to this post by Tobias Blomberg
SM0SVX wrote:
> On Sunday 13 April 2014 18:13:23 Rob Janssen wrote:
>> Here are a couple more crashdumps from the same repeater.
>> The first 3 are apparently a different situation that ends in an Abort
>> (signal 6), the last one is again a Segmentation Violation (signal 11) and
>> looks much like the first.
> Thanks for helping to solve this problem and thanks for the dumps. I'll have a
> look at them.
>

I have been working on it and I noticed that several versions of svxlink had been installed
on the computer on top of eachother.  I decided to uninstall everything and start from scratch,
especially after I saw a backtrace in gdb where part of the function list had no matching symbols.

Unfortunately I made the mistake to uninstall in reverse order: first a "make uninstall" to
undo the "make install" I did last, and then a couple of "rpm -e" commands to remove the
early version that had been installed using rpm, then some more rm commands to remove
libraries still left in /usr/lib.

I found out the hard way that "make uninstall" simply removes the /etc/svxlink/svxlink.conf file,
not a file that it has installed but the carefully modified one :-(

I had expected (in fact I had not really thought about it) that it would leave config files, certainly
those that had been modified, or that it would rename them.   rpm -e does that, but as I ran the
"make uninstall" first, the svxlink.conf file already was lost.
The latest backup was two months old.   Of course I have arranged for a daily backup of those
directories now.

What I did not really expect did happen though: after the clean install, the crashes as I have
described have not yet occurred again.  So maybe there still was some installation conflict
that was resolve this way, and that can result when only "make install" is used?
To be really sure, we need to run it a few days more.  But usually it crashed 6 times a day or
more, and now it has not crashed for more than a day.

Is there a script available that removes all installed files from different svxlink versions?
(so one can make a clean start)
Of course I now know to save the modified config files first :-)

Rob

------------------------------------------------------------------------------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Error in voter

Tobias Blomberg
In reply to this post by Rob Janssen
On Sunday 20 April 2014 19:34:19 Rob Janssen wrote:

> SM0SVX wrote:
> > On Sunday 13 April 2014 18:13:23 Rob Janssen wrote:
> >> Here are a couple more crashdumps from the same repeater.
> >> The first 3 are apparently a different situation that ends in an Abort
> >> (signal 6), the last one is again a Segmentation Violation (signal 11)
> >> and
> >> looks much like the first.
> >
> > Thanks for helping to solve this problem and thanks for the dumps. I'll
> > have a look at them.
>
> I am again trying to debug it and I noticed that the "assertion failed"
> messages never appear anywhere.   I found it is caused by the re-routing of
> stderr to a pipe during startup when --logfile is present.
> Normally this is nice because it will cause stderr messages to be
> time-stamped in the logfile, but when those assert errors occur the C
> library will print the message to stderr and then close everything and
> raise a signal 6, which means the main loop that gets the message from the
> pipe and writes it to the log is not executed anymore.

Hmmm. Yes, the logging could be improved somewhat obviously.


> I put a "if (daemonize)" around the redirection of stderr so I can have the
> assert errors while debugging (and running the program on the console under
> a program that re-starts it when it exits with signal 6 or 11, so the users
> of the repeater do not suffer). However, it appears that a lot of output is
> in fact written to stderr.

Why not just temporarily run it in foreground? If you want timestamped rows,
just pipe the output to something that can add timestamps, like awk:

        svxlink | awk '{ print strftime("%c") ": " $0 }'

You'd have to add your restart loop as well of course.

If you do not want to be logged in to the system all the time, use a utility
like "tmux" (or "screen") to be able to detach and reattach to a terminal
session.


> I think it needs a decision, whether to send error output to stdout, or to
> open the logfile on stderr and not use the redirect pipe trick on stderr.  
> Of course that means that stderr output will not be timestamped in the log.
> Maybe it could also be fixed by catching the SIGABRT signal and flushing the
> error pipe before resetting the signal and raising it again?

I'll need to think about that one. If you don't want it to be forgotten, enter
a bug report at:

        http://sourceforge.net/p/svxlink/bugs/


> I also noticed this fragment at the end of main (in svxlink.cpp):
>
>    if (sigaction(SIGHUP, &sighup_oldact, NULL) == -1)
>    {
>      perror("sigaction");
>    }
>
>    if (sigaction(SIGHUP, &sigterm_oldact, NULL) == -1)
>    {
>      perror("sigaction");
>    }
>
>    if (sigaction(SIGHUP, &sigint_oldact, NULL) == -1)
>    {
>      perror("sigaction");
>    }
>
> I think the last to SIGHUP should be SIGTERM and SIGINT respectively.
> Of course this fixes no problems, in fact this part could be removed
> completely without any effect.

Yes, that's wrong. Thanks for pointing that out. I have fixed it in the 13.12
branch. But as you say, they have no real effect. They are only there for
completeness.

73's de SM0SVX / Tobias


>
> Rob


------------------------------------------------------------------------------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Error in voter

Tobias Blomberg
In reply to this post by Rob Janssen
On Tuesday 22 April 2014 23:17:05 Rob Janssen wrote:

> SM0SVX wrote:
> > On Sunday 13 April 2014 18:13:23 Rob Janssen wrote:
> >> Here are a couple more crashdumps from the same repeater.
> >> The first 3 are apparently a different situation that ends in an Abort
> >> (signal 6), the last one is again a Segmentation Violation (signal 11)
> >> and
> >> looks much like the first.
> >
> > Thanks for helping to solve this problem and thanks for the dumps. I'll
> > have a look at them.
>
> I have been working on it and I noticed that several versions of svxlink had
> been installed on the computer on top of eachother.  I decided to uninstall
> everything and start from scratch, especially after I saw a backtrace in
> gdb where part of the function list had no matching symbols.

Ah, that typically sounds like different libraries were used when linking and
when running.


> Unfortunately I made the mistake to uninstall in reverse order: first a
> "make uninstall" to undo the "make install" I did last, and then a couple
> of "rpm -e" commands to remove the early version that had been installed
> using rpm, then some more rm commands to remove libraries still left in
> /usr/lib.
>
> I found out the hard way that "make uninstall" simply removes the
> /etc/svxlink/svxlink.conf file, not a file that it has installed but the
> carefully modified one :-(
>
> I had expected (in fact I had not really thought about it) that it would
> leave config files, certainly those that had been modified, or that it
> would rename them.   rpm -e does that, but as I ran the "make uninstall"
> first, the svxlink.conf file already was lost.
> The latest backup was two months old.   Of course I have arranged for a
> daily backup of those directories now.

I'm sorry you got your configuration deleted. At least you (re-)discovered that
backups are good :-)

I guess the "make uninstall" could be improved but the plan is to switch to
cmake so I will not put in any time to fix the old makefiles. The reason I have
not switched to cmake yet is that I have an old SvxLink system running that
does not support cmake. It should be upgraded but that have not happened so
far. Maybe soon...


> What I did not really expect did happen though: after the clean install, the
> crashes as I have described have not yet occurred again.  So maybe there
> still was some installation conflict that was resolve this way, and that
> can result when only "make install" is used? To be really sure, we need to
> run it a few days more.  But usually it crashed 6 times a day or more, and
> now it has not crashed for more than a day.

That's great! I hope it will continue to run. I thought it was kind of strange
that you had so many crashes since I have systems that have been running
without problems for a very long time.

Using "make install" should work but I rarely use it myself since I mostly run
SvxLink directly from the source tree. That is more convenient for
development.


> Is there a script available that removes all installed files from different
> svxlink versions? (so one can make a clean start)
> Of course I now know to save the modified config files first :-)

There is nothing other than "make uninstall" that I know of. If you want to
see exactly which files are installed you could temporarily install svxlink
into its own directory.

        make install DESTDIR=/tmp/svxlink NO_CHOWN=1 NO_CHGRP=1

Now you can have a look in /tmp/svxlink to find out what has been installed.
The "tree" utility give a nice overview:

        tree /tmp/svxlink

73's de SM0SVX / Tobias


>
> Rob


------------------------------------------------------------------------------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

example sysconfig files

Rob Janssen
I noticed that the default /etc/sysconfig/svxlink and /etc/sysconfig/remotetrx files have the
configuration path set as /etc/svxlink.conf and /etc/remotetrx.conf, while those config files
are actually placed in /etc/svxlink/svxlink.conf and /etc/svxlink/remotetrx.conf.

Probably a good idea to change the paths in the default files. After my inadvertent uninstall
earlier this week this file suddenly had the wrong content program would not start as a service.

73,
Rob

------------------------------------------------------------------------------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: example sysconfig files

Tobias Blomberg
On Saturday 26 April 2014 11:00:00 Rob Janssen wrote:
> I noticed that the default /etc/sysconfig/svxlink and
> /etc/sysconfig/remotetrx files have the configuration path set as
> /etc/svxlink.conf and /etc/remotetrx.conf, while those config files are
> actually placed in /etc/svxlink/svxlink.conf and
> /etc/svxlink/remotetrx.conf.
>
> Probably a good idea to change the paths in the default files. After my
> inadvertent uninstall earlier this week this file suddenly had the wrong
> content program would not start as a service.

Thanks! Fixed in the 13.12 release branch.

73's de SM0SVX / Tobias

>
> 73,
> Rob


------------------------------------------------------------------------------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Error in voter

Rob Janssen
In reply to this post by Tobias Blomberg
SM0SVX wrote:

>
>> What I did not really expect did happen though: after the clean install, the
>> crashes as I have described have not yet occurred again.  So maybe there
>> still was some installation conflict that was resolve this way, and that
>> can result when only "make install" is used? To be really sure, we need to
>> run it a few days more.  But usually it crashed 6 times a day or more, and
>> now it has not crashed for more than a day.
> That's great! I hope it will continue to run. I thought it was kind of strange
> that you had so many crashes since I have systems that have been running
> without problems for a very long time.

It turns out that the improved stability has nothing to do with the uninstall/reinstall,
but instead it probably was caused by the revert to the older svxlink.conf
In the backup we had a voter config with these parameters:

VOTING_DELAY=100
BUFFER_LENGTH=0
REVOTE_INTERVAL=1000
HYSTERESIS=50
RX_SWITCH_DELAY=500
SQL_CLOSE_REVOTE_DELAY=500

It has been running stable for several days with these params.
Now, BUFFER_LENGTH has been changed to 100 and the crashes are back, same stackdumps
as I have presented before.   That parameter was also present in the config I accidentally
deleted.  Maybe you can look again for the cause of this issue?
(from the backtrace I suspect that something happens during the playout of that buffer,
and the program then crashes)

Anyway, here is what I made for uninstall.  Probably not relevant anymore, but maybe
others can use it (hopefully there are no unintended linewraps):

#!/bin/bash
# uninstall all svxlink software to get a clean slate before installing
# a new version - Rob PE1CHL

echo -n "Uninstall svxlink - are you sure? (y/n): "
read answer
if [ "$answer" != "y" ]
then
         exit 1
fi

now=`date +%Y%m%d%H%M%S`
backup="/tmp/backup-$now.tar.gz"
echo
echo "Making config backup to $backup..."
tar czf $backup /etc/svxlink /usr/share/svxlink/*.* /etc/init.d/svxlink /etc/init.d/remotetrx /etc/logrotate.d/svxlink /etc/logrotate.d/remotetrx /etc/sysconfig/svxlink /etc/sysconfig/remotetrx

/etc/init.d/svxlink stop
/etc/init.d/remotetrx stop

if [ -x /bin/rpm ]
then
         if rpm -qa | grep -q svxlink
         then
                 echo "Removing rpm-installed version"
                 rpm -e echolib-devel libasync-devel
                 rpm -e svxlink-server qtel echolib libasync
         fi
fi

rm -fv /etc/security/console.perms.d/90-svxlink.perms
rm -fv /etc/udev/rules.d/10-svxlink.rules
rm -fv /usr/bin/qtel /usr/bin/remotetrx /usr/bin/siglevdetcal /usr/bin/svxlink
rm -fvr /usr/include/svxlink
rm -fv /usr/lib/libasyncaudio* /usr/lib/libasynccore* /usr/lib/libasynccpp* /usr/lib/libasyncqt*
rm -fv /usr/lib/libecholib* /usr/lib/liblocationinfo.a /usr/lib/libtrx.a
rm -fvr /usr/lib/svxlink
rm -fv /usr/share/applications/qtel.desktop /usr/share/icons/link.xpm
rm -fv /usr/share/man/man1/qtel.1.gz /usr/share/man/man1/remotetrx.1.gz
rm -fv /usr/share/man/man1/siglevdetcal.1.gz /usr/share/man/man1/svxlink.1.gz
rm -fv /usr/share/man/man5/ModuleDtmfRepeater.conf.5.gz
rm -fv /usr/share/man/man5/ModuleEchoLink.conf.5.gz
rm -fv /usr/share/man/man5/ModuleHelp.conf.5.gz
rm -fv /usr/share/man/man5/ModuleParrot.conf.5.gz
rm -fv /usr/share/man/man5/ModulePropagationMonitor.conf.5.gz
rm -fv /usr/share/man/man5/ModuleSelCallEnc.conf.5.gz
rm -fv /usr/share/man/man5/ModuleTclVoiceMail.conf.5.gz
rm -fv /usr/share/man/man5/remotetrx.conf.5.gz
rm -fv /usr/share/man/man5/svxlink.conf.5.gz
rm -fvr /usr/share/qtel
rm -fv /usr/share/svxlink/events.d/*.tcl* /usr/share/svxlink/modules.d/*.tcl*
rmdir -v /usr/share/svxlink/* /usr/share/svxlink
rmdir -v /var/spool/svxlink/* /var/spool/svxlink

echo
echo -n "Remove configuration files and other customization? (y/n): "
read answer
if [ "$answer" != "y" ]
then
         exit 0
fi

rm -fv /etc/init.d/svxlink /etc/init.d/remotetrx
rm -fv /etc/logrotate.d/svxlink /etc/logrotate.d/remotetrx
rm -fv /etc/sysconfig/svxlink /etc/sysconfig/remotetrx
rm -fvr /etc/svxlink /usr/share/svxlink/*.*

echo
echo -n "Remove stored data (qso recorder, voice mail etc)? (y/n): "
read answer
if [ "$answer" != "y" ]
then
         exit 0
fi

rm -fvr /usr/share/svxlink
rm -fvr /var/spool/svxlink
exit 0


------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.  Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Error in voter

Tobias Blomberg
On Monday 28 April 2014 20:07:57 Rob Janssen wrote:

> SM0SVX wrote:
> >> What I did not really expect did happen though: after the clean install,
> >> the crashes as I have described have not yet occurred again.  So maybe
> >> there still was some installation conflict that was resolve this way,
> >> and that can result when only "make install" is used? To be really sure,
> >> we need to run it a few days more.  But usually it crashed 6 times a day
> >> or more, and now it has not crashed for more than a day.
> >
> > That's great! I hope it will continue to run. I thought it was kind of
> > strange that you had so many crashes since I have systems that have been
> > running without problems for a very long time.
>
> It turns out that the improved stability has nothing to do with the
> uninstall/reinstall, but instead it probably was caused by the revert to
> the older svxlink.conf In the backup we had a voter config with these
> parameters:
>
> VOTING_DELAY=100
> BUFFER_LENGTH=0
> REVOTE_INTERVAL=1000
> HYSTERESIS=50
> RX_SWITCH_DELAY=500
> SQL_CLOSE_REVOTE_DELAY=500
>
> It has been running stable for several days with these params.
> Now, BUFFER_LENGTH has been changed to 100 and the crashes are back, same
> stackdumps as I have presented before.   That parameter was also present in
> the config I accidentally deleted.  Maybe you can look again for the cause
> of this issue?
> (from the backtrace I suspect that something happens during the playout of
> that buffer, and the program then crashes)

Very interesting! That could explain why I have not seen the crashes on any of
my systems since I have been using zero buffer length. I'll have a look at it
later this week.

73's de SM0SVX / Tobias


>
> Anyway, here is what I made for uninstall.  Probably not relevant anymore,
> but maybe others can use it (hopefully there are no unintended linewraps):
>
> #!/bin/bash
> # uninstall all svxlink software to get a clean slate before installing
> # a new version - Rob PE1CHL
>
> echo -n "Uninstall svxlink - are you sure? (y/n): "
> read answer
> if [ "$answer" != "y" ]
> then
>          exit 1
> fi
>
> now=`date +%Y%m%d%H%M%S`
> backup="/tmp/backup-$now.tar.gz"
> echo
> echo "Making config backup to $backup..."
> tar czf $backup /etc/svxlink /usr/share/svxlink/*.* /etc/init.d/svxlink
> /etc/init.d/remotetrx /etc/logrotate.d/svxlink /etc/logrotate.d/remotetrx
> /etc/sysconfig/svxlink /etc/sysconfig/remotetrx
>
> /etc/init.d/svxlink stop
> /etc/init.d/remotetrx stop
>
> if [ -x /bin/rpm ]
> then
>          if rpm -qa | grep -q svxlink
>          then
>                  echo "Removing rpm-installed version"
>                  rpm -e echolib-devel libasync-devel
>                  rpm -e svxlink-server qtel echolib libasync
>          fi
> fi
>
> rm -fv /etc/security/console.perms.d/90-svxlink.perms
> rm -fv /etc/udev/rules.d/10-svxlink.rules
> rm -fv /usr/bin/qtel /usr/bin/remotetrx /usr/bin/siglevdetcal
> /usr/bin/svxlink rm -fvr /usr/include/svxlink
> rm -fv /usr/lib/libasyncaudio* /usr/lib/libasynccore* /usr/lib/libasynccpp*
> /usr/lib/libasyncqt* rm -fv /usr/lib/libecholib* /usr/lib/liblocationinfo.a
> /usr/lib/libtrx.a rm -fvr /usr/lib/svxlink
> rm -fv /usr/share/applications/qtel.desktop /usr/share/icons/link.xpm
> rm -fv /usr/share/man/man1/qtel.1.gz /usr/share/man/man1/remotetrx.1.gz
> rm -fv /usr/share/man/man1/siglevdetcal.1.gz
> /usr/share/man/man1/svxlink.1.gz rm -fv
> /usr/share/man/man5/ModuleDtmfRepeater.conf.5.gz
> rm -fv /usr/share/man/man5/ModuleEchoLink.conf.5.gz
> rm -fv /usr/share/man/man5/ModuleHelp.conf.5.gz
> rm -fv /usr/share/man/man5/ModuleParrot.conf.5.gz
> rm -fv /usr/share/man/man5/ModulePropagationMonitor.conf.5.gz
> rm -fv /usr/share/man/man5/ModuleSelCallEnc.conf.5.gz
> rm -fv /usr/share/man/man5/ModuleTclVoiceMail.conf.5.gz
> rm -fv /usr/share/man/man5/remotetrx.conf.5.gz
> rm -fv /usr/share/man/man5/svxlink.conf.5.gz
> rm -fvr /usr/share/qtel
> rm -fv /usr/share/svxlink/events.d/*.tcl*
> /usr/share/svxlink/modules.d/*.tcl* rmdir -v /usr/share/svxlink/*
> /usr/share/svxlink
> rmdir -v /var/spool/svxlink/* /var/spool/svxlink
>
> echo
> echo -n "Remove configuration files and other customization? (y/n): "
> read answer
> if [ "$answer" != "y" ]
> then
>          exit 0
> fi
>
> rm -fv /etc/init.d/svxlink /etc/init.d/remotetrx
> rm -fv /etc/logrotate.d/svxlink /etc/logrotate.d/remotetrx
> rm -fv /etc/sysconfig/svxlink /etc/sysconfig/remotetrx
> rm -fvr /etc/svxlink /usr/share/svxlink/*.*
>
> echo
> echo -n "Remove stored data (qso recorder, voice mail etc)? (y/n): "
> read answer
> if [ "$answer" != "y" ]
> then
>          exit 0
> fi
>
> rm -fvr /usr/share/svxlink
> rm -fvr /var/spool/svxlink
> exit 0
>
>
> ----------------------------------------------------------------------------
> -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.  Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Svxlink-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/svxlink-devel


------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.  Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Error in voter

Tobias Blomberg
On Monday 28 April 2014 22:51:34 SM0SVX wrote:

> On Monday 28 April 2014 20:07:57 Rob Janssen wrote:
> > SM0SVX wrote:
> > >> What I did not really expect did happen though: after the clean
> > >> install,
> > >> the crashes as I have described have not yet occurred again.  So maybe
> > >> there still was some installation conflict that was resolve this way,
> > >> and that can result when only "make install" is used? To be really
> > >> sure,
> > >> we need to run it a few days more.  But usually it crashed 6 times a
> > >> day
> > >> or more, and now it has not crashed for more than a day.
> > >
> > > That's great! I hope it will continue to run. I thought it was kind of
> > > strange that you had so many crashes since I have systems that have been
> > > running without problems for a very long time.
> >
> > It turns out that the improved stability has nothing to do with the
> > uninstall/reinstall, but instead it probably was caused by the revert to
> > the older svxlink.conf In the backup we had a voter config with these
> > parameters:
> >
> > VOTING_DELAY=100
> > BUFFER_LENGTH=0
> > REVOTE_INTERVAL=1000
> > HYSTERESIS=50
> > RX_SWITCH_DELAY=500
> > SQL_CLOSE_REVOTE_DELAY=500
> >
> > It has been running stable for several days with these params.
> > Now, BUFFER_LENGTH has been changed to 100 and the crashes are back, same
> > stackdumps as I have presented before.   That parameter was also present
> > in
> > the config I accidentally deleted.  Maybe you can look again for the cause
> > of this issue?
> > (from the backtrace I suspect that something happens during the playout of
> > that buffer, and the program then crashes)
>
> Very interesting! That could explain why I have not seen the crashes on any
> of my systems since I have been using zero buffer length. I'll have a look
> at it later this week.

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.

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.

73's de SM0SVX / Tobias


------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.  Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
123