Holger Steinhaus

Retested this issue with 2.0.15-rc1 - it's still there. But I have never seen such a fast parameter transfer via 3DR radio before. It is 13 seconds now for 436...

2 seconds was normal under Linux as well, up to version 2.0.10. Sounds like some kind of race condition to me...

Update for version (5f3e9179-2.0.16-rc1-37-g5f3e917): I am pretty sure now that even the radio link is affected by the same problem. The first 150 params are transfered rather fast, then there...

I am using the release build, so I guess without.

My current machine is Dell 6430 ATG (medium-sized laptop, Core-i5, SSD, 8G RAM), running Centos 7.0 64 bit. At the time I started this issue I was still using a...

BTW, there seems to be no real load during the parameter transfer, neither CPU nor IO. So I really guess this problem is related to some locking stuff...

I have tried the changes. I have seen one very fast parameter load (too fast?), lots of loads at the usual slow speed, some failed connects and a few crashes...

Yes, will try to do that tomorrow.

After a few hundred dis/reconnects I regret to report that the crash only happens with the release build. When using debug executable or running in gdb, it has never ever...

finally I catched a core file using the releese build. Obviously it has no debug symbols, but may be it contains a hint: #0 0x00007f153a8c39ed in QV8Engine::toVariant(QV4::ValueRef, int) () from...