I don't think this has anything to do with threads after looking at it a
bit after dinner.
The call stack looks clearly incorrect ... there's no reason for
emit_message out of libjpeg to be calling __ZN10__cxxabiv112_GLOBAL__N_
19destruct_EPv
If we look at the code in emit_message in JS, the line involved is:
FUNCTION_TABLE_vi[HEAP32[(HEAP32[i6 >> 2] | 0) + 8 >> 2] & 63](HEAP32[i4
>> 2] | 0);
The line from C is:
(*err->output_message) (cinfo);
I really don't think this should be invoking what it is.
So ... looking a bit further, we see this function in your C++ code:
void DecodeImage::prepare(int sizeOfData, emscripten::val callback)
{
// create and assign libjpegs internal data structure
struct jpeg_error_mgr jerr;
struct jpeg_decompress_struct cinfo;
this->cinfo = cinfo;
this->sizeOfData = sizeOfData;
// Allocate Memory
this->imageData = (uint8_t*) malloc(this->sizeOfData);
callback(emscripten::memory_view<uint8_t>(this->sizeOfData,
this->imageData));
// Allocate and initialize JPEG decompression object
this->cinfo.err = jpeg_std_error(&jerr);
// Now we can initialize the JPEG decompression object.
jpeg_create_decompress(&this->cinfo);
// Specify data source
jpeg_mem_src(&this->cinfo, (unsigned char*)(this->imageData),
this->sizeOfData);
}
That's creating jerr on the stack, saving a pointer to it, and then
exiting, leaving that pointer invalid. You need to fix your memory
allocation and then all will probably be well.
Cheers,
- Bruce
On Thu, May 28, 2015 at 7:45 PM, Jukka Jylänki <[email protected]> wrote:
> 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.
>
--
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.
