2016-05-22 14 views
0

Kann mir bitte jemand helfen? Ich habe eine Test-SDL2-Anwendung, die auf meinem Handy läuft. Ich nahm eine Kopie der Beispiel-App und begann in Code von meiner eigenen Anwendung zu portieren, die gut baut und verbindet.Android SDL2 Startup Crash

Meine Anwendung stürzt beim Start mit dem folgenden Fehler im Protokoll (letzte Zeile):

05-22 16:24:48.271 14834-14834/org.libsdl.app D/dalvikvm: Trying to load lib /data/app-lib/org.libsdl.app-13/libSDL2.so 0x42b0fb20 
05-22 16:24:48.271 14834-14834/org.libsdl.app D/dalvikvm: Added shared lib /data/app-lib/org.libsdl.app-13/libSDL2.so 0x42b0fb20 
05-22 16:24:48.271 14834-14834/org.libsdl.app D/dalvikvm: Trying to load lib /data/app-lib/org.libsdl.app-13/libmain.so 0x42b0fb20 
05-22 16:24:48.281 14834-14834/org.libsdl.app A/libc: Fatal signal 11 (SIGSEGV) at 0x0000000c (code=1), thread 14834 (org.libsdl.app) 

Ich habe meinen main() Code kommentiert und ersetzt diesen Inhalt mit dem main() aus der Beispielanwendung und es stürzt immer noch ab.

Ich bin mit der langatmigen Aufgabe konfrontiert, Quelldateien und Komponenten inkrementell einzubauen, bis ich die Ursache identifizieren kann.

Kennt jemand bitte eine gemeinsame Ursache dafür?

Ich mache einen sauberen Build und laufen jedes Mal.

+1

Es sieht so aus, als ob Sie logcat Ausgangsfilterung aktiviert haben. In der Ausgabe sollte nach der Zeile "fatales Signal" eine Stapelverfolgung vorhanden sein, die sichtbar ist, wenn Sie in logcat "Keine Filter" auswählen. Die Dekodierung dieser Stack-Trace wird Ihre Suche hoffentlich ein wenig schmäler machen. –

+0

@ bullsy Danke dafür. Ja, ich habe neulich in den Protokollen mehr Informationen gefunden, und es sieht so aus, als ob ein Teil meines Codes abstürzt, wo globale Klassenobjekte konstruiert werden. Also - ein Fehler in meinem Code mit anderen Worten - etwas, das ich in der Lage sein sollte, mich selbst zu reparieren und nichts speziell für SDL oder NDK im Allgemeinen. Fügen Sie Ihren Kommentar als Antwort hinzu und ich werde ihn akzeptieren, denn genau das ist die Schlussfolgerung, zu der ich gekommen bin. Ich wusste nicht, wie man den Filter ein- und ausschaltet, also habe ich ihn vielleicht ausgeschaltet und die ganze Spur aus Versehen gesehen. – SparkyNZ

+0

Ich bin froh, dass Sie es eingrenzen konnten. Es ist leicht, die Ablaufverfolgung zu verpassen, da die Filterung standardmäßig auf "Nur diese Anwendung anzeigen" zeigt. Das Debuggen eines Absturzes unter Last kann schwierig sein, aber die neu integrierten C++ - Debugging-Tools in Android Studio sind hilfreich. Wenn Sie sie nicht bereits verwenden und an diesem Problem noch arbeiten, können Sie die Android Studio 2.2-Vorschau ausprobieren. –

Antwort

1

Es sieht so aus, als ob Sie die Ausgabe von logcat gefiltert haben. In der Ausgabe sollte nach der Zeile "fatales Signal" eine Stapelverfolgung vorhanden sein, die sichtbar ist, wenn Sie in logcat "Keine Filter" auswählen. Die Dekodierung dieser Stack-Trace wird Ihre Suche hoffentlich ein wenig schmäler machen.