Kivy: Segmentierungsfehler in Raspberry 3B+

Erstellt am 22. Okt. 2018  ·  44Kommentare  ·  Quelle: kivy/kivy

Versionen

Beschreibung

Ich versuche, die Demo app_with_kv.py auszuführen, aber sie zeigt immer einen segmentation fault Fehler an. Ich benutze den TFT-Bildschirm von hier aus .

Code und Protokolle

[INFO   ] [Logger      ] Record log in /home/pi/.kivy/logs/kivy_18-10-22_12.txt
[INFO   ] [Kivy        ] v1.11.0.dev0, git-916b77b, 20181022
[INFO   ] [Python      ] v3.5.3 (default, Sep 27 2018, 17:25:39) 
[GCC 6.3.0 20170516]
[INFO   ] [Factory     ] 184 symbols loaded
[INFO   ] [Image       ] Providers: img_tex, img_dds, img_sdl2, img_pil, img_gif (img_ffpyplayer ignored)
[INFO   ] [Text        ] Provider: sdl2
[INFO   ] [Window      ] Provider: egl_rpi
[INFO   ] [GL          ] Using the "OpenGL ES 2" graphics system
[INFO   ] [GL          ] Backend used <sdl2>
Segmentation fault
RPi High SDL2 Confirmed

Hilfreichster Kommentar

Hatte ähnliche Probleme damit. Aus irgendeinem Grund wird sdl2 anstelle von gl für das Backend aufgerufen. Ich weiß nicht, ob es dafür eine dauerhafte Lösung gibt, aber nachdem ich einige Zeit versucht habe, eine Lösung zu finden, ist die einzige Lösung, die mir einfällt, die 2 Zeilen über Ihrer App hinzuzufügen, bevor Sie Kivy importieren. Sollte so aussehen:

import os
os.environ['KIVY_GL_BACKEND'] = 'gl'
import kivy

Hoffe es wird helfen. Viel Glück!

PS Wenn Sie Ihre App unter Windows ausführen möchten, möchten Sie vielleicht os.environ['KIVY_GL_BACKEND'] = 'gl' kommentieren, sonst wird sie nicht ausgeführt.

Alle 44 Kommentare

Hatte ähnliche Probleme damit. Aus irgendeinem Grund wird sdl2 anstelle von gl für das Backend aufgerufen. Ich weiß nicht, ob es dafür eine dauerhafte Lösung gibt, aber nachdem ich einige Zeit versucht habe, eine Lösung zu finden, ist die einzige Lösung, die mir einfällt, die 2 Zeilen über Ihrer App hinzuzufügen, bevor Sie Kivy importieren. Sollte so aussehen:

import os
os.environ['KIVY_GL_BACKEND'] = 'gl'
import kivy

Hoffe es wird helfen. Viel Glück!

PS Wenn Sie Ihre App unter Windows ausführen möchten, möchten Sie vielleicht os.environ['KIVY_GL_BACKEND'] = 'gl' kommentieren, sonst wird sie nicht ausgeführt.

Ich erhalte den gleichen Fehler beim Zero W. @goadik hat das 3B + für mich behoben, habe den Zero noch nicht ausprobiert.

Ich bestätige auch, dass die Lösung von @goadik funktioniert! Und ich weise auch darauf hin, dass Sie die Variable einfach wie folgt exportieren können, da es sich um ein Umgebungsvariablenproblem handelt:

export KIVY_GL_BACKEND=gl

Und dann das Skript ausführen.

SDL2 wird verwendet, um das Symbol dynamisch nachzuschlagen.
Es wäre schön, eine Rückverfolgung zu haben, um das Problem zu verstehen und zu beheben.
Der Wechsel zum GL-Backend für rpi könnte je nach Plattform implementiert werden, aber ich würde eher das zugrunde liegende Problem beheben.

Bitte verwenden Sie gdb --args python main.py , geben Sie r , und wenn es abstürzt, tun Sie bt all . Poste die ganzen Sachen.

Okay. Dies ist die Ausgabe für gdb --args python main.py :

