Search code examples
c++linuxsegmentation-faultvalgrindunordered-map

Google Filament rendering engine segmentation fault


I am attempting to compile the sample app "Suzanne" from the Filament library, by statically linking to the appropriate libraries. Both the sample app and libraries have been compiled from the latest source code. I am compiling with clang++.

However, when I compile and run the app, I get a segmentation fault. valgrind gives the following output:

==31202== Process terminating with default action of signal 11 (SIGSEGV)
==31202==  Access not within mapped region at address 0x8
==31202==    at 0x46A485: size (__hash_table:809)
==31202==    by 0x46A485: bucket_count (__hash_table:1197)
==31202==    by 0x46A485: std::__1::__hash_iterator<std::__1::__hash_node<std::__1::__hash_value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, void*>*> std::__1::__hash_table<std::__1::__hash_value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::__unordered_map_hasher<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::__hash_value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::hash<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, true>, std::__1::__unordered_map_equal<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::__hash_value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::equal_to<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, true>, std::__1::allocator<std::__1::__hash_value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > >::find<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) (__hash_table:2334)
==31202==    by 0x461CA7: find (unordered_map:1205)
==31202==    by 0x461CA7: image::KtxBundle::getMetadata(char const*, unsigned long*) const (KtxBundle.cpp:274)
==31202==    by 0x463D26: image::KtxBundle::getSphericalHarmonics(filament::math::details::TVec3<float>*) (KtxBundle.cpp:290)
==31202==    by 0x420E69: IBL::loadFromKtx(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) (in /home/joel/Documents/KiwiTest/filament-suzanne/out/suzanne)
==31202==    by 0x42162D: IBL::loadFromDirectory(utils::Path const&) (in /home/joel/Documents/KiwiTest/filament-suzanne/out/suzanne)
==31202==    by 0x41A41C: FilamentApp::loadIBL(Config const&) (in /home/joel/Documents/KiwiTest/filament-suzanne/out/suzanne)
==31202==    by 0x415D19: FilamentApp::run(Config const&, std::__1::function<void (filament::Engine*, filament::View*, filament::Scene*)>, std::__1::function<void (filament::Engine*, filament::View*, filament::Scene*)>, std::__1::function<void (filament::Engine*, filament::View*)>, std::__1::function<void (filament::Engine*, filament::View*, filament::Scene*, filament::Renderer*)>, std::__1::function<void (filament::Engine*, filament::View*, filament::Scene*, filament::Renderer*)>, unsigned long, unsigned long) (in /home/joel/Documents/KiwiTest/filament-suzanne/out/suzanne)
==31202==    by 0x40A1D4: main (in /home/joel/Documents/KiwiTest/filament-suzanne/out/suzanne)
==31202==  If you believe this happened as a result of a stack
==31202==  overflow in your program's main thread (unlikely but
==31202==  possible), you can try to increase the size of the
==31202==  main thread stack using the --main-stacksize= flag.
==31202==  The main thread stack size used in this run was 8388608.

Any thoughts on what could be causing this and what I could do to resolve this would be greatly appreciated.


Solution

  • Error resolved (courtesy of TheGoldKnight23): The header files in use were outdated.