Segmentation Fault when using Sparks in Command-Based

Technical C/C++
1

This year, our team is using 5 Talons and 3 Sparks. When using the Sparks with a command based program, the program builds and deploys successfully, but when accessing the driver’s station, it says “No Robot Code.” In the debugger built into Eclipse, it says there is a segmentation fault and gives two memory addresses. Commenting out any code that references the Sparks allows the code to run magnificently, minus three of our motors.

In an iterative robot project that we use to test logic and motors, the Sparks work beautifully.

Any ideas?

In the command based, these are the ways we have defined the Sparks, all return the same segmentation fault.

//In the header file for a subsystem
Spark* motor = new Spark(9);
Spark motor{9};
Spark* motor; //Then say motor = new Spark(9); in the .cpp file


//In the subsystem's .cpp file
motor -> Set (1.0);
motor.Set(1.0); //depending on whether we define it as a reference or pointer, of course.
2

A) It is unclear to me which of the code snips you actually use. You can’t use all of them simultaneously - the compiler would not like that.
B) I don’t know what the {} notation is intended to be in Spark motor{9} - that is illegal in my estimation.
C) It is almost guaranteed that you are using a pointer before it has been properly initialized (new’d).

More information and/or actual code snips would be very helpful. BTW - usually the debugger will trap/break/stop literally at the location in the code where you’ve used the uninitialized pointer. Might you also provide a screen shot of the debugger when it breaks?

Thanks,
bob

3

That’s list initialization

4

We’ve tried all of those, at different times, all with the same result. The code is on a different laptop, I’ll have the other programming guy upload it in a bit.

As for the {} notation, we’ve tried both with {9} and (9), both with the same result.

We just tried to create a fresh Command-Based, with nothing but one subsystem, including one Spark, and an empty Robot.cpp, but the instant we included the subsystem in Robot.cpp, it crashed. I’ll upload code and debugger screenshots in a bit.

5

From what I’ve seen in other people’s code, I think I initialize things a bit differently… but, here’s how I would do it.

I make an InitHardware method to initialize hardware instead of doing all my initialization at comment number 1 because I ran into an issue with drivetrain initialization order, and running it in a method seemed to fix it.

.h


#ifndef Intake_H
#define Intake_H

#include <Commands/Subsystem.h>
#include "WPILib.h"

class Intake : public Subsystem {
private:
	void InitHardware();
	**std::shared_ptr<Spark> IntakeMtr;**

public:
	Intake();
	virtual ~Intake();
	void InitDefaultCommand();
	void Manual(double speed);
};

#endif  // Intake_H

.cpp


#include "Intake.h"
#include "WPILib.h"

Intake::Intake() :
		Subsystem("ExampleSubsystem") {
        //comment number 1
	InitHardware();
}
Intake::~Intake() {
}
void Intake::InitHardware() {
	**IntakeMtr.reset(new Spark(5));**
	IntakeMtr->SetInverted(false);
}
void Intake::InitDefaultCommand() {
	SetDefaultCommand(new IntakeControl(false));
}
void Intake::Manual(double speed) {
	IntakeMtr->Set(speed);
}