GNU gdb (Raspbian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from python3...(no debugging symbols found)...done.
(gdb) r
Starting program: /usr/bin/python3 main.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[INFO   ] [Logger      ] Record log in /home/pi/.kivy/logs/kivy_18-10-27_0.txt
[INFO   ] [Image       ] Providers: img_tex, img_dds, img_sdl2, img_pil, img_gif (img_ffpyplayer ignored)
[INFO   ] [Kivy        ] v1.11.0.dev0, git-916b77b, 20181022
[INFO   ] [Python      ] v3.5.3 (default, Sep 27 2018, 17:25:39) 
[GCC 6.3.0 20170516]
[INFO   ] [Factory     ] 184 symbols loaded
[DEBUG  ] [App         ] Loading kv <./main.kv>
[DEBUG  ] [App         ] kv <./main.kv> not found
[INFO   ] [Window      ] Provider: egl_rpi
[New Thread 0x74758470 (LWP 973)]
[New Thread 0x73dff470 (LWP 974)]
[New Thread 0x735ff470 (LWP 975)]
[New Thread 0x72dff470 (LWP 976)]
[DEBUG  ] [Window      ] Actual display size: 800x480
[INFO   ] [GL          ] Using the "OpenGL ES 2" graphics system
[DEBUG  ] [GL          ] glActiveTexture is not available
[DEBUG  ] [GL          ] glAttachShader is not available
[DEBUG  ] [GL          ] glBindAttribLocation is not available
[DEBUG  ] [GL          ] glBindBuffer is not available
[DEBUG  ] [GL          ] glBindFramebuffer is not available
[DEBUG  ] [GL          ] glBindRenderbuffer is not available
[DEBUG  ] [GL          ] glBindTexture is not available
[DEBUG  ] [GL          ] glBlendColor is not available
[DEBUG  ] [GL          ] glBlendEquation is not available
[DEBUG  ] [GL          ] glBlendEquationSeparate is not available
[DEBUG  ] [GL          ] glBlendFunc is not available
[DEBUG  ] [GL          ] glBlendFuncSeparate is not available
[DEBUG  ] [GL          ] glBufferData is not available
[DEBUG  ] [GL          ] glBufferSubData is not available
[DEBUG  ] [GL          ] glCheckFramebufferStatus is not available
[DEBUG  ] [GL          ] glClear is not available
[DEBUG  ] [GL          ] glClearColor is not available
[DEBUG  ] [GL          ] glClearStencil is not available
[DEBUG  ] [GL          ] glColorMask is not available
[DEBUG  ] [GL          ] glCompileShader is not available
[DEBUG  ] [GL          ] glCompressedTexImage2D is not available
[DEBUG  ] [GL          ] glCompressedTexSubImage2D is not available
[DEBUG  ] [GL          ] glCopyTexImage2D is not available
[DEBUG  ] [GL          ] glCopyTexSubImage2D is not available
[DEBUG  ] [GL          ] glCreateProgram is not available
[DEBUG  ] [GL          ] glCreateShader is not available
[DEBUG  ] [GL          ] glCullFace is not available
[DEBUG  ] [GL          ] glDeleteBuffers is not available
[DEBUG  ] [GL          ] glDeleteFramebuffers is not available
[DEBUG  ] [GL          ] glDeleteProgram is not available
[DEBUG  ] [GL          ] glDeleteRenderbuffers is not available
[DEBUG  ] [GL          ] glDeleteShader is not available
[DEBUG  ] [GL          ] glDeleteTextures is not available
[DEBUG  ] [GL          ] glDepthFunc is not available
[DEBUG  ] [GL          ] glDepthMask is not available
[DEBUG  ] [GL          ] glDetachShader is not available
[DEBUG  ] [GL          ] glDisable is not available
[DEBUG  ] [GL          ] glDisableVertexAttribArray is not available
[DEBUG  ] [GL          ] glDrawArrays is not available
[DEBUG  ] [GL          ] glDrawElements is not available
[DEBUG  ] [GL          ] glEnable is not available
[DEBUG  ] [GL          ] glEnableVertexAttribArray is not available
[DEBUG  ] [GL          ] glFinish is not available
[DEBUG  ] [GL          ] glFlush is not available
[DEBUG  ] [GL          ] glFramebufferRenderbuffer is not available
[DEBUG  ] [GL          ] glFramebufferTexture2D is not available
[DEBUG  ] [GL          ] glFrontFace is not available
[DEBUG  ] [GL          ] glGenBuffers is not available
[DEBUG  ] [GL          ] glGenerateMipmap is not available
[DEBUG  ] [GL          ] glGenFramebuffers is not available
[DEBUG  ] [GL          ] glGenRenderbuffers is not available
[DEBUG  ] [GL          ] glGenTextures is not available
[DEBUG  ] [GL          ] glGetActiveAttrib is not available
[DEBUG  ] [GL          ] glGetActiveUniform is not available
[DEBUG  ] [GL          ] glGetAttachedShaders is not available
[DEBUG  ] [GL          ] glGetAttribLocation is not available
[DEBUG  ] [GL          ] glGetBooleanv is not available
[DEBUG  ] [GL          ] glGetBufferParameteriv is not available
[DEBUG  ] [GL          ] glGetError is not available
[DEBUG  ] [GL          ] glGetFloatv is not available
[DEBUG  ] [GL          ] glGetFramebufferAttachmentParameteriv is not available
[DEBUG  ] [GL          ] glGetIntegerv is not available
[DEBUG  ] [GL          ] glGetProgramInfoLog is not available
[DEBUG  ] [GL          ] glGetProgramiv is not available
[DEBUG  ] [GL          ] glGetRenderbufferParameteriv is not available
[DEBUG  ] [GL          ] glGetShaderInfoLog is not available
[DEBUG  ] [GL          ] glGetShaderiv is not available
[DEBUG  ] [GL          ] glGetShaderSource is not available
[DEBUG  ] [GL          ] glGetString is not available
[DEBUG  ] [GL          ] glGetTexParameterfv is not available
[DEBUG  ] [GL          ] glGetTexParameteriv is not available
[DEBUG  ] [GL          ] glGetUniformfv is not available
[DEBUG  ] [GL          ] glGetUniformiv is not available
[DEBUG  ] [GL          ] glGetUniformLocation is not available
[DEBUG  ] [GL          ] glGetVertexAttribfv is not available
[DEBUG  ] [GL          ] glGetVertexAttribiv is not available
[DEBUG  ] [GL          ] glHint is not available
[DEBUG  ] [GL          ] glIsBuffer is not available
[DEBUG  ] [GL          ] glIsEnabled is not available
[DEBUG  ] [GL          ] glIsFramebuffer is not available
[DEBUG  ] [GL          ] glIsProgram is not available
[DEBUG  ] [GL          ] glIsRenderbuffer is not available
[DEBUG  ] [GL          ] glIsShader is not available
[DEBUG  ] [GL          ] glIsTexture is not available
[DEBUG  ] [GL          ] glLineWidth is not available
[DEBUG  ] [GL          ] glLinkProgram is not available
[DEBUG  ] [GL          ] glPixelStorei is not available
[DEBUG  ] [GL          ] glPolygonOffset is not available
[DEBUG  ] [GL          ] glReadPixels is not available
[DEBUG  ] [GL          ] glRenderbufferStorage is not available
[DEBUG  ] [GL          ] glSampleCoverage is not available
[DEBUG  ] [GL          ] glScissor is not available
[DEBUG  ] [GL          ] glShaderBinary is not available
[DEBUG  ] [GL          ] glShaderSource is not available
[DEBUG  ] [GL          ] glStencilFunc is not available
[DEBUG  ] [GL          ] glStencilFuncSeparate is not available
[DEBUG  ] [GL          ] glStencilMask is not available
[DEBUG  ] [GL          ] glStencilMaskSeparate is not available
[DEBUG  ] [GL          ] glStencilOp is not available
[DEBUG  ] [GL          ] glStencilOpSeparate is not available
[DEBUG  ] [GL          ] glTexImage2D is not available
[DEBUG  ] [GL          ] glTexParameterf is not available
[DEBUG  ] [GL          ] glTexParameteri is not available
[DEBUG  ] [GL          ] glTexSubImage2D is not available
[DEBUG  ] [GL          ] glUniform1f is not available
[DEBUG  ] [GL          ] glUniform1fv is not available
[DEBUG  ] [GL          ] glUniform1i is not available
[DEBUG  ] [GL          ] glUniform1iv is not available
[DEBUG  ] [GL          ] glUniform2f is not available
[DEBUG  ] [GL          ] glUniform2fv is not available
[DEBUG  ] [GL          ] glUniform2i is not available
[DEBUG  ] [GL          ] glUniform2iv is not available
[DEBUG  ] [GL          ] glUniform3f is not available
[DEBUG  ] [GL          ] glUniform3fv is not available
[DEBUG  ] [GL          ] glUniform3i is not available
[DEBUG  ] [GL          ] glUniform3iv is not available
[DEBUG  ] [GL          ] glUniform4f is not available
[DEBUG  ] [GL          ] glUniform4fv is not available
[DEBUG  ] [GL          ] glUniform4i is not available
[DEBUG  ] [GL          ] glUniform4iv is not available
[DEBUG  ] [GL          ] glUniformMatrix4fv is not available
[DEBUG  ] [GL          ] glUseProgram is not available
[DEBUG  ] [GL          ] glValidateProgram is not available
[DEBUG  ] [GL          ] glVertexAttrib1f is not available
[DEBUG  ] [GL          ] glVertexAttrib2f is not available
[DEBUG  ] [GL          ] glVertexAttrib3f is not available
[DEBUG  ] [GL          ] glVertexAttrib4f is not available
[DEBUG  ] [GL          ] glVertexAttribPointer is not available
[DEBUG  ] [GL          ] glViewport is not available
[INFO   ] [GL          ] Backend used <sdl2>

Thread 1 "python3" received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()

Außerdem hat bt all ein "Kein Symbol "alle" im aktuellen Kontext" ausgegeben. Nachricht, ich habe die Ausgabe von thread apply all bt , die wie folgt lautet:

Thread 5 (Thread 0x72dff470 (LWP 976)):
#0  0x76f88014 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, 
    expected=1, futex_word=0x748885ec <cecservice_notify_available_event+24>)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:205
#1  do_futex_wait (sem=sem@entry=0x748885ec <cecservice_notify_available_event+24>, 
    abstime=0x0) at sem_waitcommon.c:115
#2  0x76f88158 in __new_sem_wait_slow (
    sem=0x748885ec <cecservice_notify_available_event+24>, abstime=0x0)
    at sem_waitcommon.c:282
#3  0x7486ec44 in cecservice_notify_func () from /opt/vc/lib/libbcm_host.so
#4  0x747d7cc4 in vcos_thread_entry (arg=0x74888600 <cecservice_notify_task>)
    at /home/dc4/projects/staging/userland/interface/vcos/pthreads/vcos_pthreads.c:144
#5  0x76f7efc4 in start_thread (arg=0x72dff470) at pthread_create.c:335
#6  0x76e0cbc8 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:76
   from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 4 (Thread 0x735ff470 (LWP 975)):
#0  0x76f88014 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, 
    expected=1, futex_word=0x74887864 <tvservice_notify_available_event+24>)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:205
#1  do_futex_wait (sem=sem@entry=0x74887864 <tvservice_notify_available_event+24>, 
    abstime=0x0) at sem_waitcommon.c:115
#2  0x76f88158 in __new_sem_wait_slow (
    sem=0x74887864 <tvservice_notify_available_event+24>, abstime=0x0)
---Type <return> to continue, or q <return> to quit---
    at sem_waitcommon.c:282
#3  0x7486e084 in tvservice_notify_func () from /opt/vc/lib/libbcm_host.so
#4  0x747d7cc4 in vcos_thread_entry (arg=0x74887878 <tvservice_notify_task>)
    at /home/dc4/projects/staging/userland/interface/vcos/pthreads/vcos_pthreads.c:144
#5  0x76f7efc4 in start_thread (arg=0x735ff470) at pthread_create.c:335
#6  0x76e0cbc8 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:76
   from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 3 (Thread 0x73dff470 (LWP 974)):
#0  0x76f88014 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, 
    expected=1, futex_word=0x748886e8 <dispmanx_notify_available_event+24>)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:205
#1  do_futex_wait (sem=sem@entry=0x748886e8 <dispmanx_notify_available_event+24>, 
    abstime=0x0) at sem_waitcommon.c:115
#2  0x76f88158 in __new_sem_wait_slow (
    sem=0x748886e8 <dispmanx_notify_available_event+24>, abstime=0x0)
    at sem_waitcommon.c:282
#3  0x74872150 in dispmanx_notify_func () from /opt/vc/lib/libbcm_host.so
#4  0x747d7cc4 in vcos_thread_entry (arg=0x74889428 <dispmanx_notify_task>)
    at /home/dc4/projects/staging/userland/interface/vcos/pthreads/vcos_pthreads.c:144
#5  0x76f7efc4 in start_thread (arg=0x73dff470) at pthread_create.c:335
#6  0x76e0cbc8 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:76
   from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
---Type <return> to continue, or q <return> to quit---

Thread 2 (Thread 0x74758470 (LWP 973)):
#0  0x76e0580c in ioctl () at ../sysdeps/unix/syscall-template.S:84
#1  0x747f1010 in completion_thread () from /opt/vc/lib/libvchiq_arm.so
#2  0x747d7cc4 in vcos_thread_entry (arg=0x74804318 <vchiq_instance+16>)
    at /home/dc4/projects/staging/userland/interface/vcos/pthreads/vcos_pthreads.c:144
#3  0x76f7efc4 in start_thread (arg=0x74758470) at pthread_create.c:335
#4  0x76e0cbc8 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:76
   from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 1 (Thread 0x76ff7010 (LWP 967)):
#0  0x00000000 in ?? ()

#1  0x74bb28d0 in __pyx_pf_4kivy_8graphics_6opengl_138glGetString (
    __pyx_self=<optimized out>, __pyx_v_name=<optimized out>)
    at /tmp/pip-bp1kpwjd-build/kivy/graphics/opengl.c:12436
#2  __pyx_pw_4kivy_8graphics_6opengl_139glGetString (__pyx_self=<optimized out>, 
    __pyx_arg_name=<optimized out>)
    at /tmp/pip-bp1kpwjd-build/kivy/graphics/opengl.c:12415
#3  0x000b1df8 in PyEval_EvalFrameEx ()
#4  0x000b1a7c in PyEval_EvalFrameEx ()
#5  0x000b1a7c in PyEval_EvalFrameEx ()
#6  0x001985c8 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

OK, sieht so aus, als ob SDL_GL_GetProcAddress nichts finden kann :( Jetzt verstehe ich.
Unsere Methode zum Erkennen und Laden von opengl ist an den verwendeten Window-Provider gebunden.
Aber in diesem Fall wird egl_rpi verwendet, nicht SDL2, daher funktioniert die SDL2-Funktion nicht.

Es erfordert eine Korrektur, danke für die Meldung!

Ich bin mir nicht sicher, ob es relevant ist, hier hinzuzufügen, aber ich denke, es hat etwas mit der neuen Version von Raspbian zu tun. Ich habe das ältere ausprobiert (ich habe ein Bild) und es funktionierte wie ein Zauber.

Das Problem mit dem Segmentierungsfehler beim App-Start kann mit einer Umgebungsvariablen behoben werden, aber es stürzt auch jedes Mal mit dem gleichen Segmentierungsfehler ab, wenn ich das Diagramm mit vielen Daten lade, die angezeigt werden sollen.

Das Problem mit GDB ist, dass, wenn ich versuche, es so zu verwenden, gdb --args python main.py und den Absturz reproduzieren, RPI einfach einfriert und das einzige, was zu diesem Zeitpunkt noch zu tun ist, darin besteht, es neu zu starten. Wenn ich die Protokolle überprüfe, sind sie leer.

Wollte es hier hinzufügen.

Ich hatte das gleiche Problem und wie @goadik sagte, könnte es ein Fehler der neuen Raspbian-Version sein, da auf meinem älteren Image (Raspberry3, kivy v1.11.0.dev0, python v3.4.2) die kivy-App einwandfrei läuft. Mein Problem ist hier beschrieben: https://stackoverflow.com/questions/53122908/kivy-opengl-segmentation-fault-on-raspberry

@krrrambambuli

Auf meinem älteren Image (Raspberry3, kivy v1.11.0.dev0, python v3.4.2) läuft die kivy-App einwandfrei

Warum also nicht das ältere Image verwenden?

RPi Devs sind berüchtigt dafür, neue "Updates" herauszubringen, die alle möglichen Dinge kaputt machen. Ich habe damit so viele unangenehme Erfahrungen gemacht, dass ich alle betriebssystembezogenen Updates, die von RPi org kommen, vollständig deaktiviert habe.

@E3V3A

Warum also nicht das ältere Image verwenden?

Denn ich hatte ein RPI, das bereits mit dem neuesten Raspbian-Update konfiguriert war. Und ich habe mich nur gefragt, warum Kivy nicht läuft, obwohl ich genau die gleichen Dinge wie zuvor gemacht habe. Jetzt habe ich auf das alte Image gewechselt und es läuft einwandfrei!

Ab jetzt kümmere ich mich um hastige Updates ;)

Vielleicht völlig unabhängig, aber wenn ich mich nicht irre: Kivy hängt von SDL2 ab und SDL2 hängt von cffi und/oder Cairo ab, und cffi ist unabhängig von der Architektur schwer zu bauen. Aber ich bin auf das folgende Pip-Paket gestoßen, vielleicht versuchen Sie das?

# pip3 search cairocffi 
cairotft (0.1.2)   - UI library for small tft screens using cairocffi

@E3V3A
Ich habe bereits auf das alte Image umgestellt. Vielleicht ist es gut zu wissen für die Zukunft

Darf ich fragen, welches Bild du verwendest und wo ich es finde? Ich verwende Rpi 3 B+ und kivy 1.11.0.dev0, welches Image soll ich verwenden?

@E3V3A
Ich habe bereits auf das alte Image umgestellt. Vielleicht ist es gut zu wissen für die Zukunft

Ich verwende Raspbian Jessie, das letzte Mal am 06.11.18 ohne Upgrades aktualisiert. Rpi3, Kivy v1.10.1 und Python 3.4.2
Mein Log:

[INFO] Logger: Log aufzeichnen in /home/pi/.kivy/logs/kivy_18-11-14_11.txt
[INFO] Kivy: v1.10.1
[INFO] Python: v3.4.2 (Standard, 19. Oktober 2014, 13:31:11)
[GCC 4.9.1]
[INFO] KivyMD: KivyMD-Version: 0.1.2
[INFO] Werk: 194 Symbole geladen
[INFO ] Bild: Anbieter: img_tex, img_dds, img_sdl2, img_pil, img_gif (img_ffpyplayer ignoriert)
[INFO ] Fenster: Anbieter: egl_rpi
[INFO] GL: Verwendung des "OpenGL ES 2"-Grafiksystems
[INFO] GL: Backend verwendet
[INFO] GL: OpenGL-Version [INFO] GL: OpenGL-Anbieter [INFO] GL: OpenGL-Renderer
[INFO] GL: OpenGL-geparste Version: 2, 0
[INFO ] GL: Beschattungsversion
[INFO] GL: Maximale Texturgröße <2048>
[INFO] GL: Textur max. Einheiten <8>
[INFO ] Fenster: virtuelle Tastatur erlaubt, Mehrbenutzermodus, nicht angedockt
[INFO] Text: Anbieter: sdl2
[INFO] GL: NPOT-Texturunterstützung ist verfügbar
[INFO ] Zwischenablage: Anbieter: xclip
[INFO] CutBuffer: CutBuffer-Unterstützung aktiviert
[INFO] ProbeSysfs: Geräteübereinstimmung: /dev/input/event0
...

Danke, hatte das gleiche Problem.
KIVY_GL_BACKEND=gl . exportieren
repariert.

habe genau das gleiche Problem in Raspberry Pi 3b+.

auch welches Raspbian-Image sollte ich in Raspberry Pi 3b+ verwenden, um Kivy zum Laufen zu bringen?

dieses Problem ist nicht behoben
usingimport os
os.environ['KIVY_GL_BACKEND'] = 'gl'
kivy importieren
ist nur eine Übergangslösung

Es wurde in diesem Thread noch nicht erwähnt, aber es könnte relevant sein, ob jemand die Lite- oder PIXEL-Version von Raspbian hat.

screen shot 2018-12-17 at 8 34 11 am

sdl2 enthält eine X-Windows-Abhängigkeit und Raspbian Lite enthält diese offensichtlich nicht.

Das schleichen kann ich bestätigen...

import os
os.environ['KIVY_GL_BACKEND'] = 'gl'

...am Anfang meines Python-Skripts lässt die App "Hello, Button" funktionieren. Ich bin auf der Stretch Lite-Version.

Welche Raspbian-Version sollte ich verwenden, um dieses Problem nicht zu haben?
Ich habe versucht, mein Betriebssystem auf Raspbian Jessie 8.0 herunterzustufen, aber ich habe den gleichen Seg-Fehler ...

Welche Raspbian-Version sollte ich verwenden, um dieses Problem nicht zu haben?
Ich habe versucht, mein Betriebssystem auf Raspbian Jessie 8.0 herunterzustufen, aber ich habe den gleichen Seg-Fehler ...

Gleiches Problem hier mit einem Himbeer-Pi 3b+:

Startprogramm: /usr/bin/python3 /home/pi/sorbito/main.py
[Thread-Debugging mit aktivierter libthread_db]
Verwenden der Hostbibliothek libthread_db "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[INFO] [Logger] Log aufzeichnen in /home/pi/.kivy/logs/kivy_19-02-13_3.txt
[INFO] [Kivy] v1.11.0.dev0, git-233cdd1, 20190212
[INFO] [Python] v3.5.3 (Standard, 27.09.2018, 17:25:39)
[GCC 6.3.0 20170516]
[INFO] [Factory] 184 Symbole geladen
[INFO ] [Image ] Anbieter: img_tex, img_dds, img_pil, img_gif (img_sdl2, img_ffpyplayer ignoriert)
[INFO] [Text] Anbieter: sdl2
[INFO] [Fenster] Anbieter: egl_rpi
[Neuer Thread 0x747ff470 (LWP 2420)]
[Neuer Thread 0x73dff470 (LWP 2421)]
[Neuer Thread 0x735ff470 (LWP 2422)]
[Neuer Thread 0x72dff470 (LWP 2423)]
[INFO] [GL] Verwendung des "OpenGL ES 2"-Grafiksystems
[INFO] [GL] Verwendetes Backend

Thread 1 "python3" empfängt Signal SIGSEGV, Segmentierungsfehler.
0x00000000 im ?? ()

Protokoll:
[INFO] Logger: Log aufzeichnen in /home/pi/.kivy/logs/kivy_19-02-13_3.txt
[INFO] Kivy: v1.11.0.dev0, git-233cdd1, 20190212
[INFO] Python: v3.5.3 (Standard, 27. September 2018, 17:25:39)
[GCC 6.3.0 20170516]
[INFO] Werk: 184 Symbole geladen
[INFO ] Bild: Anbieter: img_tex, img_dds, img_pil, img_gif (img_sdl2, img_ffpyplayer ignoriert)
[INFO] Text: Anbieter: sdl2
[INFO ] Fenster: Anbieter: egl_rpi
[INFO] GL: Verwendung des "OpenGL ES 2"-Grafiksystems
[INFO] GL: Backend verwendet

