ProjectsWhat's NewDownloadsCommunitySupportCompany
Forum Index » S.T.A.L.K.E.R.: Shadow of Chernobyl Forum » Mod discussion
Tracing a C stack overflow

« Previous 10 events | 1 2 | All Messages
Posted by/on
Question/AnswerMake Newest Up Sort by Descending
  17:43:42  12 March 2012
profilee-mailreply Message URLTo the Top
Llynix
(Novice)
 
On forum: 12/19/2011
Messages: 47

---QUOTATION---
>> - The main function of iteration inventory
>> - (Linked to the function update () in file bind_stalker.script)

Really?

You are iterating over your inventory in your actor_binder:update() loop?

<*brain 'splodes*>


---END QUOTATION---



Well, I'm not iterating, since it's not my script. Why would that be baffling? Could you please explain?

I have also discovered that it's not the Artefact Detector script that causes the C Stack Overflow. Or perhaps there's something else that does. I'm going to try and play a previous version of my mod without any all.spawn and gulag changes from AMK 1.4 - I'll see if it works.

Still, the "unknown command: nil" thing is pretty puzzling and probably not entirely beneficial to the game's stability. I'll check the suggestions posted here so far - if anyone's got other ideas, I'll be grateful.
  19:32:49  12 March 2012
profilee-mailreply Message URLTo the Top
Llynix
(Novice)
 
On forum: 12/19/2011
Messages: 47
nope. still getting this:


Expression    : fatal error
Function      : CScriptEngine::lua_error
File          : E:\stalker\sources\trunk\xr_3da\xrGame\script_engine.cpp
Line          : 73
Description   : <no expression>
Arguments     : LUA error: ...hadow of chernobyl\gamedata\scripts\state_mgr.script:193: C stack overflow



is the info about state_mgr.script any help?
  19:38:42  12 March 2012
profilee-mailreply Message URLTo the Top
Llynix
(Novice)
 
On forum: 12/19/2011
Messages: 47
perhaps my log file will help?

[link]http://www.mediafire.com/?rab63quzhnnnmtq[/link]
  20:21:57  12 March 2012
profilee-mailreply Message URLTo the Top
Lijenstina
Doom metal in the shade of the flying radiators
(Resident)

 

 
On forum: 07/23/2005
Messages: 1902
Those c-stack log errors are usually useless. It just points out to the straw that broke the camel's back not what filled it up in the first place.
  12:38:55  13 March 2012
profilee-mailreply Message URLTo the Top
Llynix
(Novice)
 
On forum: 12/19/2011
Messages: 47
Perhaps this is a silly idea, but I'm getting desperate. One of the things I've changed lately was the "NPC aiming sideways fix" from here:

https://www.gsc-game.com/index.php?t=community&s=forums&s_game_type=xr&thm_page=167&thm_id=20798&sec_id=16&page=1

could this possibly lead to a C-Stack Overflow?
  21:37:53  13 March 2012
profilee-mailreply Message URLTo the Top
Meltac
messing with code
(Resident)

 

 
On forum: 01/21/2010
Messages: 1519

---QUOTATION---
Perhaps this is a silly idea, but I'm getting desperate. One of the things I've changed lately was the "NPC aiming sideways fix" from here:

https://www.gsc-game.com/index.php?t=community&s=forums&s_game_type=xr&thm_page=167&thm_id=20798&sec_id=16&page=1

could this possibly lead to a C-Stack Overflow?
---END QUOTATION---



Most most most probably not.
  12:55:42  13 April 2012
profilee-mailreply Message URLTo the Top
NatVac
Senior Resident
 

 
On forum: 06/15/2007
Messages: 4302

---QUOTATION---
>> You are iterating over your inventory in your actor_binder:update() loop?

Well, I'm not iterating, since it's not my script. Why would that be baffling? Could you please explain?
---END QUOTATION---


Sure, if you don't mind your eyes bleeding.

I was engaging in hyperbole for effect; obviously my brain did not explode. The calm, even tone of my follow-up statement was intended to serve as contrast to the over-the-top reaction.

If I said, "She took the train to Glasgow," I would not intend the hearer to understand that she picked up a train and carried it overland to a city far away. (Unless I gave you a context that it was a toy, a model train, and her son in Glasgow wanted it.)

No, I've employed a common programming vernacular expression, and my attempts to explain it will likely only confuse most folks who already understand its intent.

What is meant: If you use code provided by another in your game, it is under your control. The code itself is not iterating over anything, but the game engine that you started is executing those instructions that you put there. You are responsible for that code execution, hence "you are" initiating an action that is "iterating over your inventory in your actor_binder:update() loop".

I'm not doing it, the writer of the code is not doing it in this context. You are doing it. Your reply reminded me of that secret in the game where the guy claims it wasn't his fault that his friend died, but that of the damned bullet.

If you don't have any runaway loops, like recursive loops that don't meet any exit conditions, the most common cause of C stack overflow is too much processing done in the same execution context. One example is too much spawning.

Let's say you have 20000 bytes (characters) of stack space. For the sake of discussion assume it takes 1010 bytes per NPC spawned. If you spawn 19, you're fine. Once you try to put the 20th NPC into the game, the stack limit is exceeded and the game exits with the error. The secret would be to only spawn 10 NPCs at a time, so the stack limit is never exceeded.

In your case, I'm wary of doing anything that is time-intensive in the update() loop, like the iteration over all the game objects. It can make the loop take a long time to complete, longer than the time interval at which it is supposed to be repeating. You might get the "I Love Lucy" assembly line fiasco with Lucy and Ethel, where the line of items moves faster than they can handle.

Yet my personal experience is that you can do lots of stuff in the update() loop and the calls will just queue up. Your game will get very laggy. But the stack is still limited, and doing the kind of object manipulation "you" are doing (examples: creating/releasing separators, re-initializing tables) might just use up a lot of stack. It could be that the garbage collector never gets a chance to run to free up the no-longer-used objects "you"'ve released.

And there are a lot of other entities that are updated by the scheduler; there are other possible contributors to the crash.

You might try reducing objects_per_update in config\alife.ltx as a test. Or add debugging statements to find out what is being done when.

Use Lijenstina's suggestion to isolate the culprit if you haven't already.
 
Each word should be at least 3 characters long.
Search:    
Search conditions:    - spaces as AND    - spaces as OR   
 
Forum Index » S.T.A.L.K.E.R.: Shadow of Chernobyl Forum » Mod discussion
 

All short dates are in Month-Day-Year format.


 

Copyright © 1995-2022 GSC Game World. All rights reserved.
This site is best viewed in Internet Explorer 4.xx and up and Javascript enabled. Webmaster.
Opera Software products are not supported.
If any problem concerning the site functioning under Opera Software appears apply
to Opera Software technical support service.