[Bf-committers] 2.36 status...
Kester Maddock
Christopher.Maddock.1 at uni.massey.ac.nz
Tue Dec 14 10:30:36 CET 2004
Hi Jacques,
That is what the assert is supposed to check for - I guess no one compiles
debug builds.
If this works for most people, commit it and send it to Gino for help.
Kester
On Monday 15 November 2004 16:10, Jacques Beaurain wrote:
> Hi,
>
> Tried it over here on Windows XP (Visual Studio build) and managed to
> crash using #2006 instructions. The call stack is below for those that
> knows the game engine a bit better than I do (I don't at all, but would
> like to). It is kind of hard to figure out what went wrong (although the
> routine does look a bit unsafe to me; also explained below). I stop in
> the SumoPhysicsController destructor a couple of times after hitting
> escape and then crash here because I am inside a member function of an
> invalid BP_Endpoint object.
>
> blender.exe!BP_Endpoint::getType() Line 69 + 0x3 bytes C++
> blender.exe!BP_EndpointList::stab(const BP_Endpoint & pos={...},
> BP_ProxyList & proxies={...}) Line 44 + 0x8 bytes C++
> blender.exe!BP_EndpointList::range(const BP_Endpoint & min={...},
> const BP_Endpoint & max={...}, unsigned short & first=7, unsigned short
> & last=62, BP_ProxyList & proxies={...}) Line 86 + 0x10 bytes C++
> blender.exe!BP_EndpointList::removeInterval(unsigned short first=7,
> unsigned short last=62, BP_ProxyList & proxies={...}) Line 155 C++
> blender.exe!BP_Proxy::remove(BP_ProxyList & proxies={...}) Line 63
> + 0x37 bytes C++
> blender.exe!BP_Scene::destroyProxy(BP_Proxy * proxy=0x04dd0648)
> Line 55 C++
> blender.exe!BP_DestroyProxy(BP_SceneHandle__ * scene=0x0367e398,
> BP_ProxyHandle__ * proxy=0x04dd0648) Line 56 C++
> blender.exe!DT_Scene::removeObject(DT_Object & object={...}) Line
> 129 + 0x17 bytes C++
> blender.exe!DT_RemoveObject(DT_SceneHandle__ * scene=0x0465d3d0,
> DT_ObjectHandle__ * object=0x04dd0518) Line 310 C++
> blender.exe!SM_Scene::remove(SM_Object & object={...}) Line 150 +
> 0x14 bytes C++
> blender.exe!SumoPhysicsController::~SumoPhysicsController() Line
> 71 C++
> blender.exe!KX_SumoPhysicsController::~KX_SumoPhysicsController()
> Line 217 + 0x20 bytes C++
> blender.exe!KX_SumoPhysicsController::`scalar deleting
> destructor'() + 0x14 bytes C++
> blender.exe!SG_IObject::~SG_IObject() Line 165 + 0x27 bytes C++
> blender.exe!SG_Spatial::~SG_Spatial() Line 91 + 0x24 bytes C++
> blender.exe!SG_Node::~SG_Node() Line 66 + 0x1d bytes C++
> blender.exe!SG_Node::`scalar deleting destructor'() + 0x14
> bytes C++
> blender.exe!KX_Scene::RemoveNodeDestructObject(SG_IObject *
> node=0x035c4208, CValue * gameobj=0x03670958) Line 357 + 0x20 bytes C++
> blender.exe!KX_SceneDestructionFunc(SG_IObject * node=0x035c4208,
> void * gameobj=0x03670958, void * scene=0x0466ff78) Line 91 C++
> blender.exe!SG_IObject::ActivateDestructionCallback() Line 129 +
> 0x1a bytes C++
> blender.exe!SG_Node::Destruct() Line 128 C++
> blender.exe!KX_Scene::RemoveObject(CValue * gameobj=0x03670958)
> Line 644 C++
> blender.exe!KX_Scene::~KX_Scene() Line 174 C++
> blender.exe!KX_Scene::`scalar deleting destructor'() + 0x14
> bytes C++
> blender.exe!KX_KetsjiEngine::StopEngine() Line 836 + 0x21 bytes
> C++ blender.exe!StartKetsjiShell(ScrArea * area=0x046956dc, char *
> scenename=0x046a00c6, Main * maggie=0x046899bc, int
> always_use_expand_framing=1) Line 335 C++
> blender.exe!start_game() Line 473 + 0x1b bytes C
> blender.exe!do_view3d_buttons(short event=152) Line 3570 C
> blender.exe!do_headerbuttons(short event=152) Line 2072 + 0x15
> bytes C
> blender.exe!scrarea_dispatch_header_events(ScrArea *
> sa=0x04693634) Line 488 + 0xa bytes C
> blender.exe!screen_dispatch_events() Line 963 + 0x9 bytes C
> blender.exe!screenmain() Line 1216 C
> blender.exe!main(int argc=1, unsigned char * * argv=0x01082da0)
> Line 604 C
> blender.exe!mainCRTStartup() Line 283 + 0x12 bytes C
> kernel32.dll!7c816d4f()
> kernel32.dll!7c8399f3()
>
> Looking at BP_EndpointList::stab, it i (unsigned short) has been
> decremented from 0 and now points to an invalid location (65535) in the
> endpoint list. However count is still 1 and the loop continued which
> caused the crash. With limited knowledge and time to investigate this at
> the moment a quick fix seems to just do what I did in the patch
> attached, I compiled with it and it seemed to resolve the problem, but I
> did not try the other issues though. I did not look into this because of
> time constraints right now and with my limited knowledge I expect that
> something elsewhere is wrong, but hopefully someone can find this
> information useful.
>
> Cheers,
> Jacques
>
> BTW, the game seems to start okay, but then the screen goes grey after I
> move around a bit (fall through the floor?) and when I hit escape the
> abort happens.
>
> Ton Roosendaal wrote:
> > Hi,
> >
> > Went with Kester today over engine status. He advised to release,
> > since for him the engine runs better than ever. :)
> >
> > The unsolved issue is still why we get crashes... the version running
> > at Kester's survives bug #2006 and the conveyorbelt.blend without
> > issues. All other tests done until now give crashes for it in release
> > candidates built for Linux, OSX and Windows.
> >
> > Kester tried both building with scons and make, both run fine. CVS is
> > on same level, no files forgotten to commit, no weird options for
> > compiling. In short, a mystery still.
> >
> > If people have time to help, try to collect clues. Like is Solid
> > really compiled OK? Is the intern/moto/ really OK? Full clean
> > recompile done? No cvs sticky tags sneaked in?
> >
> > Kester; had no time to ask (darn timezones!) but can you upload your
> > binary build?
> >
> > Clueless in Amsterdam,
> >
> > -Ton-
> >
> > ------------------------------------------------------------------------
> > --
> > Ton Roosendaal Blender Foundation ton at blender.org
> > http://www.blender.org
> >
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at projects.blender.org
> > http://projects.blender.org/mailman/listinfo/bf-committers
--
The rule on staying alive as a program manager is to give 'em a number or
give 'em a date, but never give 'em both at once.
More information about the Bf-committers
mailing list