4. QT-Programm auf Raspi32 gibt SIGSEGV

QT-Programm auf Raspi32 gibt SIGSEGV


  • Ich habe einen Streamplayer für die Console programmiert. Auf dem Desktop läuft es wunderbar, da es ein 64Bit-System ist. Auf meinem kleinen Raspi(3B) sagt mir strace jedoch, das QT versucht clock_gettime64 aufzurufen. Das crasht natürlich.
    Vor Jahren hab ich auf dem Raspi mal was mit QT4 gemacht und kann mich dunkel daran erinnern, das man dieses gettime auf 32Bit umstellen kann.
    Irgendwie fallen mir aber grad die richtigen Stichwörter für eine Google-Suche nicht ein. Kann mir einer von Euch vielleicht weiterhelfen?

    0
    S
     1 Antwort
  • S

    @daMicha Ich würde vermuten, dass du dein Program für dein Zielsystem kompilieren musst.

    0

  • Natürlich hab ich das Programm auf dem Raspi kompiliert. Das Programm läuft ja auch bis das erste Mal ein QTimer aufgerufen wird. Und der arbeitet komischerweise mit dem Aufruf von gettime64...

    0
    S
     1 Antwort
  • ?

    das spielt keine rolle solang dein kernel relativ aktuell ist, denn clock_gettime64 hat einen 32bit fallback.

    0
  • S

    @daMicha Hm, ich habe mich von dem 64 auch fehlleiten lassen, glaube ich.

    Auch auf 32 bit Systemen kann man 64 bit Zeit verwenden. Für GNU C gibt es da das Linkerflag: -D_TIME_BITS, also z.B. -D_TIME_BITS=64. Ich könnte mir vorstellen, dass das für QT gesetzt wird, um nicht das Y2038 Problem zu bekommen, dann solltest du das für deine Anwendung auch setzen.

    Wenn ich das gerade richtig gelesen habe, muss man dann auch D_FILE_OFFSET_BITS=64setzen.

    Edit: Das zweite Flag muss natürlich dann auch D_FILE_OFFSET_BITS heißen, hab das geändert 😉

    0

  • Danke erst mal, werd ich gleich mal ausprobieren.
    Das System ist ein aktuelles Bullseye und die letzte Funktion, die von strace angezeigt wird, ist die clock_gettime64. Deshalb meine Frage.

    0

  • Das Probieren hat erst mal nichts genützt. Der SegFault kommt immer noch. Der gdb hat mir jetzt aber noch mehr verraten. Der Crash passiert, nachdem das https-Plugin der vlc-lib einen poll gemacht hat. Und das scheint auch den Stack zu zerstören, also komme ich auch mit dem Backtrace nicht allzu weit.

    (gdb) backtrace
#0  __GI___poll (timeout=-1, nfds=1, fds=0xa1dfeaa4) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  __GI___poll (fds=0xa1dfeaa4, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:26
#2  0xaed0d47c in ?? () from /usr/lib/arm-linux-gnueabihf/vlc/plugins/access/libhttps_plugin.so
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

    Ich werd das morgen mal in ein kleines Mini Programm stecken um das Problem weiter einzugrenzen.
    Danke für Eure Unterstützung bisher.

    0
Anmelden zum Antworten