[Bf-committers] 2.36 status...
Ton Roosendaal
ton at blender.org
Tue Dec 14 13:35:58 CET 2004
Hi,
I am not familiar with asserts, but i regular compile debug builds with
"-g", I suppose you mean something else? Do we have to compile solid
with asserts on or so? (N00b alert!)
Remaining issues;
- why did it run OK at your machine? Any clue we can learn from?
- Gino likely won't respond - did he ever for you? - so maybe we could
check if DT_Count can better become signed int everywhere?
- is, with this patch, the engine OK for release for you?
Thanks,
-Ton-
On 14 Dec, 2004, at 10:30, Kester Maddock wrote:
> 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.
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
>
>
------------------------------------------------------------------------
--
Ton Roosendaal Blender Foundation ton at blender.org
http://www.blender.org
More information about the Bf-committers
mailing list