dl5di / OpenDV

Open Digital Voice software for Amateur Radio based on Jonathan Naylor's (G4KLX) "ircDDBGateway" and "PCRepeaterController" for D-Star
GNU General Public License v2.0
107 stars 63 forks source link

DStarRepeater Remote Command's Crash Application #97

Open viper14306 opened 8 years ago

viper14306 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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/dstarrepeaterconf/.hlp %{buildroot}/usr/share/dstarrepeater_conf cp -bu /srv/opendv/usr/share/dstarrepeaterconf/.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/dstarrepeaterconf/.hlp %attr(644,root,root) /usr/share/dstarrepeaterconf/.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

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 https://github.com/dl5di/OpenDV/issues/97#issuecomment-214493253

mcdermj commented 8 years ago

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.