I'll let the stacktrace speak for itself, but this is a pretty odd bug. I am using an outdated version of Angelscript, so I will see if using the latest SVN ffixes it, but here:

Program received signal SIGSEGV, Segmentation fault.
0x6523ecc3 in asCContext::ExecuteNext (this=0xbbd0fd8) at C:\mengin\src\deps\angelscript\as_context.cpp:1292
1292 switch( *(asBYTE*)l_bc )
(gdb) bt fuull
No symbol "fuull" in current context.
(gdb) bt full
#0 0x6523ecc3 in asCContext::ExecuteNext (this=0xbbd0fd8) at C:\mengin\src\deps\angelscript\as_context.cpp:1292
l_bc = 0x0
l_sp = 0xbb2ba54
l_fp = 0xbb2ba54
#1 0x6523e424 in asCContext::Execute (this=0xbbd0fd8) at C:\mengin\src\deps\angelscript\as_context.cpp:985
No locals.
#2 0x651289b7 in _fu121___ZSt4cout (this=0xbbbc6e8, act=0xba73608, collider=0xbbbc6e8) at C:\mengin\src\core\CollisionObject.cpp:346
r = 0
info = 0xc14d440
#3 0x651283e9 in Irre::CollisionObject::RunCollisionDetection (this=0xbbbc6e8) at C:\mengin\src\core\CollisionObject.cpp:308
pt = @0xb580d90
p = 0
manifold = 0xb580d8c
objA = 0xbb29050
cooA = 0xbb28ab8
other_object = 0xbb28ab8
objB = 0xbbbc8c0
cooB = 0xbbbc6e8
directionSign = 1
j = 0
pair = @0x8b6e270
collisionPair = 0xbbf3b60
i = 0
manifoldArray = {m_allocator = {<No data fields>}, m_size = 1, m_capacity = 1, m_data = 0x8b7fc40, m_ownsMemory = true}
pairArray = @0xbba58f4
numPairs = 4
#4 0x651136a8 in Irre::ObjectManager::PropagateOnCollide (this=0xbb23f48, a1=0x0, co1=0x0, a2=0x0, co2=0x0) at C:\mengin\src\core\ObjectManager.cpp:446
obj = 0xbbbc6e8
i = {<boost::iterator<std::forward_iterator_tag, std::pair<int const, Irre::Object*>, int, std::pair<int const, Irre::Object*>*, std::pair<int const, Irre::Object*>&>> = {<boost::detail::iterator_base<std::forward_iterator_tag, std::pair<int const, Irre::Object*>, int, std::pair<int const, Irre::Object*>*, std::pair<int const, Irre::Object*>&>> = {<std::iterator<std::forward_iterator_tag, std::pair<int const, Irre::Object*>, int, std::pair<int const, Irre::Object*>*, std::pair<int const,
Irre::Object*>&>> = {<No data fields>}, <No data fields>}, <No data fields>}, base_ = {bucket_ = 0xba83b3c, node_ = 0xbbd5008}}
#5 0x65123fcf in Irre::WorldTickCallback (world=0x8b5aed0, timestep=0.00416666688) at C:\mengin\src\physics\World.cpp:478
No locals.
#6 0x651fcb9f in btDiscreteDynamicsWorld::internalSingleStepSimulation (this=0x8b5aed0, timeStep=0.00416666688)
at C:\mengin\src\deps\bullet\BulletDynamics\Dynamics\btDiscreteDynamicsWorld.cpp:355
__profile = {<No data fields>}
dispatchInfo = @0x8b5aeec
#7 0x651fc9b1 in btDiscreteDynamicsWorld::stepSimulation (this=0x8b5aed0, timeStep=62, maxSubSteps=15, fixedTimeStep=0.00416666688)
at C:\mengin\src\deps\bullet\BulletDynamics\Dynamics\btDiscreteDynamicsWorld.cpp:290
i = 0
clampedSimulationSteps = 15
__profile = {<No data fields>}
numSimulationSubSteps = 14880
#8 0x651252ab in Irre::World::Update (this=0x8b4f478, delta=46) at C:\mengin\src\physics\World.cpp:566
elapsed = 62
substeps = 15
timestep = 0.0620000027
#9 0x651320a2 in Irre::Stage::Update (this=0x8aeacd0, time_delta=46) at C:\mengin\src\core\stage\StageAngel.cpp:409
No locals.
#10 0x6510eb3b in Irre::LogicThread::SingleThreadRun (this=0x8aefd50) at C:\mengin\src\core\LogicThread.cpp:86
time_delta = 46
#11 0x651067cc in Irre::Engine::Run (this=0x4d9808) at C:\mengin\src\core\Engine.cpp:105
tid = 0
#12 0x65106980 in Irre::Run () at C:\mengin\src\core\Engine.cpp:165
No locals.
#13 0x004013e5 in main (ac=1, av=0x4d44f0) at C:\mengin\src\runner\main.cpp:11
No locals.

More on this as I find out.

Just updated my code to the latest SVN of the library and it is crashing in the same spot. I'll try to get more info.

   I believe I have figured out the problem. When I was setting the object while preparing to call, I was setting the wrong object, which given the design of my collision detection system is easy enough to do. I need to learn to keep my objects straight. This could lead to a bit of an enhancement. I find it odd that the program decided to crash there and not let me know "This object doesn't have that function stupid." 

I'd have to agree with you. It's always better if the library can give a proper error message.

I didn't quite understand how you got this error though. You called the ctx->SetObject() with the wrong object? But was the wrong object still a script object? Otherwise it would be difficult for the library to validate it.

The wrong object was an asIScriptObject, yes. It was just the wrong asIScriptObject. It's a bit hard to explain without studying my system, but I have been refactoring CollisionObjects to have their own core script objects to perform event callbacks on, where before they would obtain the callback object and call OnCollision on the core object of an Actor thwy would be attached to.