Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DStarRepeater Remote Command's Crash Application #97

Open
viper14306 opened this issue Apr 24, 2016 · 3 comments
Open

DStarRepeater Remote Command's Crash Application #97

viper14306 opened this issue Apr 24, 2016 · 3 comments

Comments

@viper14306
Copy link

I have setup a Raspberry Pi B+ with the DVMEGA GPIO board on it. I installed Raspbian Jessie on the Pi and compiled the repeater software from here and tried the one from Yahoo Group. All of them appear to have this issue (except the one from the Western D-Star Group, which doesn't indicate it is in DEBUG). When I have remote commands setup to do things like Shutdown or Restart, when I make a call to the command, it crashes the Repeater with the following error in the console that the repeater was ran from:

Fatel Error: Assertion failed on line 587 in file ../src/unix/utilsunx.cpp and function wxExecute: wxThread::IsMain() wxExecute() can be called only from the main thread.

I posted this in the Yahoo Group and someone said their build works fine. The Yahoo Group code says it is the same version as the Western D-Star Group's version (again, mine saying DEBUG and theirs does not). Anyone else have this issue or have any thoughts?

@mcdermj
Copy link
Contributor

mcdermj commented Apr 25, 2016

The assertion is only enabled when wxWidgets is compiled with DEBUG enabled. It doesn't mean that the error isn't happening, it just means that the assertion isn't firing.

This is a programming error as the code doesn't check to see if it's running on the main thread or not. wxShell/wxExecute can only be run from the main thread, so we'll have to run down how to use wxQueueEvent to trigger the main thread to do the processing.

@vk4tux
Copy link
Contributor

vk4tux commented Apr 25, 2016

I did a standard compile in my latest Odroid C2 image. no flag added for
debug, but debug through the the GUI title bar later? Which I thought
'weird', and GUI remotecontrol choking on the complete host files from
my server,.. why are the gateways included ? Instead of messing around
with opendv, the install script could detect the existing system user,
and setup paths under same with correct permissions.

In debian/ubuntu setting the existing user in settings.mk worked very
well, especially as the program was also used underneath that user.

I was doing systemd rpm packaging for 2.8 wx base since 4 years ago ;

%define debug_packages %{nil}
%define debug_package %{nil}

Name: dstarrepeater
Version: 20151012
Release: 1
License: GPLv2
Group: Networking/Daemons
Summary: G4KLX DStarRepeater
URL: vk4tux.no-ip.org
Packager: vk4tux
Requires: wxGTK, libusbx, alsa-lib
Obsoletes: repeater
Source0: DStarRepeater-20151012.tgz
BuildRoot: %{_tmppath}/%{name}-root
BuildRequires: wxGTK-devel, libusbx-devel

%description
Dstar-Repeater

%prep
%setup -n DStarRepeater
cp -pf settings_default.mk settings.mk

%build
make DStarRepeater/dstarrepeater DStarRepeaterConfig/dstarrepeaterconfig

%install
rm -rf %{buildroot}
mkdir -p %{buildroot}/var/run/%{name}
mkdir -p %{buildroot}/etc/default
mkdir -p %{buildroot}/etc/sysconfig
mkdir -p %{buildroot}/lib/systemd/system
mkdir -p %{buildroot}/usr/local/bin
mkdir -p %{buildroot}/usr/share/dstarrepeater_conf
mkdir -p %{buildroot}/var/log/dstar

cp DStarRepeater/dstarrepeater %{buildroot}/usr/local/bin
cp DStarRepeater/dstarrepeaterd %{buildroot}/usr/local/bin
cp DStarRepeaterConfig/dstarrepeaterconfig %{buildroot}/usr/local/bin
cp /srv/opendv/usr/local/bin/dstarrepeaterconfig.sh
%{buildroot}/usr/local/bin
cp /srv/opendv/usr/local/bin/dstarrepeater_conf %{buildroot}/usr/local/bin

cp /srv/opendv/etc/sysconfig/dstarrepeater_conf %{buildroot}/etc/sysconfig
cp /srv/opendv/etc/dstarrepeater.version %{buildroot}/etc
cp -bu /srv/opendv/etc/default/dstarrepeater.default
%{buildroot}/etc/default

cp -bu /srv/opendv/usr/share/dstarrepeater_conf/.hlp
%{buildroot}/usr/share/dstarrepeater_conf
cp -bu /srv/opendv/usr/share/dstarrepeater_conf/
.menu
%{buildroot}/usr/share/dstarrepeater_conf
cp -bu /srv/opendv/lib/systemd/system/dstarrepeater_1.service
%{buildroot}/lib/systemd/system
cp -bu /srv/opendv/lib/systemd/system/dstarrepeater_2.service
%{buildroot}/lib/systemd/system
cp -bu /srv/opendv/lib/systemd/system/dstarrepeater_3.service
%{buildroot}/lib/systemd/system
cp -bu /srv/opendv/lib/systemd/system/dstarrepeater_4.service
%{buildroot}/lib/systemd/system

%clean
rm -rf %{buildroot}

%files
%defattr(-,root,root)
%attr(755,root,root) /usr/local/bin/dstarrepeater_conf
%attr(755,root,root) /usr/local/bin/dstarrepeaterconfig.sh
%attr(755,root,root) /usr/local/bin/dstarrepeater
%attr(755,root,root) /usr/local/bin/dstarrepeaterd
%attr(755,root,root) /usr/local/bin/dstarrepeaterconfig

%attr(644,root,root) /etc/dstarrepeater.version

%attr(644,root,root) /etc/default/dstarrepeater.default

%attr(644,root,root) /usr/share/dstarrepeater_conf/.hlp
%attr(644,root,root) /usr/share/dstarrepeater_conf/
.menu
%config(noreplace) /lib/systemd/system/dstarrepeater*
%config(noreplace) /etc/sysconfig/dstarrepeater_conf

%dir /var/run/%{name}

%post

/usr/bin/echo "run dstarrepeater_conf 1 to setup. Remove dstar
service files if any from /etc/init.d/*" || :

%changelog

  • Mon Oct 12 2015 vk4tux
  • pidora|fedora release 20151012 Systemd Service

Let me know the included systemd components in latest code please, and
what replaced remotecontrold ?

On 26/04/16 05:33, Jeremy McDermond wrote:

The assertion is only enabled when wxWidgets is compiled with DEBUG
enabled. It doesn't mean that the error isn't happening, it just means
that the assertion isn't firing.

This is a programming error as the code doesn't check to see if it's
running on the main thread or not. wxShell/wxExecute can only be run
from the main thread, so we'll have to run down how to use
wxQueueEvent to trigger the main thread to do the processing.


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#97 (comment)

@mcdermj
Copy link
Contributor

mcdermj commented May 3, 2016

I see where the issue is here and have a path forward to fix it. I'll see if I can commit some code within the next couple of days to move forward on it. It's going to have a few other rearchitecting things that it'll be dependent on, so I'll have to complete those first. Stay tuned @viper14306.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants