crash, linux 64-bit gcc

crash, linux 64-bit gcc

I get crashes when trying to run the samples or the simple code in the documentation. Is this library ready for testing?

Andrew

6 posts / 0 nouveau(x)
Dernière contribution
Reportez-vous à notre Notice d'optimisation pour plus d'informations sur les choix et l'optimisation des performances dans les produits logiciels Intel.

Hi Andrew,

Please provide more details about the crash. For example, error messages, GCC version, OS verstion,CPU type, and the command line used to compile and link the program. In addition, you can set the environment variable (ARBB_VERBOSE=1) and run it again. This will display a lot more helpful information related to the execution.

Thanks,
Zhang

Here is the program:

#include
#include

using namespace arbb;

// Define a function using Intel ArBB types.
void my_function(f32& result, f32 a, f32 b)
{
result = a + b;
}

int main()
{
// Declare some scalar variables.
f32 x = 1.0f;
f32 y = 2.0f;
f32 z;

// Compile and execute the function using Intel Array Building Blocks.
call(my_function)(z, x, y);

// Print out the value of z after the function execution.
fprintf(stderr, "%f\n", value(z));

return 0;
}

And the verbose output:

>> ArBB FE: System Starts up !
>> ArBB GC: the heap is being created !
>> ArBB GC: the heap is allocated, reserve size = 1073741824 bytes !
>> ArBB GC: the heap is allocated, allocated size = 134217728 bytes !
>> ArBB GC: the separated scalar heap is allocated, allocated size = 16777216 byte !
>> ArBB HLO: Disabled Opt:dsfusion block accurate_fp invDemote fusemap aggressive_memopt dump_cpp recursive_call accessor scalarize_map
terminate called after throwing an instance of 'arbb_1::internal_error'
what(): Internal error: CTE_ILLEGAL_MEMORY_OPERAND ILLEGAL_MEM_OP: Access the illegal memory address => Accessing not mapped address [0x230] at IP[0x7fa51049c8b0] IP[0x7fa51049c8b0]
>> Ct EMU: Emulation library initialization finished. Function table size: 99496Abort (core dumped)

Core stack trace:

#0 0x00007fa50daa9a75 in *__GI_raise (sig=)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x00007fa50daad5c0 in *__GI_abort () at abort.c:92
#2 0x00007fa50e35f8e5 in __gnu_cxx::__verbose_terminate_handler() ()
from /usr/lib/libstdc++.so.6
#3 0x00007fa50e35dd16 in ?? () from /usr/lib/libstdc++.so.6
#4 0x00007fa50e35dd43 in std::terminate() () from /usr/lib/libstdc++.so.6
#5 0x00007fa50e35de3e in __cxa_throw () from /usr/lib/libstdc++.so.6
#6 0x00000000004035a3 in ~throw_on_error_details (this=0x7fff8e9b71c0,
__in_chrg=)
at /home/andrew/intel/arbb/1.0.0.008/include/arbb/cpp/detail/error_details.hpp:54
#7 0x00000000004039bc in arbb_1::detail::function::begin (this=
0x7fff8e9b7340, is_remote=false)
at /home/andrew/intel/arbb/1.0.0.008/include/arbb/cpp/detail/function_impl.hpp:44
#8 0x0000000000408ce7 in arbb_1::closure&, arbb_1::scalar<(arbb_scalar_type_t)8>, arbb_1::scalar<(arbb_scalar_type_t)8>)> arbb_1::capture&, arbb_1::scalar<(arbb_scalar_type_t)8>, arbb_1::scalar<(arbb_scalar_type_t)8> >(void (*)(arbb_1::scalar<(arbb_scalar_type_t)8>&, arbb_1::scalar<(arbb_scalar_type_t)8>, arbb_1::scalar<(arbb_scalar_type_t)8>)) (cpp_function=
0x402aa4 &, arbb_1::scalar<(arbb_scalar_type_t)8>, arbb_1::scalar<(arbb_scalar_type_t)8>)>)
at /home/andrew/intel/arbb/1.0.0.008/include/arbb/cpp/detail/capture_template.hpp:89
#9 0x0000000000406bae in arbb_1::closure&, arbb_1::scalar<(arbb_scalar_type_t)8>, arbb_1::scalar<(arbb_scalar_type_t)8>)> arbb_1::call&, arbb_1::scalar<(arbb_scalar_type_t)8>, arbb_1::scalar<(arbb_scalar_type_t)8> >(void (*)(arbb_1::scalar<(arbb_scalar_type_t)8>&, arbb_1::scalar<(arbb_scalar_type_t)8>, arbb_1::scalar<(arbb_scalar_type_t)8>)) (cpp_function=
0x402aa4 &, arbb_1::scalar<(arbb_scalar_type_t)8>, arbb_1::scalar<(arbb_scalar_type_t)8>)>)
at /home/andrew/intel/arbb/1.0.0.008/include/arbb/cpp/detail/call_template.hpp:62
#10 0x0000000000402b80 in main () at test.cpp:52

Andrew,

Thanks for providing your code and the verbose output. I could not reproduce the problem using your code. However, I did get something similar by changing the environment a bit. I guess the the problem is probably related to how you define the ARBB_OPT_LEVEL environment variable.

ARBB_OPT_LEVEL dictates the level of optimization that ArBB performs at run time. ARBB_OPT_LEVEL can only take one of the 3 values: O0(oh-zero), O2(oh-two), and O3(oh-three). If you set ARBB_OPT_LEVEL to anything else, for example, if you have ARBB_OPT_LEVEL=2, then you will get undefined behavior because '2' is not a valid value for this environment variable. The ARBB_OPT_LEVEL and other ArBB environment variables are well documented in the User Guide. Please refer to "Appendix A: Environment Variables".

Please try to unset ARBB_OPT_LEVEL (it will take the default value which is O2), or set it to O0, O2, or O3. If the problem still persists then we need to dig deeper in your system. Please consider:

  1. Clean up all ArBB related environment variables. Then, execute the "set_env" script in the tools directory. Suppose the installation directory for ArBB is $ARBB_ROOT and suppose you are using bash, then

    > source $ARBB_ROOT/tools/set_env.sh

  2. Check the LD_LIBRARY_PATH environment variable. Does it contain the correct path to ArBB's runtime library?
  3. Check how the loader resolve shared library dependencies. Try to execute the command:

    > ldd ./your_exe

Let us know if this resolves your issue. Thanks for your interests in Intel ArBB!

Best,
Zhang

You are right, setting ARBB_OPT_LEVEL to "O2" rather than "2" fixes the crash. It would probably be a good idea for it not to crash otherwise people will think it is broken (and ideally accept numerical values without the O).

Frame #5 in the stack trace tells us that an exception is thrown
that isn't caught. In general you'll want to have try/catch around arbb
code because the C++ frontend can throw exceptions (arbb::exception).

Connectez-vous pour laisser un commentaire.