With those flags, I did not refer to the callstack, but the actual code in the generated file. Running with --profiling-funcs will give you minified code, but only readable symbols. With -O2 -g2 you will get nonminified code, which will enable you to edit the .js file directly to try to locate what the code looks like in the .js file in a text editor. You will need to do some JS code debugging to dig into the cause, to pinpoint the root of the issue. Chances are it is because of 1) or 2) I posted above, or as Bruce's findings suggest, it might also be something to do with a threading related construct, in which case like I mentioned already, you should try to find a compilation flag in libjpeg so that it avoids calling to threading constructs, or edit the libjpeg code yourself to remove calls to threading constructs.
2015-05-28 15:38 GMT+03:00 Björn K. <[email protected]>: > 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]>: >> >>> 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]> 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]>: >>>> >>>>> 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]. >>>>> 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. >>>> >>> >>> -- >>> 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]. > 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.
