Search Results

Search found 3 results on 1 pages for 'rpf'.

Page 1/1 | 1 

  • WP7 BarcodeManager - Invalid cross-thread access

    - by rpf
    I'm trying to use Windows Phone 7 Silverlight ZXing Barcode Scanning Library but I'm having some problems. I'm using a background worker to check the image, but when I do this: WP7BarcodeManager.ScanBarcode(this.Image, BarcodeResults_Finished); The code throws an exception: Invalid cross-thread access. Here is my code... void photoChooserTask_Completed(object sender, PhotoResult e) { if (e.TaskResult == TaskResult.OK) { ShowImage(); System.Windows.Media.Imaging.BitmapImage bmp = new System.Windows.Media.Imaging.BitmapImage(); bmp.SetSource(e.ChosenPhoto); imgCapture.Source = bmp; this.Image = new BitmapImage(); this.Image.SetSource(e.ChosenPhoto); progressBar.Visibility = System.Windows.Visibility.Visible; txtStatus.Visibility = System.Windows.Visibility.Collapsed; worker.RunWorkerAsync(); } else ShowMain(); } void worker_DoWork(object sender, DoWorkEventArgs e) { try { Thread.Sleep(2000); WP7BarcodeManager.ScanMode = com.google.zxing.BarcodeFormat.UPC_EAN; WP7BarcodeManager.ScanBarcode(this.Image, BarcodeResults_Finished); } catch (Exception ex) { Debug.WriteLine("Error processing image.", ex); } } How can I solve this?

    Read the article

  • HP-UX: libstd_v2 in stack trace of JNI code compiled with g++

    - by Miguel Rentes
    Hello, uname -mr: B.11.23 ia64 g++ --version: g++ (GCC) 4.4.0 java -version: Java(TM) SE Runtime Environment (build 1.6.0.06-jinteg_20_jan_2010_05_50-b00) Java HotSpot(TM) Server VM (build 14.3-b01-jre1.6.0.06-rc1, mixed mode) I'm trying to run a Java application that uses JNI. It is crashing inside the JNI code with the following (abbreviated) stack trace: (0) 0xc0000000249353e0 VMError::report_and_die{_ZN7VMError14report_and_dieEv} + 0x440 at /CLO/Components/JAVA_HOTSPOT/Src/src/share/vm/utilities/vmError.cpp:738 [/opt/java6/jre/lib/IA64W/server/libjvm.so] (1) 0xc000000024559240 os::Hpux::JVM_handle_hpux_signal{_ZN2os4Hpux22JVM_handle_hpux_signalEiP9 __siginfoPvi} + 0x760 at /CLO/Components/JAVA_HOTSPOT/Src/src/os_cpu/hp-ux_ia64/vm/os_hp-ux_ia64.cpp:1051 [/opt/java6/jre/lib/IA64W/server/libjvm.so] (2) 0xc0000000245331c0 os::Hpux::signalHandler{_ZN2os4Hpux13signalHandlerEiP9__siginfoPv} + 0x80 at /CLO/Components/JAVA_HOTSPOT/Src/src/os/hp-ux/vm/os_hp-ux.cpp:4295 [/opt/java6/jre/lib/IA64W/server/libjvm.so] (3) 0xe00000010e002620 ---- Signal 11 (SIGSEGV) delivered ---- (4) 0xc0000000000d2d20 __pthread_mutex_lock + 0x400 at /ux/core/libs/threadslibs/src/common/pthreads/mutex.c:3895 [/usr/lib/hpux64/libpthread.so.1] (5) 0xc000000000342e90 __thread_mutex_lock + 0xb0 at ../../../../../core/libs/libc/shared_em_64/../core/threads/wrappers1.c:273 [/usr/lib/hpux64/libc.so.1] (6) 0xc00000000177dff0 _HPMutexWrapper::lock{_ZN15_HPMutexWrapper4lockEPv} + 0x90 [/usr/lib/hpux64/libstd_v2.so.1] (7) 0xc0000000017e9960 std::basic_string,std::allocator{_ZNSsC1ERKSs} + 0x80 [/usr/lib/hpux64/libstd_v2.so.1] (8) 0xc000000008fd9fe0 JniString::str{_ZNK9JniString3strEv} + 0x50 at eg_handler_jni.cxx:50 [/soft/bus-7_0/lib/libbus_registry_jni.so.7.0.0] (9) 0xc000000008fd7060 pt_efacec_se_aut_frk_cmp_registry_REGHandler::getKey{_ZN44pt_efacec_se_aut_frk_cmp_registry_REGHandler6getKeyEP8_jstringi} + 0xa0 [/soft/bus-7_0/lib/libbus_registry_jni.so.7.0.0] (10) 0xc000000008fd17f0 Java_pt_efacec_se_aut_frk_cmp_registry_REGHandler_getKey__Ljava_lang_String_2I + 0xa0 [/soft/bus-7_0/lib/libbus_registry_jni.so.7.0.0] (11) 0x9fffffffdf400ed0 Internal error (-3) while unwinding stack [/CLO/Components/JAVA_HOTSPOT/Src/src/os_cpu/hp-ux_ia64/vm/thread_hp-ux_ia64.cpp:142] This JNI code and dependencies are being compiled using g++, are multithreaded and 64 bit (-pthread -mlp64 -shared -fPIC). The LD_LIBRARY_PATH environment variable is set the dependencies location, and running ldd on the JNI shared libraries finds them all: ldd libbus_registry_jni.so: libefa-d.so.7 = /soft/bus-7_0/lib/libefa-d.so.7 libbus_registry-d.so.7 = /soft/bus-7_0/lib/libbus_registry-d.so.7 libboost_thread-gcc44-mt-d-1_41.so = /usr/local/lib/libboost_thread-gcc44-mt-d-1_41.so libboost_system-gcc44-mt-d-1_41.so = /usr/local/lib/libboost_system-gcc44-mt-d-1_41.so libboost_regex-gcc44-mt-d-1_41.so = /usr/local/lib/libboost_regex-gcc44-mt-d-1_41.so librt.so.1 = /usr/lib/hpux64/librt.so.1 libstdc++.so.6 = /opt/hp-gcc-4.4.0/lib/gcc/ia64-hp-hpux11.23/4.4.0/../../../hpux64/libstdc++.so.6 libm.so.1 = /usr/lib/hpux64/libm.so.1 libgcc_s.so.0 = /opt/hp-gcc-4.4.0/lib/gcc/ia64-hp-hpux11.23/4.4.0/../../../hpux64/libgcc_s.so.0 libunwind.so.1 = /usr/lib/hpux64/libunwind.so.1 librt.so.1 = /usr/lib/hpux64/librt.so.1 libm.so.1 = /usr/lib/hpux64/libm.so.1 libunwind.so.1 = /usr/lib/hpux64/libunwind.so.1 libdl.so.1 = /usr/lib/hpux64/libdl.so.1 libunwind.so.1 = /usr/lib/hpux64/libunwind.so.1 libc.so.1 = /usr/lib/hpux64/libc.so.1 libuca.so.1 = /usr/lib/hpux64/libuca.so.1 Looking at the stack trace, it seams odd that, although ldd list g++'s libstdc++ is being used, the std:string copy c'tor being reported as used is the one in libstd_v2, the implementation provided by aCC. The crash happens in the following code, when method str() returns: class JniString { std::string m_utf8; public: JniString(JNIEnv* env, jstring instance) { const char* utf8Chars = env-GetStringUTFChars(instance, 0); if (utf8Chars == 0) { env-ExceptionClear(); // RPF throw std::runtime_error("GetStringUTFChars returned 0"); } m_utf8.assign(utf8Chars); env-ReleaseStringUTFChars(instance, utf8Chars); } std::string str() const { return m_utf8; } }; Simultaneous usage of the two C++ implementations could likely be a reason for the crash, but that should not be happening. Any ideas?

    Read the article

1