2016-07-15 3 views
2

Ich bin derzeit versucht, die DLIB-android Bibliothek zu bauen und zu verwenden, die DLIB auf Android zu portieren will. Das Bauen ist erfolgreich; Wenn Sie jedoch die kompilierte freigegebene C++ - Bibliothek im entsprechenden Demoprojekt dlib-android-app verwenden, stürzt die App beim Starten von Bibliotheksfunktionen über JNI ab.DLIB/DLIB-android Abstürze während der Laufzeit, wenn auf OSX gebaut

Dieser Laufzeitabsturz tritt bei jedem Build auf, den ich lokal mit einer beliebigen NDK-Version unter OSX oder Debian ausführe. Der Absturz kann jedoch nicht reproduziert werden, indem die vorgefertigte Version dlib-android verwendet wird, die in dem Projekt dlib-android-app enthalten ist. Außerdem gibt der Projektbetreuer an, dass er das Problem nicht reproduzieren kann.

Welche Faktoren können dazu führen, dass meine lokalen Builds auf zwei verschiedenen Betriebssystemen fehlerhaft werden, während der Projektmaintainer mit derselben Codebasis und demselben Build-Vorgang einen funktionalen Build erstellen kann? Könnte es sein, dass globale Compilerflags dieses Problem verursachen könnten?

Ressourcen

Stapelüberwachung

backtrace: 
    #00 pc 000372dc /system/lib/libc.so (tgkill+12) 
    #01 pc 00014719 /system/lib/libc.so (pthread_kill+52) 
    #02 pc 00015337 /system/lib/libc.so (raise+10) 
    #03 pc 00011bd1 /system/lib/libc.so (__libc_android_abort+36) 
    #04 pc 00010044 /system/lib/libc.so (abort+4) 
    #05 pc 0046a103 /data/app/com.tzutalin.dlibtest-1/lib/arm/libpeople_det.so (__gnu_cxx::__verbose_terminate_handler()+226) 
    #06 pc 00433dc9 /data/app/com.tzutalin.dlibtest-1/lib/arm/libpeople_det.so (__cxxabiv1::__terminate(void (*)())+4) 
    #07 pc 00433e3d /data/app/com.tzutalin.dlibtest-1/lib/arm/libpeople_det.so (std::terminate()+8) 
    #08 pc 00433f61 /data/app/com.tzutalin.dlibtest-1/lib/arm/libpeople_det.so (__cxa_throw+120) 
    #09 pc 00150a9c /data/app/com.tzutalin.dlibtest-1/lib/arm/libpeople_det.so (dlib::compress_stream_kernel_1<dlib::entropy_encoder_model_kernel_5<257ul, dlib::entropy_encoder_kernel_2, 200000ul, 4ul>, dlib::entropy_decoder_model_kernel_5<257ul, dlib::entropy_decoder_kernel_2, 200000ul, 4ul>, dlib::crc32>::decompress(std::istream&, std::ostream&) const+544) 
    #10 pc 00150478 /data/app/com.tzutalin.dlibtest-1/lib/arm/libpeople_det.so (dlib::get_serialized_frontal_faces()+63512) 
    #11 pc 00140654 /data/app/com.tzutalin.dlibtest-1/lib/arm/libpeople_det.so (dlib::get_frontal_face_detector()+44) 
    #12 pc 0013544c /data/app/com.tzutalin.dlibtest-1/lib/arm/libpeople_det.so (DLibHOGFaceDetector::det(cv::Mat const&)+236) 
    #13 pc 000e8d30 /data/app/com.tzutalin.dlibtest-1/lib/arm/libpeople_det.so (Java_com_tzutalin_dlib_PeopleDet_jniBitmapFaceDect+868) 

Antwort

2

Es gibt mehrere ähnliche Beiträge über diese (ähnlich) Problem: C++ Debug builds broke in Snow Leopard X-Code Xcode 3.2.1 and C++ string fails!

wenn Python build_push.py läuft - es

ret = subprocess.call(['ndk-build', '-j4', 'NDK_LOG=1', 'NDK_DEBUG=1', 'V=0']) 

dieses Mittel bauen Gebäude Debug-Version (described here)

NDK_DEBUG = 1 Erzwinge einen debugbaren Build (siehe Tabelle 1).

NDK_DEBUG = 0 Erzwinge einen Release-Build (siehe Tabelle 1).

betrachten Wechsel build_push.py Skript mit NDK_DEBUG = 0

+0

Du bist genial, vielen Dank! –

Verwandte Themen