Immer noch keine Lösung dafür?

os.environ['KIVY_GL_BACKEND'] = 'gl'hilft überhaupt nicht mit v1.11.0.dev0, git-9ebad2d, 20190516

Erhalten: [KRITISCH] [App ] Fenster kann nicht abgerufen werden, Abbruch

Und mit älteren Versionen wie 1.10.1 bekomme ich keine transparente PNG-Unterstützung...alle transparenten PNGs werden mit einem schwarzen Hintergrund gezeichnet...derselbe Code funktioniert jedoch unter Debian 9 einwandfrei...

Wird RPi Stretch-Lite also nie wieder unterstützt?

Lies meinen letzten Kommentar zu diesem Thread zurück. Es funktioniert für mich auf Raspbian Stretch Lite (Nov 2018) und meine 1.10.1 _unterstützt_ die etwa hundert PNG-Grafiken, die ich mit transparentem Hintergrund verwende.

Das Bestätigen eines Builds mit dem neuesten Stable (1.11.0) in einer vollständig aktuellen stretch-lite-Installation auf einem beliebigen RPI verursacht diesen Segmentierungsfehler. Muss stable-1.10.1 erstellen, um auf einem RPI ausgeführt zu werden. Ich bin mir nicht sicher, warum Sie einen Stall veröffentlichen würden, der dieses Problem seit über 6 Monaten auf einer großen Plattform hat.

Ich habe dieses Problem auch auf Raspberry 3 B+, ​​auf Raspbian Lite

Eine gute Problemumgehung besteht im Moment darin, sicherzustellen, dass Pillow installiert ist, und dann kivy mit KIVY_WINDOW=sdl2 auszuführen. In diesem Fall muss das gl-Backend nicht eingestellt werden, da sdl2 verwendet wird. Wenn Sie den Fensteranbieter egl_rpi möchten, muss das gl-Backend eingestellt werden.

Dies ist definitiv ein Regressionsfehler. Installation auf RPI 3B+ als

pip install git+https://github.com/kivy/[email protected]

rendert einen Segmentierungsfehler, während

pip install git+https://github.com/kivy/[email protected]

klappt wunderbar.

Ich plane, es in der Post-Release zu beheben.

Am Mi, 12. Juni 2019, 13:11 RafalSkolasinski [email protected]
schrieb:

Dies ist definitiv als Regressionsfehler zu qualifizieren. Installation auf RPI 3B+ als

pip install git+ https://github.com/kivy/[email protected]

rendert einen Segmentierungsfehler, während

pip install git+ https://github.com/kivy/[email protected]

klappt wunderbar.


Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/kivy/kivy/issues/6007?email_source=notifications&email_token=AAMRN7T3A2SZJ5OE4QQ63NDP2EU2XA5CNFSM4F6QJQM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63DNP20com2
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAMRN7XWDPCYLGW5QREDN3DP2EU2XANCNFSM4F6QJQMQ
.

Kannst du https://github.com/kivy/kivy/pull/6384 testen? Dies sollte das Problem beheben und es Ihnen auch ermöglichen, eines der drei Backends zu verwenden, wenn es manuell ausgewählt wird (egl_rpi, sdl2 und x11, falls kompiliert).

Kann ich heute oder morgen später testen.

Am Do, 13. Juni 2019, 22:52 Uhr schrieb matham, [email protected] :

Können Sie #6384 https://github.com/kivy/kivy/pull/6384 testen? Das sollte
behebe es und erlaube dir auch, eines der drei Backends zu verwenden, wenn es ausgewählt ist
manuell (egl_rpi, sdl2 und x11, falls kompiliert).


Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/kivy/kivy/issues/6007?email_source=notifications&email_token=ACTL75LVT74IBQJQ4W5QARTP2K6RXA5CNFSM4F6QJQM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBWLO3LNMVX2GODX189
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/ACTL75OGYIBPXEVW33B57KLP2K6RXANCNFSM4F6QJQMQ
.

6384 Behebt es für mich mit egl_rpi auf raspbian-lite, keine Exporte erforderlich.

[INFO] Logger: Log aufzeichnen in /home/pi/.kivy/logs/kivy_19-06-14_1.txt
[INFO ] Bild: Anbieter: img_tex, img_dds, img_pil, img_gif (img_sdl2, img_ffpyplayer ignoriert)
[INFO] Kivy: v2.0.0.dev0, git-dccba95, 20190614
[INFO] Kivy: Installiert unter "/home/pi/Stuff/kivy-fix/kivy/__init__.py"
[INFO] Python: v3.5.3 (Standard, 27. September 2018, 17:25:39)
[GCC 6.3.0 20170516]
[INFO] Python: Interpreter unter "/usr/bin/python3"
[INFO] Werk: 184 Symbole geladen
[INFO] Text: Anbieter: sdl2
[INFO ] Fenster: Anbieter: egl_rpi
[INFO] GL: Verwendung des "OpenGL ES 2"-Grafiksystems
[INFO] GL: Backend verwendet
[INFO] GL: OpenGL-Version [INFO] GL: OpenGL-Anbieter [INFO] GL: OpenGL-Renderer
[INFO] GL: OpenGL-geparste Version: 2, 0
[INFO ] GL: Schattierung v

Ja es funktioniert.
Anfangs hatte ich ein Problem und bekam einige Fehler

[CRITICAL] [Window      ] Unable to find any valuable Window provider.

