Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Jason Goepel

Member Since 15 May 2013
Offline Last Active Jun 30 2015 08:25 AM

Topics I've Started

Calling Convention Bug?

27 April 2015 - 12:26 PM

I've discovered some sort of bug in the "CallSystemFunction."  I have only encountered it in x64 Windows builds (Visual Studio 2013).

 

It looks like the code cleaning up the arguments incorrectly attempts to clean up the return variable.  To trigger the bug, I register a class with a destructor and register a function that returns an instance of this object and takes one as an argument, so that the argument needs to be cleaned up.  The cleanup code will then attempt to free the argument, but it will mistakenly pass a pointer to the return variable to be freed.  This pointer is not a valid heap pointer, so there is a crash.

 

The attached file can be added to the test project to demonstrate the problem.

 

The fix may be something as simple as adding the following code the the cleanup section, but I am not familiar enough with how the AngelScript compiler manages its memory and sets up function calls to make that judgement.

 

as_callfunc.cpp(820)

// Clean up arguments
const asUINT cleanCount = sysFunc->cleanArgs.GetLength();
if( cleanCount )
{
    args = context->m_regs.stackPointer;
    if( callConv >= ICC_THISCALL )
        args += AS_PTR_SIZE;

    //** New code to address bug **/
    if( descr->DoesReturnOnStack() )
        args += AS_PTR_SIZE;

    asSSystemFunctionInterface::SClean *clean = sysFunc->cleanArgs.AddressOf();
    for( asUINT n = 0; n < cleanCount; n++, clean++ )
    {
        void **addr = (void**)&args[clean->off];
        if( clean->op == 0 )
        {
            if( *addr != 0 )
            {
                engine->CallObjectMethod(*addr, clean->ot->beh.release);
                *addr = 0;
            }
        }
        else 
        {
            asASSERT( clean->op == 1 || clean->op == 2 );
            asASSERT( *addr );

            if( clean->op == 2 )
                engine->CallObjectMethod(*addr, clean->ot->beh.destruct);
            
            engine->CallFree(*addr);
        }
    }
}

"Null pointer access" putting object type in exception info

01 April 2015 - 12:20 PM

In an effort to provide more helpful error messages to my script writers, I have been looking for a way to make "null pointer access" a little more descriptive.  Most of my script writers are technical people, but their programming training is very thin.  "Null pointer access" pretty much doesn't mean anything to them.  I am hoping to provide something like "Instance of CDemoClass has not been properly initialized" or something, potentially varying based on the object.

 

I don't have a good way of accomplishing this within the Exception callback framework, short of analyzing the line where an exception occurred.  I have been considering adding object information, when it exists, to the context (something like m_exceptionObjectType) which could be read during the exception callback.

 

I know there are many instances where the object type is not readily available (like asBC_CHKREF), so I was wondering if you had any thoughts about this.

 

Thanks


Multithreading - Creating a Module

04 November 2014 - 03:25 PM

I know that building multiple modules in separate threads that belong to the same engine is "thread safe" because the engine will only allow building one module at a time.

 

It looks like if multiple threads are calling "asIScriptEngine::GetModule" and "asIScriptModule::Discard" at the same time they calling code should acquire a lock first, since these functions modify an array belonging to the engine.  I'm not suggesting that the functions themselves should block.  I am just confirming that the burden is on the application to synchronize those module-related activities.

// Create a new script module
asAcquireExclusiveLock();
asIScriptModule *mod = engine->GetModule("module", asGM_ALWAYS_CREATE);
asReleaseExclusiveLock();

// Load and add the script sections to the module
string script;
LoadScriptFile("script.as", script);
mod->AddScriptSection("script.as", script.c_str());

// Build the module
int r = mod->Build();

// ... Do something with the module

asAcquireExclusiveLock();
mod->Discard();
asReleaseExclusiveLock();

C++ Compiler Warning

28 October 2014 - 08:00 AM

This is not a big deal, but I build my projects with Microsoft's VC++ compiler, and I set the warning level to 4.  When I build AngelScript targeting the x64 platform I get the following compiler warning.

 

>source\as_builder.cpp(240): warning C4267: 'initializing' : conversion from 'size_t' to 'AngelScript::asUINT', possible loss of data

 

I would recommend an explicit cast here so that the warning does not appear.

 

asUINT numTempl = (asUINT)engine->templateInstanceTypes.GetLength();

 


Implicit Convert Math Bug

09 October 2014 - 12:08 PM

I think there's a bug somewhere when compiling math operators and using implicit conversion functions.  The following test fails.

int x = 1;
class A
{
    int val;
    A(int x)
    {
        val = x;
    }
    int opImplConv()
    {
        return val;
    }
}

A myA(5);

void main()
{
    assert(myA + (x + 1) == myA + x + 1);
}

The error seems to be that after the CALLINTF instruction for A::opImplConv there is no following CpyRtoV4.  The error is in the bytecode generated on the left side of the comparison.

 

Also, if the global declaration of "x" is removed and a local declaration of "x" is added to the main function the bug is gone.

 


PARTNERS