#Somehow unable to access member in vector.

105 messages · Page 1 of 1 (latest)

copper vigil
#

Hello, so I'm getting this wacky segfault that occurs in a seemingly unrelated part of my program to what I was working on. I ran it with GDB in the commandline and I'm honestly don't have any other tricks up my sleve, I don't know what the callstack implies, and I have no idea what any of it NEEDS to do. I also struggle with figuring out if what I have in the vector is valid. Any ideas for this kind of situation? The "events" are a stack of lambdas, which was the thing I was trying to implement as a temporary solution for something.

int main(){
    UFO_EngineMain ufo;
    ufo.scene_system.start_events.push_back([&](){ufo.scene_system.LoadScene<Scene>("../res/frogatto_jr/example.json"); return true;});
    ufo.Start(1600,800,1,1);
    return 0;
};


void SceneSystem::Start(){
    if(scenes.size() > 0){
        for(auto&& event : start_events) event();
        scenes.back()->OnStart();
    }
}

void
SceneSystem::GotoScene(std::string _scene_name){}

void
SceneSystem::RemoveActiveScene(){}

Scene*
SceneSystem::GetActiveScene(){
    assert(scenes.size() > 0);

    return scenes.back().get();
}

void
SceneSystem::Update(){
    scenes[scenes.size()-1]->Update();
    for(auto&& event : events){
        event();
    }
    events.clear();
    //scenes[scenes.size()-1]->DrawScene();
}
image.png
undone grottoBOT
#

When your question is answered use !solved to mark the question as resolved.

Remember to ask specific questions, provide necessary details, and reduce your question to its simplest form. For tips on how to ask a good question use !howto ask.

copper vigil
#

The scene system exists during the programs entire runtime. The address of UFO_EngineMain ufo; does not change, and I think capturing it should work fine. LoadScene presumably accesses the scene-stack. Start() also does run, but oddly enough a lot of print messages don't appear that should be there

humble shoal
#

is this code getting run in multiple threads?

copper vigil
#

I, personally don't use threads, at least not explicitly or as far as I know

#

But something does make you wonder if I do use threads, right? And what could the reason for that be?

humble shoal
#

is the scenes list empty by any chance?

humble shoal
wild nymph
#

it is, the screenshot shows it is

#

size on the vector returns 0 but then you just index into it any way

#

a priori for this scenes[scenes.size()-1]->Update();

#

or whatever line 28 of scene_system.cpp is

copper vigil
#

it's probably empty then

humble shoal
#

ok cool, yeah, thought that's what the gdb dump was saying in there. so i'm guessing you aren't expecting that to be empty then?

copper vigil
#

Which I have no idea asto why, how do I verify which variable is not valid? I don't see any nullpointer values in the gdb output, nothing really catches my eye at all

humble shoal
#

you should get familiar with a debugger when it comes to this type of stuff btw.. it'll just pause the program if/when it crashes like this so you can inspect the state of things

#

it's trying to index into the array using -1

copper vigil
#

Yeah, I've stared at it over and over and nothing really stands out as mysterious, and I often can'ẗ verify the validity of anything

humble shoal
#

which is probably cast to a size_t, so it's really trying to index into the vector using whatever size_t max is

humble shoal
copper vigil
wild nymph
#

scenes.size() - 1 is already a "size_t" a priori

wild nymph
humble shoal
#

ah, yep, that's right

wild nymph
#

which is kinda not something that outsider can easily help you with

copper vigil
wild nymph
#

indexing an empty vector isn't valid

#

it's your job to ensure that the vector isn't empty if you decide to index it

copper vigil
#

Yes, I know the vector is empty now.

humble shoal
#