aber nach dem Hinzufügen von pillow fing es an zu funktionieren.
Ich denke, pillow sind neue Abhängigkeiten, die in 1.11 hinzugefügt wurden?

bearbeiten:
Wird dieser Fix in 1.11.1 ? Aha

[INFO ] Kivy: v2.0.0.dev0, git-dccba95, 20190614

in Protokollen.

Dies wird in einer Nachveröffentlichung von 1.11.0.post0 (https://github.com/kivy/kivy/pull/6357) ausgewählt. Auf diese Weise erhalten Benutzer, die bei der Installation 1.11.0 als Ziel haben, automatisch die korrigierte Version (vorausgesetzt, pip macht hier das Richtige und installiert 1.11.0.post0 wenn 1.11.0 angefordert wird).

Normalerweise würde ich zu 1.11.1 gehen, aber das funktioniert mit unserem Workflow nicht sehr gut, da wir auf 2.0.0 umgestiegen sind und das nächste Release Dinge wie Python 2-Unterstützung bricht. Diese Veröffentlichung sollte sehr bald erfolgen.

Was das Kissen betrifft, bin ich mir nicht sicher, was los ist. sdl2_image hätte funktionieren sollen (ich denke, es hat in der Vergangenheit funktioniert?), aber aus irgendeinem Grund kann das Bild nicht geladen werden. Ich denke, es müsste weiter behoben werden (PRs willkommen). Auf jeden Fall habe ich die Dokumentation aktualisiert, um Kissen als Abhängigkeit aufzulisten.

Ich würde 1.11.1 wählen, da dann klar ist, dass ein Bugfix enthalten ist. Lasst uns
Ich hoffe, dass Pip wir das Richtige tun werden.

Am Freitag, 14. Juni 2019, 17:11 Uhr schrieb matham, [email protected] :

Dies wird in einer Nachveröffentlichung von 1.11.0.post0 (#6357 .)
https://github.com/kivy/kivy/pull/6357 ). Auf diese Weise Menschen, die zielen
1.11.0 wird bei der Installation automatisch die feste Version erhalten (vorausgesetzt
pip macht hier das Richtige und installiert 1.11.0.post0 wenn 1.11.0 ist
angefordert).

Normalerweise würde ich zu 1.11.1 gehen, aber das funktioniert bei unserem nicht so gut
Workflow, angesichts unseres Sprungs zu 2.0.0 und der nächsten Version, die Dinge bricht, wie z
als Python-2-Unterstützung. Diese Veröffentlichung sollte sehr bald erfolgen.

Was das Kissen betrifft, bin ich mir nicht sicher, was los ist. sdl2_image hätte funktionieren sollen
(Ich denke, es hat in der Vergangenheit funktioniert?), aber aus irgendeinem Grund kann es nicht geladen werden
das Bild. Ich denke, es müsste weiter behoben werden (PRs willkommen). In
Auf jeden Fall habe ich die Dokumentation aktualisiert, um Kissen als Abhängigkeit aufzulisten.


Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/kivy/kivy/issues/6007?email_source=notifications&email_token=ACTL75LMHH3Q2FDKYW4HTUTP2O7LDA5CNFSM4F6QJQM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVX2GOD1
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/ACTL75NBY6O6KBPR4QT3LPDP2O7LDANCNFSM4F6QJQMQ
.

Wenn Sie nach 1.11.0 fragen, wird pip wahrscheinlich nicht 1.11.1 installieren, sondern genau 1.11.0. Ich bin mir nicht sicher, was es bewirken würde, wenn wir um 1.11 bitten,

Oh, ich meinte, dass es gepatchte ".post0" installiert, wenn wir nach "1.11.0" fragen :)

Am Freitag, 14. Juni 2019, 19:29 Uhr schrieb matham, [email protected] :

Wenn Sie nach 1.11.0 fragen, installiert pip wahrscheinlich nicht 1.11.1, sondern 1.11.0
Exakt. Ich bin mir nicht sicher, was es tun würde, wenn wir nach 1.11 fragen,


Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/kivy/kivy/issues/6007?email_source=notifications&email_token=ACTL75JZDOPPHORTC3LEVZTP2PPPNA5CNFSM4F6QJQM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVDZLOXXPWS22comment
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/ACTL75KC3BTJGUQTTBMAHLDP2PPPNANCNFSM4F6QJQMQ
.

Wie oben besprochen, habe ich export KIVY_GL_BACKEND=gl zum Pfad hinzugefügt und jetzt bekomme ich ein weiteres Problem, das besagt ...
create_window() takes 1 positional argument but 2 were given

bitte helft mir aus diesem fehler heraus.
wenn ich meinen Code in Himbeere pi . ausführe

sudo python3 main.py
[WARNUNG] [Config ] Ältere Konfigurationsversion erkannt (0 statt 14)
[WARNUNG] [Config ] Aktualisieren der Konfiguration im Gange.
[INFO] [Logger] Log aufzeichnen in /root/.kivy/logs/kivy_19-06-17_0.txt
[INFO] [Kivy] v1.9.1
[INFO] [Python] v3.5.3 (Standard, 27.09.2018, 17:25:39)
[GCC 6.3.0 20170516]
[INFO] [Factory] 179 Symbole geladen
[INFO ] [Image ] Anbieter: img_tex, img_dds, img_gif, img_sdl2, img_pil (img_ffpyplayer ignoriert)
[INFO] [Text] Anbieter: sdl2
[INFO] [OSC] mitfür Steckdose
[INFO ] [Window ] Provider: sdl2(['window_egl_rpi'] ignoriert)
Fehler: XDG_RUNTIME_DIR in der Umgebung nicht gesetzt.
[KRITISCH] [Window ] Kann keinen wertvollen Windows-Anbieter finden!
egl_rpi - ImportError: Name 'bcm' kann nicht importiert werden
Datei "/usr/lib/python3/dist-packages/kivy/core/__init__.py", Zeile 59, in core_select_lib
fromlist=[Modulname], level=0)
Datei "/usr/lib/python3/dist-packages/kivy/core/window/window_egl_rpi.py", Zeile 12, in
aus kivy.lib.vidcore_lite import bcm, egl

