I see this sort of error pretty regularly in C libraries I pull in, and
it's always been from lazy ABI usage in C functions used as callbacks or
pluggable functions (like C++ vtables done manually in a struct with
function pointers).
Looks something like this:
typedef void (*callbackType)(int firstParam, int secondParam);
void myCoolCallback(int firstParam) {
// some clever programmer noticed they didn't use secondParam in this
function,
// so just left it off to avoid getting 'unused parameter' warnings
doSomethingWith(firstParam);
}
// some clever programmer might even typecast it when putting it in the
var/struct
callbackType aCallback = (callbackType)myCoolCallback;
// The actual call site always passes the parameters, as the pointer
definition requires
aCallback(aFirstParam, aSecondParam);
There is indeed no compiler option you can use to magically fix it -- you
need to find the offending function declaration and fix either the function
definition or the pointer type definition & call site so they match...
If it's an open-source library (or proprietary third-party library you've
licensed), be sure to send a patch back to the authors so the next person
using it under emscripten won't encounter the same bug!
-- brion
On Wed, Sep 2, 2015 at 7:01 AM, Jukka Jylänki <[email protected]> wrote:
> Optimizations should not add any pointer cast problems, so we don't have a
> set of flags to remove the problems. It is possible that it is a bug in
> Emscripten compiler, in which case reducing it down to a small test case
> can help. Alternatively the code has a bug that it e.g. smashes a vtable or
> similar, and ends up calling a bogus pointer; or the code depends on the
> relaxed native x86 ABI where certain types of function pointer casts are ok
> even though the C standard considers them undefined behavior. Emscripten
> follows the C standard more strictly in this aspect compared to native.
>
> 2015-09-02 10:54 GMT+03:00 Dmitry Grechka <[email protected]>:
>
>> But why I get this problem even with EMULATE_FUNCTION_POINTER_CASTS=1 and
>> ALIASING_FUNCTION_POINTERS=0?
>>
>> What optimization should I disable (or what set of options should I
>> enable) to avoid all these pointer casts problems?
>>
>>
>>
>> On Monday, 31 August 2015 18:55:25 UTC+3, Alon Zakai wrote:
>>>
>>> This can mostly be detected only at runtime. As the error message
>>> indicates, the two main causes are deferencing a null pointer and casting
>>> the type of a function pointer to something wrong before calling it. For
>>> the latter, while we could in theory note at compile time all casts of
>>> function pointer types, LLVM inserts a lot of such casts that are actually
>>> ok, but would seem as dangerous as a truly incorrect cast. But clang can
>>> warn about some specifically dangerous types of casts, which as mentioned
>>> in the message can be turned on with -Werror.
>>>
>>>
>>> On Mon, Aug 31, 2015 at 8:47 AM, Dmitry Grechka <[email protected]>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I run the emscripten compiled code (with -Werror -g3 -s
>>>> EMULATE_FUNCTION_POINTER_CASTS=1 -s DEMANGLE_SUPPORT=1 -s ASSERTIONS=2) and
>>>> get
>>>>
>>>> Invalid function pointer '0' called with signature 'vii'. Perhaps this
>>>> is an invalid value (e.g. caused by calling a virtual method on a NULL
>>>> pointer)? Or calling a function with an incorrect type, which will fail?
>>>> (it is worth building your source files with -Werror (warnings are errors),
>>>> as warnings can indicate undefined behavior which can cause this)
>>>> Z3shell.js:160:7
>>>> This pointer might make sense in another type signature: vi: 0 viid:
>>>> 0 viii: 0 v: 0 viiii: 0 viiiii: 0 viiiid: 0 viiiiii: 0 viiiiiii: 0
>>>> viiiiiiii: 0 viiiiiiiii: 0 viiiiiiiiii: 0 viiiiiiiiiii: 0
>>>> viiiiiiiiiiii: 0 viiiiiiiiiiiii: 0 viiiiiiiiiiiiiii: 0 ii: 0 iii: 0
>>>> dii: 0 iid: 0 i: 0 id: 0 iiii: 0 diid: 0 diii: 0 diiid: 0 iiiid: 0
>>>> iiiii: 0 iiiiii: 0 iiiiid: 0 iiiiiid: 0 iiiiiii: 0 iiiiiiii: 0
>>>> iiiiiiiii: 0 iiiiiiiiii: 0 iiiiiiiiiiii: 0 iiiiiiiiiiiiii: 0
>>>>
>>>> uncaught exception: *abort(0)* at jsStackTrace@
>>>> https://home.dgrechka.net/z3/static_srinked_g3o3alGrowthDemangle/Z3shell.js:1187:13
>>>> stackTrace@
>>>> https://home.dgrechka.net/z3/static_srinked_g3o3alGrowthDemangle/Z3shell.js:1204:22
>>>> *abort*@
>>>> https://home.dgrechka.net/z3/static_srinked_g3o3alGrowthDemangle/Z3shell.js:8918328:44
>>>> *nullFunc*_vii@
>>>> https://home.dgrechka.net/z3/static_srinked_g3o3alGrowthDemangle/Z3shell.js:6586:1993
>>>> *b20809*@
>>>> https://home.dgrechka.net/z3/static_srinked_g3o3alGrowthDemangle/Z3shell.js:8599707:2
>>>> __ZN3smt7context11relevant_ehEP4expr [smt::context::relevant_eh(expr*)]@
>>>> https://home.dgrechka.net/z3/static_srinked_g3o3alGrowthDemangle/Z3shell.js:2341531:2
>>>> __ZN3smt24relevancy_propagator_imp16mark_as_relevantEP4expr
>>>> [smt::relevancy_propagator_imp::mark_as_relevant(expr*)]@
>>>> https://home.dgrechka.net/z3/static_srinked_g3o3alGrowthDemangle/Z3shell.js:2324332:5
>>>> __ZN3smt24relevancy_propagator_imp21propagate_relevant_orEP3app
>>>> [smt::relevancy_propagator_imp::propagate_relevant_or(app*)]@
>>>> https://home.dgrechka.net/z3/static_srinked_g3o3alGrowthDemangle/Z3shell.js:2473876:4
>>>> __ZN3smt15or_relevancy_ehclERNS_20relevancy_propagatorE
>>>> [smt::or_relevancy_eh::operator()(smt::relevancy_propagator&)]@
>>>> https://home.dgrechka.net/z3/static_srinked_g3o3alGrowthDemangle/Z3shell.js:3240091:2
>>>>
>>>>
>>>> As I understand this looks like a function pointer issue.
>>>>
>>>> Is there any way to get these kind of messages at compile time?
>>>>
>>>> Regards,
>>>> Dmitry.
>>>>
>>>> --
>>>> 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.