but you don't know why it's empty (assuming you're not expecting it to be in this call)

wild nymph
#

so either you check it explicitly, or when you use the debugger you check it isn't empty

#

normally your overall code design/software architecture either never expects the vector to be empty and you can index it, or the vector can be empty there and you have to deal with the empty case

#

those kind of assumptions are generally all over the place

copper vigil
#

Check and use .... what as a cue? I have a pointer I am accessing when trying to push the scene, but how do I know that that pointer is what I think it is?

wild nymph
#

and we as outsider will have a hard time helping you realize those individual bits of assumptions you may or may not have, without a proper understanding of what the code is doing or supposed to be doing

#

well you check how it is created?

#

where did that pointer value come from

#

as for the gdb screenshot, you also have to understand what the various pieces of information are telling you

#

right in the middle of that screenshot there's something fishy going on since the debugger can't access the memory at the address of the return value

#

that's the result of indexing the vector btw

#

so from there you already should suspect that that specific pointer is wrong, and that subsequent operations that depend on that pointer value are likely to fail or produce invalid result

#

so at that point the prime suspect is the index value you used for indexing

#

which leads you back to the vector being empty

copper vigil
#

I'd like to talk about the output, not about how I suck at GDB.

#

Please.

wild nymph
# copper vigil I'd like to talk about the output, not about how I suck at GDB.

I never meant to say "you s.ck at gdb", I said that these are the typical steps you can take to backtrack to the source of the problem
yes the ouput isn't nice to look at, and that's also why people often prefer not to use gdb directly but use something with a nicer interface (which uses gdb as backend)
if for whatever reason you're stuck without such tools and have to use gdb directly as command line it's still nice to be able to understand the output, and yes the tl;dr of what I'm telling is "learn to read and use it"

#

there's no secret recipe or trick to learning to debug, you have to look at the information available to you and interpret it

#

and yes my way of saying thing is dry, that's how typing formal language work, half the time

humble shoal
#

feedback like that is never intended to be an insult, but it really is the magic bullet when it comes to narrowing down issues like this. that's probably why it's reiterated so often in here

wild nymph
#

it's just not in my style to punctuate things with emojis

copper vigil
wild nymph
#

and phrasing complex things without saying something false is also just hard so I try to get to the point as much as possible

#

if that makes you unconformtable best I can offer is let other more english fluent people address your future issues

humble shoal
#

one place to start on making it easier to interpret what's being output is by using the debugger that integrates into the vscode UI itself... so you don't have to interpret the output that looks pretty cryptic if you aren't familiar with, it will just show you the values of every variable in scope at any level of the callstack

copper vigil
#

If I'd go back on track I'd say the pointer is created via the LoadScene function when the LoadScene function is supposed to call some functions of the top scene.

wild nymph
#

I still don't know what pointer value you're talking about

#

I talked about most information that was displayed in the screenshot

#

there are a couple of values there that I guess are pointer values

#

but they are all basically bogus because of the vector being empty

#

if you're talking about a different pointer value you've seen in a different part of your program that has no direct relation with what was in your screenshot, then assessing the validity of that pointer value mostly boils down to keeping track of all the valid pointer values that you've created and put in that container (assuming you have a container), and checking the value you get out the other end is what you expect to have

#

sometimes doing all of that is just not feasible

#

maybe because there are too many pointers generated or for whatever reason

#

at that point there's generally little to say about checking for a pointer being valid or invalid

#

though in your screenshot it's "easy" to tell something is wrong, because the debugger cannot access the memory at the other end of the pointer

copper vigil
wild nymph
#

but if you have corrupted pointer values that point to areas of memory that the debugger can access, sometimes it'll just interpret the memory and it'll be a lot less obvious

humble shoal
#

this is what the debugger integration looks like for vscode... everything you see in the panels surrounding the cpp file is the state shown by the debugger. you can step through your code line by line or scatter breakpoints wherever you want to pause the program (like it is here for the line highlighted in yellow) and inspect everything in scope. from any breakpoint you can also walk up/down the callstack and inspect the state of callers/callees:

image.png
wild nymph
humble shoal
#

hovering over any variable in the editor will also show that tooltip that's drawing in the middle the code window.. the screenshot just didn't capture my mouse cursor

wild nymph
#

and I said "I still don't know what pointer value you're talking about" because I don't know if you mean a specific pointer in the screenshot or code excerpt, or something completely different, or a generic question

wild nymph
#

it's just unspecified, to me, what pointer you mean, because you omitted too much context

#

like, I don't have your screen under my own eyes, so if you say "I have a pointer" I have no clue what pointer you're talking about

copper vigil
#

End of that story.

humble shoal
copper vigil
wild nymph
#

I don't think I said anything along the lines of "read the manual/documentation" in the last dozen of messages I've sent

#

but I'll take this cue to leave it to more adequate people

humble shoal
copper vigil
#

I wanna talk about the output, that's what I sought out to do today.

humble shoal
#

when it comes to stuff like this, no one can really tell you to begin. you're familiar with your entire codebase, but all we've seen when it comes to this crash is the screenshot you posted above... I think that's all it comes down to. there just isn't enough context about the issue to be able to give you any specific advice about this type of thing

copper vigil
humble shoal
#

you still get the output you were looking at in your screenshot if you want that as well

wild nymph
# copper vigil It's more that what you said can be summarised to "like, you aren't um, like, yo...

I've went over the entire screenshot and pointed at the bit you would need to be careful about to interpret the crash
I keep going back to that screenshot because that's the one concrete piece of information about the crash that you've provided, and it also explains the crash, and this was meant as an illustration of what you can pay attention for

for the rest, you asked a semi abstract question so I gave you semi abstract ideas/concepts

wild nymph
#

the only concrete output you've shown, is the screenshot

humble shoal
#

something you'll learn over time is that you should always want to use tooling to it's full potential. not using something because you don't want to is only going to make your life harder when it comes to narrowing down the cause of problems like this one.

copper vigil
#

I'm not getting anywhere with this.

#

I wanna do one thing at a time, that's it.

#

Literally, you don't need to argue for tool B, when I am currently sitting with tool A, I usually get things done when I focus on the thing.

humble shoal
#

even using the screenshot you provided, the info is there, just harder to spot...

image.png
copper vigil
#

I switch my tools when I have time

humble shoal
#

the stuff i showed you is using the same exact tools you're already using in the screenshot, right? or am i missing something?

copper vigil
# humble shoal the stuff i showed you is using the same exact tools you're already using in the...

Let's scrap my entire question and let me explain a thing to you instead. I don't use VSCode because I just have to use GDB in the terminal at this point. There is both a technical component to it, but it's also the case that I will come back to this issue eventually anyway because some things JUST REQUIRE GDB, VSCode can actually do weird things under the hood. I am also in the midst of trying to find a code editor that works better on my system, so it's very exhausting for an autistic person like me to switch environment over and over.

So please just stop exhausting me, don't take this as me biting the hand that feeds me, but rather that I am pleading, please just go with that I wanna use tool A, not tool B, because of 100 reasons we can impossibly discuss within the free time I have left today.

wild nymph
#

I tried to reread the thread, but are you asking for tips/cues as to why the vector is empty when you reach that point? is that what you mean when you say you want to "talk about the output"?

#

because the whole problem with the one screenshot you shared, is the empty vector

#

and as an outsider, it's unclear if that empty state is expected or unexpected

copper vigil
#

I need to go for the moment

humble shoal