Advertisement

Debugger and var in scope

Started by May 06, 2022 08:35 AM
15 comments, last by Alexander Orefkov 2 years, 6 months ago

In my project I creating debug adapter for Visual Studio Code for AngelScript, and sometime have problem.

When I inspecting some variable, context->IsVarInScope return true for it varibale, but context->GetAddressOfVar return nullptr for it, if I do not set returnAddressOfUnitializedObjects to true, because DetermineLiveObjects tell that variable not initialized. But if I use GetAddressOfVar with true for unitialized vars, I got valid address and alive object.

I have not yet been able to identify an obvious pattern, but in my case it was a variable of my internal type “string”, declared inside the loop “for”:

        for (...) {
            string name;
            ... some processing of name
            script.addNamedItem(name, obj, global);
        }

That's odd. It could be a bug introduced in the WIP as the returnAddressOfUnitializedObjects is newly added to allow serializing the context stack, so it should be used to get the address even if the object is not yet initialized.

I'll try to reproduce this.

I assume you use the default scriptstdstring add-on?

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

Advertisement

No, I use my own string implementation, but it nothing special - simple value object with constructor, destructor and so on.

I believe the situation when you got a null pointer in GetAddressOfVar even though IsVarInScope return true is on the line where the string variable is declared (hence in scope) but not yet initialized. This situation is valid, as GetAddressOfVar will not return a pointer to the object if it is not yet initialized (unless you set returnAddressOfUnitializedObjects to true).

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

There is piece of my code:

array<array<any>@> connectedAddins;
...
many work for build connectedAddins and collect a lot of other information, realy a lot of local variables
...
for (uint k = 0, km = connectedAddins.length; k < km; k++) {
    array<any>@ a = connectedAddins[k];
    IUnknown@ obj;
    string name;
    bool global;
    a[0].retrieve(@obj);
    a[1].retrieve(name);
    a[2].retrieve(global);
    script.addNamedItem(name, obj, global); // << there is breakpoint and check variable 'name'
}

And when I got adsress of name as unitialized var - it valid and containt right string, in my native method addNamedItem I receive right info.

OK. I'll investigate this.

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

Advertisement

I've encountered the same issue here, with app registered value types that don't have a ctor registered.

If I register a ctor for the type, it's fine.

Thanks for adding that info. I think it might be a different case, but I'll investigate both with and without ctor.

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

I've fixed the scenario reported by @mghughes in rev 2776.

Alexander, I have not been able to reproduce the scenario you reported. You can see the test case I implemented in the revision 2776 (see link above). Perhaps you can take a look at it to see if I'm doing something different than you do. You might also try out the fix, although I don't really think it is the same case as mghughes reported, there is a chance it fixes your case too.

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

Thank you, just to confirm that has fixed our issue.

Still quite new to Angelscript, but it's great to see how active the on-going development is.

Mark

This topic is closed to new replies.

Advertisement