sdl2 - RuntimeError: b'Kein verfügbares Videogerät'
Datei "/usr/lib/python3/dist-packages/kivy/core/__init__.py", Zeile 67, in core_select_lib
cls = cls()
Datei "/usr/lib/python3/dist-packages/kivy/core/window/window_sdl2.py", Zeile 138, in __init__
super(WindowSDL, selbst).__init__()
Datei "/usr/lib/python3/dist-packages/kivy/core/window/__init__.py", Zeile 722, in __init__
self.create_window()
Datei "/usr/lib/python3/dist-packages/kivy/core/window/window_sdl2.py", Zeile 237, in create_window
self.fullscreen, veränderbar, Zustand)
Datei "kivy/core/window/_window_sdl2.pyx", Zeile 80, in kivy.core.window._window_sdl2._WindowSDL2Storage.setup_window (kivy/core/window/_window_sdl2.c:1893)
Datei "kivy/core/window/_window_sdl2.pyx", Zeile 55, in kivy.core.window._window_sdl2._WindowSDL2Storage.die (kivy/core/window/_window_sdl2.c:1479)

x11 - ImportError: Kein Modul namens 'kivy.core.window.window_x11'
Datei "/usr/lib/python3/dist-packages/kivy/core/__init__.py", Zeile 59, in core_select_lib
fromlist=[Modulname], level=0)

[KRITISCH] [App ] Fenster kann nicht abgerufen werden, Abbruch.
Ausnahme ignoriert in: 'kivy.properties.dpi2px'
Traceback (letzter Anruf zuletzt):
Datei "/usr/lib/python3/dist-packages/kivy/utils.py", Zeile 513, in __get__
retval = self.func(inst)
Datei "/usr/lib/python3/dist-packages/kivy/metrics.py", Zeile 175, in dpi
EventLoop.ensure_window()
Datei "/usr/lib/python3/dist-packages/kivy/base.py", Zeile 126, in secure_window
sys.exit(1)
Systemausgang: 1
[KRITISCH] [App ] Fenster kann nicht abgerufen werden, Abbruch.

Jemand, bitte lassen Sie mich wissen, was ich tun soll.

@jayeshsingh9767 hast du es mit Master oder der letzten Version versucht? Dies wurde in Master behoben, aber wir haben noch keine neue Version veröffentlicht, die den Fix enthält.

@harshp1301 Dieser Fehler hat nichts mit diesem Problem zu

@matham Danke, aber das Problem ist behoben, als ich Window.size() aus meinem Code entfernt habe.
Ich denke, wir können die Kivy-App Window in Raspberry Pi nicht verwalten .... Aber könnte mir jemand erklären, warum?
Hinweis: Wimdow.size() lief unter Ubuntu perfekt...

Dies hat nichts mit diesem Problem zu tun, also vielleicht ein neues Problem dafür eröffnen (falls noch keins existiert)? Aber vielleicht ist das mit dem Fenster-Backend egl_rpi nicht möglich. Ich würde es mit dem sdl2-Backend oder dem x11-Fenster-Backend versuchen (ich denke, beide sind sogar auf dem Pi veränderbar).

Ich hatte ähnliche Probleme mit dem aktuellen Raspbian Lite OS (2020-05-27) --> nach dem ersten Laden bekam ich einen Segmentierungsfehler. Dann habe ich versucht, auf 'gl' umzuschalten. Danach bekomme ich einen Welchen Bildschirm und einen schwarzen Cursor ohne Inhalt von meiner GUI.
Wenn ich zu einem früheren Raspbian Lite zurückgeschaltet habe, funktioniert es mit Kivy 1.11.1. Eigentlich weiß ich nicht was genau der Unterschied ist. Es scheint, dass es einige Updates gibt, die dieses Problem verursachen (Libs, Firmware ...?). Zum Glück habe ich die alte SD-Karte gesichert und für meine tatsächlich verwendete GUI wiederhergestellt.
Ich habe mich für Kivy entschieden, weil ich X11 nicht installieren muss. Meine GUI läuft in der Konsole...

@AndreasPantle Ich habe die gleiche Erfahrung mit 1.11.1 und Raspberry PI OS (umbenannt in Raspbian). Ich werde 1.10.1 einen Wirbel geben und sehen, was passiert. kivy ist eine Abhängigkeit vom Mission Pinball-Mediencontroller, hat also möglicherweise nicht die Möglichkeit, die Version umzudrehen.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen
bleepcoder.com verwendet öffentlich lizenzierte GitHub-Informationen, um Entwicklern auf der ganzen Welt Lösungen für ihre Probleme anzubieten. Wir sind weder mit GitHub, Inc. noch mit anderen Entwicklern affiliiert, die GitHub für ihre Projekte verwenden. Wir hosten keine der Videos oder Bilder auf unseren Servern. Alle Rechte gehören ihren jeweiligen Eigentümern.
Quelle für diese Seite: Quelle

Beliebte Programmiersprachen
Beliebte GitHub Projekte
Mehr GitHub Projekte

© 2024 bleepcoder.com - Contact
Made with in the Dominican Republic.
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.