Assertion in AsyncTimer class

[dl1hrc]

SvxLink v1.5.99.3

svxlink: /root/svxlink/src/async/core/AsyncTimer.cpp:150: void Async::Timer::setEnable(bool): Assertion `(m_timeout_ms >= 0) || !do_enable' failed.

Will start it with gdb to find out more.

[sm0svx]

Yes. The problem is not in the timer class but in how the timer is used. To have any clue where to look we need more context so if you can get a backtrace from the debugger, that would help a lot.

[dl1hrc]

Unfortunately that rarely happens. I have the impression to occurs if I have four or more logics in use connected by LogicLinking and relatively "complicated" configurations. Will see what I can do here.

[sm0svx]

Can you turn core dumps on? Or maybe it's on already so that you have a core dump on your filesystem?

[dl1hrc]

is turned on now, waiting for exception...

[dl1hrc]

svxlink: /root/svxlink/src/async/core/AsyncTimer.cpp:150: void Async::Timer::setEnable(bool): Assertion `(m_timeout_ms >= 0) || !do_enable' failed.

Program received signal SIGABRT, Aborted.
0x00007ffff51910a7 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: zypper install alsa-plugins-debuginfo-1.0.28-3.1.3.x86_64 libasound2-debuginfo-1.0.28-6.1.4.x86_64 libgcc_s1-debuginfo-4.8.3+r212056-2.4.4.x86_64 libgcrypt20-debuginfo-1.6.1-8.19.1.x86_64 libgpg-error0-debuginfo-1.15-1.2.x86_64 libgsm1-debuginfo-1.0.13-25.1.2.x86_64 libopus0-debuginfo-1.1-2.1.2.x86_64 libpopt0-debuginfo-1.16-27.1.2.x86_64 libsigc-2_0-0-debuginfo-2.4.1-4.1.x86_64 libspeex1-debuginfo-1.1.999_1.2rc1-23.1.2.x86_64 libstdc++6-debuginfo-4.8.3+r212056-2.4.4.x86_64 tcl-debuginfo-8.6.3-6.1.x86_64
(gdb) Write failed: Broken pipe

grrr

[sm0svx]

What happened? Why the "broken pipe"?

[dl1hrc]

I was connected with ssh, gdb was running in console. I guess the broken pipe was the ssh timeout after exception. The output is not meaningful enough, will see what I can do... Am 28.02.2017 um 21:32 schrieb Tobias Blomberg:

…

What happened? Why the "broken pipe"? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#251 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH2kwSeUrGnXmNGRCyS9l3tRs48_I5cyks5rhIRGgaJpZM4MMHGy>.

[sm0svx]

I use "tmux" a lot, especially for shaky remote connections. It enables you to disconnect from the terminal and come back later to reattach. It's the same concept as "screen" but much improved.

Quickstart:

• Start a new tmux session using command "tmux"
• Run your command(s)
• Detach from the session using Ctrl-B D
• Now you can log out or if you got disconnected it doesn't matter
• Log in again and run "tmux a" to reattach

There are a lot more features in tmux but the simple knowledge above may help very much in many situations.

[lechner]

You can also try byobu. F12 followed by 'c' to create a session. F12 and 'd' to disconnect but keep it alive.

[dl1hrc]

I can reproduce this error when an EchoLink connection is created, whenever the remote station starts it's transmission SvxLink crashed with this error message. No further information available so far :(

[sm0svx]

That's a step forward at least if you can reproduce the problem. Try to strip down your configuration to a minimal where the problem still occurs. Also try to remove any local modifications to source code or TCL-scripts to see if that is the reason for the crash.

[dl1hrc]

Unfortunately the problem is pending. I tested together with Frank/DL3DCW, he is running some systems based on bananpi (hamserver pi). He reported that the problem doesn't occur before version 1.5. I took a look into AsyncTimer class line 150:
void Timer::setEnable(bool do_enable)
{
assert((m_timeout_ms >= 0) || !do_enable); <- that is the assert.
...
I guess that under some "special" circumstances the timer is running below 0 an will be (re-)enabled before the new value has been assigned. Unfortunately it doesn't happen everywhere, I have running about ten systems without this error, on ten other systems the exception can be reproduced by a simple EchoLink connection.
I know, that the assert isn't the reason. What can we do here? Why can a timer has values below 0? Could this case just be ignored and set to 0?
The exception, of course, doesn't occur if the assert is removed from code but it would be a bad and lazy solution ;)
73s de Adi / DL1HRC

[sm0svx]

It would help a lot if you could get a stack trace when it happens, either by running SvxLink directly under gdb or by enabling core dumps and extracting the stack trace from that.

[dl1hrc]

hope that helps: https://svxlink.de/download/core.12941.gz
bt below, can send bt full when requested

(gdb) bt
#0 0x00007f1f134a50a7 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007f1f134a6458 in __GI_abort () at abort.c:78
#2 0x00007f1f1349e126 in __assert_fail_base (fmt=0x7f1f135d5eb8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
assertion=assertion@entry=0x7f1f14bc5788 "(m_timeout_ms >= 0) || !do_enable", file=file@entry=0x7f1f14bc5748 "/root/svxreflector/svxlink/src/async/core/AsyncTimer.cpp",
line=line@entry=151, function=function@entry=0x7f1f14bc57e0 Async::Timer::setEnable(bool)::__PRETTY_FUNCTION__ "void Async::Timer::setEnable(bool)") at assert.c:92
#3 0x00007f1f1349e1d2 in __GI___assert_fail (assertion=0x7f1f14bc5788 "(m_timeout_ms >= 0) || !do_enable",
file=0x7f1f14bc5748 "/root/svxreflector/svxlink/src/async/core/AsyncTimer.cpp", line=151,
function=0x7f1f14bc57e0 Async::Timer::setEnable(bool)::__PRETTY_FUNCTION__ "void Async::Timer::setEnable(bool)") at assert.c:101
#4 0x00007f1f14bb3d1e in Async::Timer::setEnable(bool) () from /usr/lib/libasynccore.so.1.4
#5 0x00007f1f14dfca69 in Async::AudioReader::readSamples(float*, int) () from /usr/lib/libasyncaudio.so.1.4
#6 0x00007f1f14df7e85 in Async::AudioIO::readSamples(float*, int) () from /usr/lib/libasyncaudio.so.1.4
#7 0x00007f1f14df64f3 in Async::AudioDevice::getBlocks(short*, int) () from /usr/lib/libasyncaudio.so.1.4
#8 0x00007f1f14e07c71 in Async::AudioDeviceAlsa::writeSpaceAvailable(Async::FdWatch*, unsigned short) () from /usr/lib/libasyncaudio.so.1.4
#9 0x00007f1f14e09c28 in Async::AudioDeviceAlsa::AlsaWatch::writeEvent(Async::FdWatch*) () from /usr/lib/libasyncaudio.so.1.4
#10 0x00007f1f1502216d in Async::CppApplication::exec() () from /usr/lib/libasynccpp.so.1.4
#11 0x000000000059196e in main (argc=1, argv=0x7fff06755a78) at /root/svxreflector/svxlink/src/svxlink/svxlink/svxlink.cpp:526

[sm0svx]

Great! So, it seems to have something to do with the Alsa code. That narrows it down considerably!

[sm0svx]

Try latest master or svxreflector. Hopefully the problem should now be fixed.

[sm0svx]

Have you been able to try this or have the Async::AudioIO bug (now fixed) stopped you?

[sm0svx]

Resolved?

[dl1hrc]

seems to be resolved. Thank you very much!
73s Adi