GDB LArSoft Tutorial

////////////////////////////////////////////////////////////////////////
// Class:       GDBTest
// Plugin Type: analyzer (art v2_09_06)
// File:        GDBTest_module.cc
//
// Generated at Tue May  8 18:41:01 2018 by Justin Hugon using cetskelgen
// from cetlib version v3_01_03.
////////////////////////////////////////////////////////////////////////

#include "art/Framework/Core/EDAnalyzer.h"
#include "art/Framework/Core/ModuleMacros.h"
#include "art/Framework/Principal/Event.h"
#include "art/Framework/Principal/Handle.h"
#include "art/Framework/Principal/Run.h"
#include "art/Framework/Principal/SubRun.h"
#include "canvas/Utilities/InputTag.h"
#include "fhiclcpp/ParameterSet.h"
#include "messagefacility/MessageLogger/MessageLogger.h"

namespace test {
  class GDBTest;
}


class test::GDBTest : public art::EDAnalyzer {
public:
  explicit GDBTest(fhicl::ParameterSet const & p);
  // The compiler-generated destructor is fine for non-base
  // classes without bare pointers or other resource use.

  // Plugins should not be copied or assigned.
  GDBTest(GDBTest const &) = delete;
  GDBTest(GDBTest &&) = delete;
  GDBTest & operator = (GDBTest const &) = delete;
  GDBTest & operator = (GDBTest &&) = delete;

  // Required functions.
  void analyze(art::Event const & e) override;

private:

  // Declare member data here.

};


test::GDBTest::GDBTest(fhicl::ParameterSet const & p)
  :
  EDAnalyzer(p)  // ,
 // More initializers here.
{}

void test::GDBTest::analyze(art::Event const & e)
{
  // Implementation of required member function here.
  int x[10];
  for (size_t i=0; i < 2000; i++)
  {
    x[i*10000] = i;
  }

  mf::LogInfo("GDBTest") << "x[-9999999]: " << x[-99999999];
}

DEFINE_ART_MODULE(test::GDBTest)

lar -c gdbTest.fcl -S /dune/app/users/jhugon/tutorial/dunetpc_v06_69_00/fullpathnames_mcc10_protodune_beam_p2GeV_cosmics_3ms_sce_mcc10.0.txt

Now, GDB can help us find what caused the segfault. First startup GDB with the lar executable:

So, it tells you that a Segmentation fault happened, and then told you where it happened--on line 59 of GDBTest_module.cc. We are also still in GDB so can debug further. This is much more helpful than without GDB. Don\'t worry about the Missing separate debuginfos..., that just means that those libraries don\'t have debugging info, so you won\'t be able to debug code inside of them.

The backtrace command, bt, will show you the list of functions called to get to where the program execution is now all the way up to the main() function. Mine looks like this:

All of the stuff in between the GDBTest class method call and main() is larsoft stuff that we probably don\'t care about (unless you found a bug in it, but it is probably a bug in your code instead). The `frame` command will tell you which function (stack frame) GDB is inside right now, and frame i will take you to the i\'th frame from the backtrace. You can print out the code around your current frame with list, and type list again to go forward in the code. list - goes backwards in the code. This way you don\'t have to exit GDB to inspect the code where an error is.

Since the program crashed, we can\'t inspect the value of variables in the code, so we\'re not sure what value of i caused the crash on line 59. We can tell GDB to stop at whenever a segfault happens and let us look around by running:

You can also print out the value of variables with p. It\'s pretty easy to print out local variables in the scope of your current stack frame.

Hugonweb | GDB LArSoft Tutorial