I am currently using the BlueZ DBus API to scan for BLE devices but it stops responding completely after varying intervals. Sometimes it's minutes, other times it's one or two hours.
My assumption is that I am forgetting to do something. The strange thing is, that after I exit the application, tools like bluetoothctl and hciconfig also no longer respond. Sometimes a reboot is not enough to get it to work again and I need to power-cycle the machines. It happens on several different machines as well.
I am acquiring the bus using:
GError* error = nullptr;
mConnection = g_bus_get_sync(G_BUS_TYPE_SYSTEM, nullptr, &error);
Starting the loop:
mLoop = g_main_loop_new(nullptr, false);
g_main_loop_run(mLoop);
Then I power on the adapter by setting the Powered property to true and calling StartDiscovery. Devices are then reported through:
guint iface_add_sub = g_dbus_connection_signal_subscribe(mConnection, "org.bluez", "org.freedesktop.DBus.ObjectManager", "InterfacesAdded", nullptr, nullptr, G_DBUS_SIGNAL_FLAGS_NONE, device_appeared, this, nullptr);
guint iface_remove_sub
= g_dbus_connection_signal_subscribe(mConnection, "org.bluez", "org.freedesktop.DBus.ObjectManager", "InterfacesRemoved", nullptr, nullptr, G_DBUS_SIGNAL_FLAGS_NONE, device_disappeared, this, nullptr);
Is there anything I am missing to prevent BlueZ from stopping to respond?
bluetoothd -v = 5.53
ldd --version = GLIBC 2.31-0ubuntu9.2
Bluez cannot scan indefinitely because it will crash, as you are observing. In my opinion it is a bug…
What I do is to scan for 8 seconds and then stop the scan. Bluez will then clean up internal cache. After allowing 1 second for cleanup, I restart the scan.
This way it will hold up much longer. Nonetheless after a week or so it might still crash…
Related
I am trying to replicate a real time application on a windows computer to be able to debug and make changes easier, but I ran into issue with Delayed Ack. I have already disabled nagle and confirmed that it improve the speed a bit. When sending a lots of small packets, window doesn't ACK right away and delay it by 200 ms. Doing more research about it, I came across this. Problem with changing the registry value is that, it will affect the whole system rather than just the application that I am working with. Is there anyway to disable delayed ACK on window system like TCP_QUICKACK from linux using setsockopt? I tried hard coding 12, but got WSAEINVAL from WSAGetLastError.
I saw some dev on github that mentioned to use SIO_TCP_SET_ACK_FREQUENCY but I didn't see any example on how to actually use it.
So I tried doing below
#define SIO_TCP_SET_ACK_FREQUENCY _WSAIOW(IOC_VENDOR,23)
result = WSAIoctl(sock, SIO_TCP_SET_ACK_FREQUENCY, 0, 0, info, sizeof(info), &bytes, 0, 0);
and I got WSAEFAULT as an error code. Please help!
I've seen several references online that TCP_QUICKACK may actually be supported by Winsock via setsockopt() (opt 12), even though it is NOT documented, or officially confirmed anywhere.
But, regarding your actual question, your use of SIO_TCP_SET_ACK_FREQUENCY is failing because you are not providing any input buffer to WSAIoctl() to set the actual frequency value. Try something like this:
int freq = 1; // can be 1..255, default is 2
result = WSAIoctl(sock, SIO_TCP_SET_ACK_FREQUENCY, &freq, sizeof(freq), NULL, 0, &bytes, NULL, NULL);
Note that SIO_TCP_SET_ACK_FREQUENCY is available in Windows 7 / Server 2008 R2 and later.
i am developing a pretty complex software for the STM32F746NG. I am using a modded Discovery Board. ST-Link is removed and replaced by a Segger J-Link via JTAG. The Rocktech Display was replaced by a bigger one. And i am using gcc6.2
The system is running pretty well. Except there are some system freezes. It appears randomly while refreshing the Display.
If the freeze happens the debugger cant halt the cpu and connecting the debugger to the cpu is impossible. A LED triggered toggeling by hardware timer stops. And the sending of error messages via UART in the Fault Handler doesent happen. It seems like the CPU just stops and isnt doing anything anymore.
Has anyone an idea what could cause this?
I cannot give the whole code, maybe some snippets.
edit:
It seems like the hardware is alright. New Board with the same 800*480 Display but again with the crappy onboard ST-Link causes the issue again.
Some more information:
I am using FreeRTOS v9.0.0, there are about 16 tasks running.
The Tickrate is with 10 kHz relative high but reducing it to 1 kHz didnt resolve the issue.
The Framebuffer is in the external sdram from the discovery board 2 Framebuffers for Foreground and 1 Framebuffer for background
last 2 MB are used for heap.
caddr_t _sbrk(int incr)
{
extern char _end; /* Defined by the linker */
static char *heap_end=0;
char *prev_heap_end;
if (heap_end == 0)
{
heap_end = &_end;
}
prev_heap_end = heap_end;
if((uint32_t)heap_end <= _heap1_end)
{
if ((uint32_t)heap_end + incr > _heap1_end)
{
heap_end = &_endFrameBuffer;
#ifdef DEBUGMODE
sendErrToUart("Heap1 is Full: continue at");
char buff[12];
sprintf(buff,"%.8x",&_endFrameBuffer);
sendErrToUart(buff);
#endif
}
}
else
{
if ((uint32_t)heap_end + incr > _RAM2_end)
{
#ifdef DEBUGMODE
sendErrToUart("Heap is Full: exit");
#endif
abort ();
}
}
heap_end += incr;
return (caddr_t) prev_heap_end;
}
malloc is thread save via vTaskSuspendAll();
HardFault, NMI, BusFault, MemFault and UsageFault Handlers are implemented remove all code from them doesnt resolve the issue
The system freeze always happens while redrawing a Framebuffer (doesnt matter which one) via the function void refreshDisplay();
I observed three different behaviors for the likelihood of the issue.
If I call vTaskSuspendAll(); on entry of refreshDisplay and xTaskResumeAll(); on exit the issue is very unlikely. It doesnt happen for hours.
If I deactivate all non maskable interrupts i.e. all but reset and nmi ( but they should never be called). I couldn't ever observe the issue in this case.
If i deactivate all interrupts with configurable priority i.e. all but reset, nmi and HardFaultHandler. Then the issue is very likely. It happens after some Minutes.
All other configurations are behaving like the last case.
I've hit a bit of an issue and I'm not sure what to make of it.
I'm running Qt 4.8.6, Qt creator 3.3.2, environment in Ubuntu 12.04 cross compiling to a Beaglebone Black running Debian 7 kernel 3.8.13.
The issue that I'm seeing is that this code:
if (qApp->hasPendingEvents())
{
qDebug() << "pending events";
}
qApp->processEvents(QEventLoop::AllEvents, 10);
does not function as it should according to (at least my interpretation of) the Qt documentation. I would expect the process events loop to function for AT MOST the 10 milliseconds specified.
What happens is the qDebug statement is never printed. I would then expect that there are therefore no events to be processed, and the process events statement goes in and out very quickly. Most of the time this is the case.
What happens (not every time, but often enough) the qDebug statement is skipped, and the processEvents statement executes for somewhere between 1 and 2 seconds.
Is there some way that I can dig into what is happening in the process events and find out what is causing the delay?
Qt is processing events for longer than specified for QApplication::processEvents call on Linux
system. Is there some way that I can dig into what is happening in the
process events and find out what is causing the delay?
Yes, observing Qt source code may help. The source code is in /home/myname/software/Qt/5.5/Src/qtbase/src/corelib/kernel/qeventdispatcher_unix.cpp or maybe somewhere around that:
bool QEventDispatcherUNIX::processEvents(QEventLoop::ProcessEventsFlags flags)
{
Q_D(QEventDispatcherUNIX);
d->interrupt.store(0);
// we are awake, broadcast it
emit awake();
// This statement implies forcing events from system event queue
// to be processed now with doSelect below
QCoreApplicationPrivate::sendPostedEvents(0, 0, d->threadData);
int nevents = 0;
const bool canWait = (d->threadData->canWaitLocked()
&& !d->interrupt.load()
&& (flags & QEventLoop::WaitForMoreEvents));
if (canWait)
emit aboutToBlock();
if (!d->interrupt.load()) {
// return the maximum time we can wait for an event.
timespec *tm = 0;
timespec wait_tm = { 0l, 0l };
if (!(flags & QEventLoop::X11ExcludeTimers)) {
if (d->timerList.timerWait(wait_tm))
tm = &wait_tm;
}
if (!canWait) {
if (!tm)
tm = &wait_tm;
// no time to wait
tm->tv_sec = 0l;
tm->tv_nsec = 0l;
}
// runs actual event loop with POSIX select
nevents = d->doSelect(flags, tm);
It seems there system posted events that are not accounted for qApp->hasPendingEvents(). And then QCoreApplicationPrivate::sendPostedEvents(0, 0, d->threadData); flushes those events to be processed by d->doSelect. If I was solving this task I would try to either flush those posted events out or maybe realize if and why flags parameter has QEventLoop::WaitForMoreEvents bit set. I usually either build Qt from source code or provide debugger with the path to its symbols/source so it is possible to dig in there.
P.S. I glanced at Qt 5.5.1 source event processing code but that should be very similar to what you deal with. Or could that implementation actually be bool QEventDispatcherGlib::processEvents(QEventLoop::ProcessEventsFlags flags)? It is easy to find on an actual system.
I am trying to initialise a sound port from pjsip and pjsua with the standart pjmedia_snd_port_create but the result is always not successful.
pj_caching_pool_init(&cp, &pj_pool_factory_default_policy, 0);
pool = pj_pool_create(&cp.factory,
"pool1",
4000,
4000,
NULL);
pjmedia_snd_port *snd_port1 = NULL;
status = pjmedia_snd_port_create(pool, id1, id1, clock_rate,
channel_count, samples_per_frame,
bits_per_sample,
0, &snd_port1);
My device id1 is 0, as i got it from the audio device manager. I`ve tried with the -1 for defaults but always fails me. I have endpoint created with the pjsua2 api from a C++ class, the lib is OK and running, I can create conference bridges also but the sound port fails me. A bit of a hint will be great.
I`ve fixed it with initialising loop, I guess it has nothing to do with the setup, what I need is actually to register all of my playback and rec devices from my hardware.
I have been looking at using IcmpSendEcho, and found that it will fail to ping certain devices (e.g. my BT Home Hub 4) with GetLastError reporting 11010. While for other devices it works fine (when executing on the same system). In comparison, ping.exe succeeds on all these devices, but I have no idea how the implementation of Ping differs. All cases I have tried so far have been IPv4, which I provided directly (so no DNS etc.).
hIcmpFile = IcmpCreateFile();
ipAddress = inet_addr(ipAddressStr);
...hIcmpFile is reused
static const WORD sendSize = 32;
static const DWORD replySize = sizeof(ICMP_ECHO_REPLY) + sendSize;
char sendData[sendSize] = { 0 };
char replyBuffer[replySize];
auto ret = IcmpSendEcho(hIcmpFile, ipAddress, sendData, sendSize, NULL, replyBuffer, replySize, 1000);
if (ret == 0)
{
auto error = GetLastError();
The only other report I have found is what would cause ICMPsendEcho to fail when ping.exe succeeds. However those answers appear to differ from my problem. I have tried using different payload sizes, and I have tried IcmpSendEcho2, that also failed for the same devices.
Try running with Administrator rights.
I've been having a similar problem, but I think the issue is due to the icmp request timing out before you get a reply.
My code is based heavily on the example code from the MSDN page for IcmpSendEcho, only I added a number of retries on failure. My code runs in the evenings, when machines are likely to have gone to sleep or some other low power state which means they take a few seconds to wake up and reply.
Usually my output logs state that the first ping attempt fails with error 11010. The second attempt always succeeds. So I'm guessing the first ping gives the machine a poke and wakes it up, but I miss the delayed reply. The second ping succeeds.
So try either adding a longer timeout or just add a few retries.