Thanks, that was it (ran the wrong history command). That running command should have given a hint :)
Can I ask what people here use for debugging/editor? I'm settling on vscode, and using bare gdb for debugging. cheers, Maarten Op ma 15 jun. 2020 om 16:47 schreef Francois Saint-Jacques < fsaintjacq...@gmail.com>: > As Antoine said, debug mode is probably the most important > configuration. You can also try the `relwithdebinfo` if you're trying > to debug the optimized code. I'd also add the following: > > 1. Building out of conda provides a much better integration with gdb > and the system's libstdc++ due to the pretty printers for common > container classes. This may download a lot of source packages. > 2. Sometimes, you have to let the test run and fail once, then set a > breakpoint such that gdb will get the sources by looking at the loaded > shared libraries. > > François > > On Mon, Jun 15, 2020 at 10:38 AM Antoine Pitrou <anto...@python.org> > wrote: > > > > > > Hi Maarten, > > > > You should build in debug mode, i.e. pass -DCMAKE_BUILD_TYPE=Debug > > > > Regards > > > > Antoine. > > > > > > Le 15/06/2020 à 16:35, Maarten Breddels a écrit : > > > Hi all, > > > > > > I have trouble getting gdb working with a test suite. > > > Running e.g.: > > > $ gdb ./release/arrow-compute-scalar-test > > > I can't set a breakpoint on e.g. > > > arrow::compute::internal::TransformAsciiUpper in > > > arrow/compute/kernels/scalar_string.cc. > > > Tab completion on arrow::compute::int<tab> give no tab completion, > because > > > I assume this is not exported (although the symbol is visible using nm > > > path/to/libarrow.so.100). > > > Is there an easy (or hard?) way to get a breakpoint there, and what > might > > > be the reason I cannot put a breakpoint at TransformAsciiUpper. > > > > > > cheers, > > > > > > Maarten Breddels > > > >
