ASSERTIONS=2 for more info, but doesn't give more info !!!!!

[wolfviking0]

Hi, I have an other trouble with other sample, when I try to launch it I have an error, and the console say try with  ASSERTIONS=2 for more info. Of course I follow the advice, and when I add it the code it's working but I don't have more info. What does that mean ??? I was thinking the ASSERTION who give me more details about the trouble in my code.

Tony

Console output :

--------------------

[Error] Invalid function pointer called with signature 'vi'. 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)

printErr (settings.js, line 173)

nullFunc_vi (toys_mandelgpu.js, line 14656)

b2 (toys_mandelgpu.js, line 294863)

__ZNSt3__114__shared_count16__release_sharedEv (toys_mandelgpu.js, line 234385)

__ZNSt3__16localeD2Ev (toys_mandelgpu.js, line 278014)

__ZNSt3__18ios_baseD2Ev (toys_mandelgpu.js, line 237812)

__ZNSt3__19basic_iosIcNS_11char_traitsIcEEED2Ev (toys_mandelgpu.js, line 237844)

__ZNSt3__118basic_stringstreamIcNS_11char_traitsIcEENS_9allocatorIcEEED1Ev (toys_mandelgpu.js, line 42586)

dynCall_vi (toys_mandelgpu.js, line 294704)

invoke_vi (toys_mandelgpu.js, line 14722)

__ZN6OCLToy16AllocOCLBufferWOEjPPN2cl6BufferEjRKNSt3__112basic_stringIcNS4_11char_traitsIcEENS4_9allocatorIcEEEE (toys_mandelgpu.js, line 90510)

dynCall_viiiii (toys_mandelgpu.js, line 294697)

invoke_viiiii (toys_mandelgpu.js, line 14713)

__ZN9MandelGPU15AllocateBuffersEv (toys_mandelgpu.js, line 41735)

__ZN9MandelGPU11SetUpOpenCLEv (toys_mandelgpu.js, line 19155)

__ZN9MandelGPU6RunToyEv (toys_mandelgpu.js, line 18953)

dynCall_ii (toys_mandelgpu.js, line 294725)

invoke_ii (toys_mandelgpu.js, line 14749)

__ZN6OCLToy3RunEiPPc (toys_mandelgpu.js, line 77137)

dynCall_iiii (toys_mandelgpu.js, line 294739)

invoke_iiii (toys_mandelgpu.js, line 14767)

_main (toys_mandelgpu.js, line 15756)

callMain (toys_mandelgpu.js, line 296767)

doRun (toys_mandelgpu.js, line 296824)

(anonymous function) (toys_mandelgpu.js, line 296836)

[Error] Build with ASSERTIONS=2 for more info.

printErr (settings.js, line 173)

nullFunc_vi (toys_mandelgpu.js, line 14656)

b2 (toys_mandelgpu.js, line 294863)

__ZNSt3__114__shared_count16__release_sharedEv (toys_mandelgpu.js, line 234385)

__ZNSt3__16localeD2Ev (toys_mandelgpu.js, line 278014)

__ZNSt3__18ios_baseD2Ev (toys_mandelgpu.js, line 237812)

__ZNSt3__19basic_iosIcNS_11char_traitsIcEEED2Ev (toys_mandelgpu.js, line 237844)

__ZNSt3__118basic_stringstreamIcNS_11char_traitsIcEENS_9allocatorIcEEED1Ev (toys_mandelgpu.js, line 42586)

dynCall_vi (toys_mandelgpu.js, line 294704)

invoke_vi (toys_mandelgpu.js, line 14722)

__ZN6OCLToy16AllocOCLBufferWOEjPPN2cl6BufferEjRKNSt3__112basic_stringIcNS4_11char_traitsIcEENS4_9allocatorIcEEEE (toys_mandelgpu.js, line 90510)

dynCall_viiiii (toys_mandelgpu.js, line 294697)

invoke_viiiii (toys_mandelgpu.js, line 14713)

__ZN9MandelGPU15AllocateBuffersEv (toys_mandelgpu.js, line 41735)

__ZN9MandelGPU11SetUpOpenCLEv (toys_mandelgpu.js, line 19155)

__ZN9MandelGPU6RunToyEv (toys_mandelgpu.js, line 18953)

dynCall_ii (toys_mandelgpu.js, line 294725)

invoke_ii (toys_mandelgpu.js, line 14749)

__ZN6OCLToy3RunEiPPc (toys_mandelgpu.js, line 77137)

dynCall_iiii (toys_mandelgpu.js, line 294739)

invoke_iiii (toys_mandelgpu.js, line 14767)

_main (toys_mandelgpu.js, line 15756)

callMain (toys_mandelgpu.js, line 296767)

doRun (toys_mandelgpu.js, line 296824)

(anonymous function) (toys_mandelgpu.js, line 296836)

[Jukka Jylänki]

That kind of error occurs when a function pointer is called and the pointer does not point to a valid function of correct signature. If I understand this correctly, it looks like the function AllocOCLBuffer ends up doing a function pointer call to delete a std::string or a std::stringstream, but the function pointer is bogus, and the runtime aborts. Try investigating from the callstack that where in C++ code the crash occurs in. What does that corresponding C++ code look like? It could be that the application is calling a virtual function when the object  vtable is busted, or something similar.

--
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 emscripten-disc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alon Zakai]

If it still says "Build with ASSERTIONS=2 for more info." then that build does not have ASSERTIONS=2 in it. Perhaps try a small testcase to see how the flag should affect things. See `other.test_implicit_func` and `other.test_dangerous_func_cast`.

- Alon