Welcome, Guest
Username: Password: Remember me

TOPIC: openskyd-dump1090 Segmentation fault

openskyd-dump1090 Segmentation fault 2 years 10 months ago #299

  • rfelten
  • rfelten's Avatar
  • Offline
  • New Member
  • Posts: 3
Topic says it :(

Platform:
Raspberry Pi 1B. Fresh install from 2017-09-07-raspbian-stretch-lite.img.
$ uname -a
Linux raspberrypi 4.9.59+ #1047 Sun Oct 29 11:47:10 GMT 2017 armv6l GNU/Linux

Walked trough the setup guides raspberry-pi-adsb and dump1090-feeder. dump1090 works.

Log:
pi@raspberrypi:~$ sudo journalctl -b 0 -u opensky-feeder --no-page
...
Nov 28 18:22:16 raspberrypi systemd[1]: Started OpenSky Daemon.
Nov 28 18:22:16 raspberrypi systemd[1]: opensky-feeder.service: Main process exited, code=killed, status=11/SEGV
Nov 28 18:22:16 raspberrypi systemd[1]: opensky-feeder.service: Unit entered failed state.
Nov 28 18:22:17 raspberrypi systemd[1]: opensky-feeder.service: Failed with result 'signal'.
Nov 28 18:22:27 raspberrypi systemd[1]: opensky-feeder.service: Service hold-off time over, scheduling restart.
Nov 28 18:22:27 raspberrypi systemd[1]: Stopped OpenSky Daemon.
Nov 28 18:22:27 raspberrypi systemd[1]: Started OpenSky Daemon.
Nov 28 18:22:27 raspberrypi systemd[1]: opensky-feeder.service: Main process exited, code=killed, status=11/SEGV
Nov 28 18:22:27 raspberrypi systemd[1]: opensky-feeder.service: Unit entered failed state.
Nov 28 18:22:27 raspberrypi systemd[1]: opensky-feeder.service: Failed with result 'signal'.

Start by hand:
$ openskyd-dump1090 
Segmentation fault

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!
The administrator has disabled public write access.

openskyd-dump1090 Segmentation fault 2 years 10 months ago #300

  • engel
  • engel's Avatar
  • Offline
  • Administrator
  • Posts: 10
  • Thank you received: 1
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.
wget https://opensky-network.org/files/firmware/opensky-feeder_2.1.3-1_armhf.deb

Regards,
Markus
The administrator has disabled public write access.

openskyd-dump1090 Segmentation fault 2 years 10 months ago #301

  • rfelten
  • rfelten's Avatar
  • Offline
  • New Member
  • Posts: 3
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
The administrator has disabled public write access.

openskyd-dump1090 Segmentation fault 2 years 10 months ago #302

  • engel
  • engel's Avatar
  • Offline
  • Administrator
  • Posts: 10
  • Thank you received: 1
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.
The administrator has disabled public write access.

openskyd-dump1090 Segmentation fault 2 years 10 months ago #303

  • engel
  • engel's Avatar
  • Offline
  • Administrator
  • Posts: 10
  • Thank you received: 1
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
The administrator has disabled public write access.

openskyd-dump1090 Segmentation fault 2 years 10 months ago #304

  • rfelten
  • rfelten's Avatar
  • Offline
  • New Member
  • Posts: 3
Hi Markus,

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

Best Regards
The administrator has disabled public write access.

openskyd-dump1090 Segmentation fault 1 year 9 months ago #671

Hi...this means that you would write portions of memory that you shouldn't write. Memory corruption causes segmentation faults.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.

assemblage carte circuit imprimé
Last Edit: 1 year 8 months ago by AvritSase.
The administrator has disabled public write access.

openskyd-dump1090 Segmentation fault 1 year 9 months ago #683

  • engel
  • engel's Avatar
  • Offline
  • Administrator
  • Posts: 10
  • Thank you received: 1
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
The administrator has disabled public write access.
The following user(s) said Thank You: strohmeier
Powered by Kunena Forum
This website uses cookies to offer you the best experience of our services. By using this website you agree to our privacy policy!