Hmm, I tried compiling with emcc -O2 -g2 myself, but did not get that more human-readable callstack, it sticked to the same as I already posted :-/ Is there something else I've to take care of?
Am Donnerstag, 28. Mai 2015 13:51:04 UTC+2 schrieb jj: > > If it is attempting to do some threads related operation, it may be worth > trying to find if there's a configuration flag to omit threading. There is > a pthreads pull request at https://github.com/kripken/emscripten/pull/3266 > coming up to add threading support, but that does sound like overkill in > this case. It is possible that perhaps the code is doing a TLS operation or > similar to be thread-friendly for calling code, which probably would just > need to be stubbed out better in src/library_pthread_stub.js (in that PR). > But perhaps there's just a simple config flag to remove references to > threading and assume a singlethreaded context/build. > > 2015-05-28 13:53 GMT+03:00 Bruce Mitchener <[email protected] > <javascript:>>: > >> I compiled this myself with -O2 -g2 and I'm seeing it crash in a >> different way than was indicated in the email. >> >> I'm seeing this stack trace: >> >> _abort_message (DecodeImage.js:51490) >> __ZN10__cxxabiv112_GLOBAL__N_19destruct_EPv (DecodeImage.js:51550) >> _emit_message (DecodeImage.js:48859) >> _examine_app0 (DecodeImage.js:37425) >> _get_interesting_appn (DecodeImage.js:41586) >> _read_markers (DecodeImage.js:37895) >> _consume_markers (DecodeImage.js:44034) >> _jpeg_consume_input (DecodeImage.js:46482) >> _jpeg_read_header (DecodeImage.js:48078) >> __ZN11DecodeImage10initializeEii (DecodeImage.js:51365) >> __ZN10emscripten8internal13MethodInvokerIM11DecodeImageFviiEvPS2_JiiEE6invokeERKS4_S5_ii >> >> (DecodeImage.js:50663) >> dynCall_viiii (DecodeImage.js:51988) >> dynCall_viiii_5 (VM385:2) >> DecodeImage$initialize (VM393:8) >> processJpgArray (loadJpgs.html:28) >> fileReader.onload (loadJpgs.html:99) >> >> >> And the error message that I get is: >> >> cannot zero out thread value for __cxa_get_globals() >> >> >> That's on current incoming with current everything. I think. >> >> At least that's an exciting, interesting error. >> >> - Bruce >> >> >> On Thu, May 28, 2015 at 5:46 PM, Jukka Jylänki <[email protected] >> <javascript:>> wrote: >> >>> You can also try building the code with the "-g -O0" or "-g -O1" linker >>> flags to get a human-editable nonminified version of the code. Try finding >>> the .js code line where it fails, and map that back to the original C code >>> to get more clues. >>> >>> Pure native code often depends on undefined behavior that is not >>> standard C. Two such features are 1) unaligned memory accesses, and 2) >>> calling a function pointer with a mismatching signature. The first is not >>> allowed in C, but in x86 architecture it is safe. The second is likewise >>> not allowed, but the function calling conventions in x86 standard ABI relax >>> this considerably, so both of these go unnoticed in native development. >>> Since JavaScript is hardware-independent, in both cases only the strictest >>> form is allowed so that the code can be executed on a wide variety of >>> platforms. Mismatching function signatures can cause error call stacks like >>> this. If your backtracking leads you to a code line where a function >>> pointer is called, then it suggests that the function pointer signatures of >>> the function declaration and the pointer did not match. See here for one >>> example codebase where such an issue was fixed: >>> https://github.com/juj/emscripten-freetype/commit/5af357ae531632a4ea4991863f4ba77c3366eda2 >>> >>> . >>> >>> It is also possible that the code hits the first issue with unaligned >>> memory accesses somewhere, and goes sideways after that. To debug that >>> issue, try adding the link flag -s SAFE_HEAP=1 to add runtime debug checks >>> to all memory operations. Running in this mode is very slow, but it can >>> help pinpoint to code lines where alignment is violated. >>> >>> 2015-05-28 13:09 GMT+03:00 Björn K. <[email protected] >>> <javascript:>>: >>> >>>> Thank you very much for you hint! I tried that and received the >>>> following output: >>>> >>>> uncaught exception: abort(5) at >>>> jsStackTrace@file:///home/user/emscripten/jpeg-components/ipl-wrapper/emscripten-tests/libjpeg-01/src/DecodeImage.js:4:20414 >>>> >>>> stackTrace@file:///home/user/emscripten/jpeg-components/ipl-wrapper/emscripten-tests/libjpeg-01/src/DecodeImage.js:4:20597 >>>> >>>> abort@file:///home/user/emscripten/jpeg-components/ipl-wrapper/emscripten-tests/libjpeg-01/src/DecodeImage.js:18:29965 >>>> >>>> b5@file:///home/user/emscripten/jpeg-components/ipl-wrapper/emscripten-tests/libjpeg-01/src/DecodeImage.js:11:30821 >>>> >>>> _read_markers@file:///home/user/emscripten/jpeg-components/ipl-wrapper/emscripten-tests/libjpeg-01/src/DecodeImage.js:10:39479 >>>> >>>> _consume_markers@file:///home/user/emscripten/jpeg-components/ipl-wrapper/emscripten-tests/libjpeg-01/src/DecodeImage.js:10:13564 >>>> >>>> _jpeg_consume_input@file:///home/user/emscripten/jpeg-components/ipl-wrapper/emscripten-tests/libjpeg-01/src/DecodeImage.js:10:5778 >>>> >>>> _jpeg_read_header@file:///home/user/emscripten/jpeg-components/ipl-wrapper/emscripten-tests/libjpeg-01/src/DecodeImage.js:10:5127 >>>> __ZN11DecodeImage10initializeEii [DecodeImage::initialize(int, >>>> int)]@file:///home/user/emscripten/jpeg-components/ipl-wrapper/emscripten-tests/libjpeg-01/src/DecodeImage.js:10:969 >>>> __ZN10emscripten8internal13MethodInvokerIM11DecodeImageFviiEvPS2_JiiEE6invokeERKS4_S5_ii >>>> >>>> [emscripten::internal::MethodInvoker<void (DecodeImage::*)(int, int), >>>> void, >>>> DecodeImage*, int, int>::invoke(void (DecodeImage::* const&)(int, int), >>>> DecodeImage*, int, >>>> int)]@file:///home/user/emscripten/jpeg-components/ipl-wrapper/emscripten-tests/libjpeg-01/src/DecodeImage.js:10:3315 >>>> >>>> dynCall_viiii@file:///home/user/emscripten/jpeg-components/ipl-wrapper/emscripten-tests/libjpeg-01/src/DecodeImage.js:11:30524 >>>> dynCall_viiii_5@file:///home/user/emscripten/jpeg-components/ipl-wrapper/emscripten-tests/libjpeg-01/src/DecodeImage.js >>>> >>>> line 4 > Function:2:12 >>>> DecodeImage$initialize@file:///home/user/emscripten/jpeg-components/ipl-wrapper/emscripten-tests/libjpeg-01/src/DecodeImage.js >>>> >>>> line 4 > Function:8:1 >>>> >>>> processJpgArray@file:///home/user/emscripten/jpeg-components/ipl-wrapper/emscripten-tests/libjpeg-01/src/loadJpgs.html:28:9 >>>> >>>> loadJpgFile/fileReader.onload@file:///home/user/emscripten/jpeg-components/ipl-wrapper/emscripten-tests/libjpeg-01/src/loadJpgs.html:99:11 >>>> >>>> >>>> Unfortunately this doesn't help much, since the purely native code runs >>>> flawlessly (what I expect from a component like libjpeg). So I guess there >>>> has to be some emscripten issue with that. >>>> >>>> But I've no clue what's wrong, especially not how to fix that... :/ >>>> >>>> Best regards, >>>> Björn >>>> >>>> >>>> Am Mittwoch, 27. Mai 2015 18:43:26 UTC+2 schrieb jj: >>>>> >>>>> Try building with --profiling-funcs linker flag in addition to that >>>>> -O2. That will give a more readable callstack to allow you to debug the >>>>> issue further. >>>>> >>>>> 2015-05-27 18:49 GMT+03:00 Björn K. <[email protected]>: >>>>> >>>>>> Hi there! >>>>>> >>>>>> I've set up a working sample of a HTML-page which loads JPEG-images >>>>>> via an emscripten-cross-compiled version of libjpeg. >>>>>> >>>>>> Unfortunately it works only when compiling without optimizations. For >>>>>> performance reasons and file size I'd like to compile with -Oz, ideally >>>>>> additionally using closure compiler. But anything beyond >>>>>> optimization-level >>>>>> -O0 just does not work. When decoding any image I get the following >>>>>> callstack: >>>>>> >>>>>> uncaught exception: abort(0) at >>>>>> jsStackTrace@file:///home/user/emscripten/jpeg-components/ipl-wrapper/emscripten-tests/libjpeg-01/src/DecodeImage.js:1:21746 >>>>>> >>>>>> stackTrace@file:///home/user/emscripten/jpeg-components/ipl-wrapper/emscripten-tests/libjpeg-01/src/DecodeImage.js:1:21929 >>>>>> >>>>>> abort@file:///home/user/emscripten/jpeg-components/ipl-wrapper/emscripten-tests/libjpeg-01/src/DecodeImage.js:15:35454 >>>>>> >>>>>> nullFunc_vii@file:///home/user/emscripten/jpeg-components/ipl-wrapper/emscripten-tests/libjpeg-01/src/DecodeImage.js:1:192767 >>>>>> >>>>>> im@file:///home/user/emscripten/jpeg-components/ipl-wrapper/emscripten-tests/libjpeg-01/src/DecodeImage.js:8:33536 >>>>>> >>>>>> he@file:///home/user/emscripten/jpeg-components/ipl-wrapper/emscripten-tests/libjpeg-01/src/DecodeImage.js:5:29651 >>>>>> >>>>>> $d@file:///home/user/emscripten/jpeg-components/ipl-wrapper/emscripten-tests/libjpeg-01/src/DecodeImage.js:5:11423 >>>>>> >>>>>> Qd@file:///home/user/emscripten/jpeg-components/ipl-wrapper/emscripten-tests/libjpeg-01/src/DecodeImage.js:5:4413 >>>>>> >>>>>> Pd@file:///home/user/emscripten/jpeg-components/ipl-wrapper/emscripten-tests/libjpeg-01/src/DecodeImage.js:5:3870 >>>>>> >>>>>> ud@file:///home/user/emscripten/jpeg-components/ipl-wrapper/emscripten-tests/libjpeg-01/src/DecodeImage.js:5:868 >>>>>> >>>>>> Id@file:///home/user/emscripten/jpeg-components/ipl-wrapper/emscripten-tests/libjpeg-01/src/DecodeImage.js:5:2636 >>>>>> >>>>>> pl@file:///home/user/emscripten/jpeg-components/ipl-wrapper/emscripten-tests/libjpeg-01/src/DecodeImage.js:8:31500 >>>>>> dynCall_viiii_5@file:///home/user/emscripten/jpeg-components/ipl-wrapper/emscripten-tests/libjpeg-01/src/DecodeImage.js >>>>>> >>>>>> line 1 > Function:2:12 >>>>>> DecodeImage$initialize@file:///home/user/emscripten/jpeg-components/ipl-wrapper/emscripten-tests/libjpeg-01/src/DecodeImage.js >>>>>> >>>>>> line 1 > Function:8:1 >>>>>> >>>>>> processJpgArray@file:///home/user/emscripten/jpeg-components/ipl-wrapper/emscripten-tests/libjpeg-01/src/loadJpgs.html:28:9 >>>>>> >>>>>> loadJpgFile/fileReader.onload@file:///home/user/emscripten/jpeg-components/ipl-wrapper/emscripten-tests/libjpeg-01/src/loadJpgs.html:99:11 >>>>>> >>>>>> You can find a repository at github at >>>>>> https://github.com/cee-dee/emscripten-tests/issues/3, which explains >>>>>> how to compile the project in detail. >>>>>> >>>>>> Any help is greatly appreciated! >>>>>> >>>>>> Best regards, >>>>>> Björn >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "emscripten-discuss" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "emscripten-discuss" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected] >>>> <javascript:>. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "emscripten-discuss" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected] >>> <javascript:>. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "emscripten-discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
