beautiful output drops off unexpectdly

[cruisercoder]

I have a strange issue where I see the beautiful output at the start of the trace and then it stops for the rest of the trace starting at (#24 below). The line numbers are present but the surrounding lines and the coloring are not. I don't know if this has something to do with gtest or how it's getting channeled through some standard library calls.

#25 | Source "/opt/rh/devtoolset-10/root/usr/include/c++/10/bits/std_function.h", line 291, in __invoke_r<int, int (*&)(int, char**), int, char**>
    |   289:       _M_invoke(const _Any_data& __functor, _ArgTypes&&... __args)
    |   290:       {
    | > 291: 	return std::__invoke_r<_Res>(*_Base::_M_get_pointer(__functor),
    |   292: 				     std::forward<_ArgTypes>(__args)...);
    |   293:       }
    | Source "/opt/rh/devtoolset-10/root/usr/include/c++/10/bits/invoke.h", line 113, in __invoke_impl<int, int (*&)(int, char**), int, char**>
    |   111: 					std::forward<_Args>(__args)...);
    |   112:       else
    | > 113: 	return std::__invoke_impl<__type>(__tag{},
    |   114: 					  std::forward<_Callable>(__fn),
    |   115: 					  std::forward<_Args>(__args)...);
      Source "/opt/rh/devtoolset-10/root/usr/include/c++/10/bits/invoke.h", line 60, in _M_invoke [0x50f3e3]
         57:   template<typename _Res, typename _Fn, typename... _Args>
         58:     constexpr _Res
         59:     __invoke_impl(__invoke_other, _Fn&& __f, _Args&&... __args)
      >  60:     { return std::forward<_Fn>(__f)(std::forward<_Args>(__args)...); }
         61:
         62:   template<typename _Res, typename _MemFun, typename _Tp, typename... _Args>
         63:     constexpr _Res
#24 | Source "../../util/gtest/utest/GTestMain.cc", line 8, in RUN_ALL_TESTS
      Source "../../third_party/gcc/10.2.1/gtest/1.12.1/include/gtest/gtest.h", line 2293, in gTestMain [0x50f2b4]
#23   Object "/home/erik/src/interpreta/out/debug/lib/libgtest.so.1.12.1", at 0x7fc9c268ddb1, in testing::UnitTest::Run()

[bombela]

It most likely fails to open the source files with relative path. You must run your binary with a "current working directory" that matches the relative paths. Another option is to configure your build system to include absolute paths to the source code.

The trace #⁠23 doesn't include source file information. That is why only the Object information are printed out.

[cruisercoder]

Yes that is it. Everything works as expected when I run the binary from the same directory it was compiled in. I'm checking to see if absolute paths are possible with the GN build tool that we use.

Is there any runtime mechanism, like a source directory, that could be specified to reference the source from a specified directory? It might make a nice enhancement for build tools that naturally want to use relative paths.

[bombela]

There is no such mechanism. But feel free to fork and adapt it to your needs. The Printer uses the filename from the debug info verbatim. You could add some logic in there to probe multiple locations. Based on some environment variables if you wish to do so.

[cruisercoder]

I was able to create my own Printer where I can use a source directory to adjust for the path. In my case, I'm using information from argc[0] to determine what the path should be so that there is no need for additional parameters (environment variables or otherwise). I have to replicate all of the formatting in backward::Printer but a bigger issue is that SignalHandling is hardwired backward::Printer so I will have to lift that class too for signal based traces.

There is an interesting response to my related question on the GN dev list.

https://groups.google.com/a/chromium.org/g/gn-dev/c/DwpCMMivOb8