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.
