I'm using the Pro edition but as you said, it shouldn't make a difference in terms of compiled code.

I'm using the statically linked version of AS so it should be using the application's heap. I'm also compiling with no optimisations.

I've yet to register the line callback. I'll try that out and see if I can pinpoint the problem with more accuracy.

I set up a line callback function but it didn't give me any more information - it simply triggered whenever I invoked a script function. I did try placing breakpoints on the wrapper functions and Point class methods however, and those seem to indicate to a temporary variable getting deleted - the references of the input arguments and the return argument all had their references > 0 at the time the rogue pointer deletion occured so it appears to be a copy of the arguments or the result that AS is trying to delete.

Does the express edition offer link time code generation? If not, that would be a large difference in code generation.

Yes, the express edition supports link time code generation.

SharkBait, you may actually want to verify that option. Perhaps turning it on or off affects the results of your application?

Link Time Code Generation was not enabled (Default). I tried the other options but I couldn't even compile as I am not using code profiling.

Anyway, AS 2.5.0 worked fine with VS 2005 with the compiler/linker configuration unchanged.

But nevermined, I just figured out a solution! You did in fact hint at it when you asked me if I was running AS in a DLL. Although I was and am still running AS statically within the same executable I actually found out that the alloc and free functions used by AS where somehow different from those used by the main exe.. or at least, the 'delete' operation had an implementation incompatible with that of 'free' used by AS.

So I used the engine method SetCommonObjectMemoryFunctions through my wrapper API and passed on pointers to 'malloc' and 'free' as seen from my exe's scope, and it worked! :)

Coincidentally, I recall asking for this functionality a while back.. although what I had in mind was the possiblity of allowing the user to replace the standard functions with more performant versions or with tracing built in. Ironically, this also turned out as a solution to my problem!

Thanks for your assistance ( and for implementing that function :) )


[Edited by - SharkBait on April 29, 2006 7:54:30 AM]

I'm happy that you were able to solve the problem. :D

ahh, i did not know that function was there. That is good news as I too have had those problems when using a DLL. Objects new'd w/ .exe version and deleted with .DLL function always crashed me.

Which is exactly why I added that possibility. :)

You can do it on a per-object level as well by registering the asBEHAVE_ALLOC and asBEHAVE_FREE behaviours. This can be useful for those objects that use a different memory manager, for example a memory pool.

Hmm, as far as I know AngelScript is working on Mac OS X with AS_MAX_PORTABILITY on. It could be that the latest changes has broken that (though I hope not).

What is the size of size_t on your platform? And what is the size of long? If the size of long and int is different then that is why you're getting segmentation error.

If you're compiling for a 64 bit platform you also need to define the AS_64BIT_PTR.

I'll create another typedef to use instead of size_t, because it seems that it is not always correct on the various compilers out there.

Unfortunately I haven't heard more from the developer that said he was working on the PPC port, so I can't say anything about when it will be available. I just received a MIPS port (PS2, PSP) though from Manu Evans, and he said that he might give PPC a try as well. I'm hopeful that it will be available soon, but since I'm not the one doing it I cannot give any guarantees.

Regards,
Andreas

The 64bit support is new and not heavily tested (since I do not have a 64bit system myself). I'll need your help in order to try to find whatever bug it might be.

First, I need to know what the script you're using looks like.

Would it be possible for you to write a small test app that reproduces the problem with a minimal of other stuff, so that I can try to figure out what's going on?