openskyd-dump1090 Segmentation fault

Topic says it

Platform:
Raspberry Pi 1B. Fresh install from 2017-09-07-raspbian-stretch-lite.img.
Walked trough the setup guides raspberry-pi-adsb and dump1090-feeder . dump1090 works.

Log:
Start by hand:
I've the strace attached.

Any ideas?

Btw: opensky-network.org/files/firmware/opens...der_latest_armhf.deb was an 404 yesterday. Maybe related?

Thanks!

Hi rfelten,

the link pointed to a wrong file and could thus not be downloaded, we fixed that yesterday. It is unrelated to your other problem.

The segfault problem is rooted in the fact that the debian armhf cross compiler (which we used the first time in this release) obviously does not support raspberry PI 1.
We waited to see wether there are still any users of this platform, but you just confirmed that there is at least you.
We're looking into it and check our options.

In the meantime, you can of course use an older release, e.g.
Regards,
Markus

Hi Markus,

thanks for your quick support! I've removed the actual package via sudo apt-get remove opensky-feeder and installed the suggested one. It works: journald shows a connection to the network and the receiver was added to my web profile.

Also I've removed the apt sources, I assume otherwise the next apt update/upgrade will break my feeder?

May I suggest to adept the documentation , e.g. adding which version of Raspi is needed and/or the link to the old version?
I'd be happy if there would be support for the old Raspis too - I think there are more people like me, apply a new duty to old hardware

Best Regards

Like I said: we'll check our options -- and that includes maybe updating the documentation or getting support again. Until that, yes...I should write a notice in the documentation.

I just found out that raspbian is not just "some preconfigured debian armhf" but an inofficial port of debian. As such, NO debian armhf can run under raspbian armhf. Yet, they are installable (since they share the same architecture _name_), which is, in my opinion, very unfortunate.

I think the cleanest solution would be to build a raspbian armhf package. I'll have a look into this as soon I got time for it.

It seems like there is no method to cross build a raspbian package from Debian, at least none working with the latest stable release (Debian stretch). So I set up our old method again (compiling under raspbian with a qemu-user emulation) and rebuilt the package.

After all, we are happy to announce that the current armhf version (2.1.4-3) should work again on Raspberry Pi 1 and Pi Zero.

Regards,
Markus

Hi Markus,

I've installed the fixed "latest" package and can confirm it is working. Thank you for your effort!

Best Regards

Hi...this means that you would write portions of memory that you shouldn't write. Memory corruption causes segmentation faults. But that could not only be the reason, because sometimes this failure happens due to the other components failure as well on the PCB. While working with Memory segments, PCB assembly plays an important role to avoid any kind of failure. On why exactly the first time it works and the second it doesn't, I don't know. But the code, as it's written, is incorrect.

Well, lets say: yes and no. All illegal memory accesses can lead to segmentation faults. So not only writes, but also reads and jumps.

You have to consider, that code is only one part of the product: you compile your code into an intermediate representation, which is then linked against other libraries. When starting, the binary is loaded by the interaction of an operating system and a dynamic loader and then (after a lot of steps!) executed.
All of these things have to work with each other, so if e.g. your compiler assumes something about the target architecture which is not true, this can result in different errors. The best thing which could happen is, that this is checked and you just get an error message. If it goes unchecked, this might result in illegal instructions, bus errors, ... or segmentation faults, depending on what the wrong assumption lead to.

In our case, I compiled the feeder under debian, assuming that raspbian would be compatible with the result. It actually did work for newer Raspberry Pies, but not for older ones or the Raspberry Pi Zero.
If you compile for debian armhf (which assumes newer processors), the generated binary will not load for older ones, i.e. you will not even get into your main function. Thus, if you say "code" and you mean "the feeder", your proposition is wrong -- if you mean the whole binary, yes, you could say it is somewhat "incorrect".

I don't know what you refer to when you say "the first time it works and the second it doesn't". It did NEVER work on older raspberries.

We fixed the problem by compiling the code for these older processors, so we can now run it on any (newer or older) Raspberry Pies.

Best Regards