view::transform with auto segfaults

[bobkocisko]

Is it a bug that replacing the 'int' with 'auto' in the following example creates a segfault?

   static std::vector<std::pair<int, std::vector<int>>> ii {
     {0, {0}},
     {0, {0, 7}},
     {1, {0, 4}},
   };

   // This this code runs fine:
   auto rng = view::concat(
     view::repeat_n(0, 16),
     view::repeat_n(1, 7),
     view::repeat_n(2, 4)
   ) |
     view::transform([](int i) { return view::all(ii[i].second); });

   // But if we change it to this, it segfaults (notice the 'auto' in the transform lambda)
   auto rng = view::concat(
     view::repeat_n(0, 16),
     view::repeat_n(1, 7),
     view::repeat_n(2, 4)
   ) |
     view::transform([](auto i) { return view::all(ii[i].second); });

  std::cout << rng << std::endl;

[ericniebler]

What segfaults? The compiler? Which one? I would say it's certainly a compiler bug, and not a bug in range-v3. A compiler should never segfault regardless of what code is thrown at it.

[ericniebler]

If you mean the code compiled and segfaults at runtime, then that would certainly be an interesting bug in range-v3.

[bobkocisko]

A segfault at runtime:

Process finished with exit code 139 (interrupted by signal 11: SIGSEGV)

[ericniebler]

What compiler?

[bobkocisko]

gcc (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609

fwiw: CMake 3.12.2

[bobkocisko]

I installed gcc straight from the default apt repo, running on an Ubuntu derivative called elementaryOs

[ericniebler]

According to wandbox you're right. That code crashes with gcc-5.4. For every gcc version more recent than gcc-6.1, the code runs fine though. (See https://wandbox.org/permlink/CQhVzhZ3zHKUr5dZ.) Even clang as ancient as 3.6 compiles and runs it just fine.

I'm inclined to write this off as a bug in the polymorphic lambda implementation of old gcc versions.

[bobkocisko]

Ok I'm glad you were able to see it via wandbox.