Jump to content

  • Log In with Google      Sign In   
  • Create Account

Sir Ementaler

Member Since 09 Mar 2013
Offline Last Active Today, 06:45 AM

Posts I've Made

In Topic: Null Pointer Error after application attempts to modify script object handle

23 May 2016 - 11:15 AM

Does your C++ compiler not give you a warning on this function?

void GetPersonInstance(Person *ptr)
    ptr = &person1;

Because it doesn't have any effect, and ptr is a variable that's set but never read. Your problem seems to come from misunderstanding how C++ works rather than AS. You probably heard something about returning values by pointer, but that's not how you do that. In this function, ptr is a local variable of type "pointer to Person". As a local variable, it will be destroyed once it goes out of scope, i.e. when the function returns. Modifying its value is therefore not useful, and certainly doesn't affect anything outside of the function. Now, modifying *ptr could have effect outside of the function, assuming ptr were a valid pointer on entry, however that's probably not what you're trying to achieve.


There are two possible solutions. The one that seems obvious to me is to return the pointer rather than take is as argument:

Person *GetPersonInstance()
    return &person1;

There doesn't seem to be any reason not to do that. If you want to obtain a value rather than provide it, it should seem reasonable that it should be returned by the function rather than taken. The AS function signature in this case should be changed to "Person@ GetPersonInstance()". On the other hand, if you insist on your current syntax, you can always pass the pointer by reference:

void GetPersonInstance(Person *&ptr)
    ptr = &person1;

I wouldn't choose this solution, but it's also available. The AS function signature in this case would be "void GetPersonInstance(Person@ &out)". If I remember how AS works correctly, there's one more issue with doing either of those, and it's that since your object is garbage-collected, you should increase its reference count before returning its handle from a C++ function, by calling


Otherwise you may experience unpleasant behavior.

In Topic: Various unexpected behaviors of AngelScript 2.31.0

09 May 2016 - 05:26 AM

Looks like the "auto foo = null;" crash may still occur when declared in the global scope.

In Topic: Access violation when passing function to generic initialization list.

08 May 2016 - 02:00 PM


In Topic: BlindMindStudios JIT-Compiler and AS 2.3

24 March 2016 - 12:27 PM

I tested the latest revision but unfortunately it didn't solve the issue. However, I noticed that the error doesn't occur for global string instances, so this may be what's preventing you from reproducing it. The smallest piece of code that I can use to reproduce the error is

void main() {
	string a = true ? "a" : "b";

However, if at least one of "a" and "b" is wrapped in an explicit string constructor, the code seems to work correctly. The access violation reliably occurs while executing (rather than compiling) the code. It comes from CopyConstructString in scriptstdstring.cpp, which is called with an invalid reference as the other argument. The reference appears to reliably be to address 0x00000001.


I also investigated the other report I got and determined that it's an unrelated access violation caused by line 3003 of as_jit.cpp, when the code is trying to dereference it->second.jitFunction. The error occurs relatively rarely, after the program runs several scripts. It would appear to me that entries are never removed from the deferredPointers multimap, and thus as the engine releases old functions and allocates new ones, it has an ever increasing chance of allocating one at an address already present among deferredPointers keys, with unexpected consequences.

In Topic: Various unexpected behaviors of AngelScript 2.31.0

23 March 2016 - 12:35 AM

Thanks for explaining; sounds very reasonable. No, I don't need it disabled, given that it's intended to be permitted syntax, possesses well-defined behavior, and has legitimate use cases. That's sufficient to rename it from a bug to a feature in my book.