1

So I am writing a c++ OpenGl application that should test if two figures layed out with matches are identical. I have written an own class: the "figure" class. This class makes use of the two classes "Line" and "Point". Here you can see my implementation in the figure.h header:

#define SHINT short int

class Point
{
public:
    std::pair<SHINT, SHINT> coord;
    Point()
    {
        coord = std::pair<SHINT, SHINT>{ 0, 0 };
    }
    Point(int x, int y)
    {
        coord = std::pair<SHINT, SHINT>{ (short)x, (short)y };
    };
};

class Line
{
public:
    std::pair<Point, Point> pts;
    Line()
    {
        pts = std::pair<Point, Point>{ Point(), Point() };
    }
    Line(Point p1, Point p2)
    {
        pts = std::pair<Point, Point>{ (Point)p1, (Point)p2 };
    };
};

class Figure
{
public:
    Figure() {};

private:
    std::vector<Line> lines;
    Point p1;
    Point p2;
    char* renderPath = FILEPATH;
public:
    void DrawComponents();
    void Clear();
    void RemoveLine(int index);
    void AddLine();
    void SetWorking(int x, int y, bool segment); //true seg1, false seg2
    
    void Render();
    
};

The implementation of the problematic functions are as follows:


void Figure::AddLine()
{
    Line l1 = Line(p1, p2);
    lines.push_back(l1);
}


void Figure::SetWorking(int x, int y, bool segment)
{
    if (segment)
    {
        p1 = Point(x, y);
    }
    p2 = Point(x, y);
}

I have a fig*, that can be either set to the first figure or to the second Figure. You can do that with the help of an ImGui overlay. If you press your mouse button, a set of function is triggered:

selected->SetWorking(posX, posY, m_Select);     //         
                                                            
            if (m_Select)                                   
                selected->AddLine();

posX and posY are calculated relative to the mouse position and that is working properly. We than call the SetWorking() function on the figure pointer, which again calls a constructor in the Point and Sets the working Point to what posX and Y are. I have to Points that are used in turns. So if I click the first time, the first Point is set, if I press a second time, the second Point is set, and with two Points set, we push a new line into the vector. This alteration is achieved by the "segment" bool int the SetWorking() function. Points are saved as std::pairs<> that hold short ints, and Lines are saved as std::pairs<> that hold two points. But if we land there, an error occurs: "Exception thrown: write access violation. this was 0x14" The error is thrown in the utility file of the c++ STL: (line 292)

pair& operator=(_Identity_t<_Myself&&> _Right) noexcept(
        conjunction_v<is_nothrow_move_assignable<_Ty1>, is_nothrow_move_assignable<_Ty2>>) /* strengthened */ {
        first  = _STD forward<_Ty1>(_Right.first); // <---- here 
        second = _STD forward<_Ty2>(_Right.second);
        return *this;
    }

And honestly, at this point I don't have the slightest clue as of what is going on there. My educated guess is, that something with the std::pair is going wrong, but I am to unskilled with c++ yet, so I don't really now how to solve these kinds of error

  • I suspect the bug is in code not shown. Can you give us just enough code to replicate the error and confirm that the error can be replicated with just the code you give us? – David Schwartz Nov 03 '20 at 21:28
  • `#define SHINT short int` please don't. Use standard names for built-in types. Also recommend using a fixed size integer instead. – bolov Nov 03 '20 at 21:28
  • @DavidSchwartz narrowed the bug via breakpoints down to the two functions: Addline() and SetWorking() – one friendly programmer Nov 03 '20 at 21:30
  • @bolov do you think that working with ints would fix my problems? I will test it right away – one friendly programmer Nov 03 '20 at 21:31
  • 1
    When building an example for Stack Overflow take inspiration from [mre]. Not only will it give us all the information we need to help you, it's also a powerful debugging technique. Odds are very good while winnowing your code down to a MRE you'll spot and fix the bug yourself. – user4581301 Nov 03 '20 at 21:32
  • 3
    @onefriendlyprogrammer Then give us code with just those functions that replicates the error. If you narrowed it down to those functions, that should be easy. But I suspect you'll discover you need a lot more code to do it. (Most likely, those two functions are the *victim* and the bug is elsewhere.) – David Schwartz Nov 03 '20 at 21:33
  • Regarding bolov's comment about fixed size integers, here's [a good documentation page covering them](https://en.cppreference.com/w/cpp/types/integer) – user4581301 Nov 03 '20 at 21:33
  • I took away key parts of my functions in advance while debugging, and found everything was working just right up to the point the constructor of Line or Point are called. I also ran the program with just SetWorking() or AddLine() or without both. The program worked only with neither of the two functions. No matter if I call the constructor of Point or Line, the same exception is thrown in the utility file line 292, which defines the behaviour of the "=" operator of the std::pair. As you can see, in the SetWorking() I set "p2 = Point(x, y);" (you see the = operator). – one friendly programmer Nov 03 '20 at 21:44
  • @onefriendlyprogrammer Great. Then show us the smallest complete code that you can confirm replicates the error. – David Schwartz Nov 03 '20 at 21:45
  • If you start your program with a debugger, you will immediately see what causes the exception. Have you tried using one? – MorningDewd Nov 03 '20 at 21:46
  • No, it has bothy to do with your problem. It's just a bad practice. – bolov Nov 03 '20 at 21:49

1 Answers1

1

"this was 0x14": The error occured in a member function (operator=()) of pair. The pair object that executes operator=() has a value of 0x14 for its this pointer, which is highly unlikely to be correct.

Usually this means that the pair is member of an object with this pointer == nullptr, and the pair object is located at offset 0x14 relative to the class.

I suspect that selected is a nullpointer and the assignment of p1 results in the access violation.

MorningDewd
  • 501
  • 2
  • 6
  • @MornigDewd that sounds exceptionally reasonable. I am currently at work and cannot try to fix that but I think that your guess I right. Didn't think of something like that, but it makes perfect sense! Thank you so much! I will try to solve this problem later and will than close this thread! Thank you so much! – one friendly programmer Nov 03 '20 at 21:48