04 Aug, 2010, galius wrote in the 1st comment:
Votes: 0
Hello everyone, I'm running a modified rom 2.4 with olc ( I think version 2.01). Anyways, recently I seem to be getting this bug after so many mobs are killed.

Quote
[****] BUG: Progs: MAX_CALL_LEVEL exceeded,


I've looked around and can't seem to find what's making the progs do this. My guess is it's looping somehow? Any ideas what causes this? I've increased the
call_level, but that just delays it for a little longer, and isn't really a solution. Any help would be appreciated. Thanks.
04 Aug, 2010, Ssolvarain wrote in the 2nd comment:
Votes: 0
If it's a specific mprog, could you post it?
I've seen that bug a lot, too. But it's been so long the details are fuzzy. It was usually coupled with a buffer overflow in my case, I think.
04 Aug, 2010, JohnnyStarr wrote in the 3rd comment:
Votes: 0
in mob_prog.c:
#define MAX_CALL_LEVEL    5        /* Maximum nested calls */


It sounds like this limit would need to be increased, but you may want to adjust your progs. MobProgs is a poorly written embedded language, and the author(s) may have limited it for that very reason. As was mentioned, you may want to post some
of your progs so we can troubleshoot further.
05 Aug, 2010, Rarva.Riendf wrote in the 4th comment:
Votes: 0
galius said:
Hello everyone, I'm running a modified rom 2.4 with olc ( I think version 2.01). Anyways, recently I seem to be getting this bug after so many mobs are killed.

Quote
[****] BUG: Progs: MAX_CALL_LEVEL exceeded,


I've looked around and can't seem to find what's making the progs do this. My guess is it's looping somehow? Any ideas what causes this? I've increased the
call_level, but that just delays it for a little longer, and isn't really a solution. Any help would be appreciated. Thanks.


I suggest you run your program through GDB and put a breakpoint where it says that. And work from there, you should soon find why it happens.
05 Aug, 2010, JohnnyStarr wrote in the 5th comment:
Votes: 0
Like I said before, it's obviously happening because his MobProgs have too many function calls.
Find out which progs have too many, or increase the max limit to a reasonable level.
05 Aug, 2010, Rarva.Riendf wrote in the 6th comment:
Votes: 0
JohnnyStarr said:
Like I said before, it's obviously happening because his MobProgs have too many function calls.
Find out which progs have too many, or increase the max limit to a reasonable level.

And like I am saying using gdb with a breakpoint here will show as soon as you return from the method wich mob, and then wich mprog has the problem.
06 Aug, 2010, JohnnyStarr wrote in the 7th comment:
Votes: 0
I'm not arguing with you here Rarva. I'm just saying that it isn't really a problem with the source. Ideally, he would want to add the name of the mob / prog in the exception itself. Not only would this save the time of running gdb for possibly multiple MobProgs (what if there are many?) it would save time for future MobProg development.
06 Aug, 2010, Davion wrote in the 8th comment:
Votes: 0
JohnnyStarr said:
I'm not arguing with you here Rarva. I'm just saying that it isn't really a problem with the source. Ideally, he would want to add the name of the mob / prog in the exception itself. Not only would this save the time of running gdb for possibly multiple MobProgs (what if there are many?) it would save time for future MobProg development.


Ya know, GDB is ideal for this kind of problem. It's not only used when detecting crashes in the code, but it's also good for sniffing out irregularities, or flawed logic in the code. Setting a breakpoint on the line that reports said error will likely show you enough information to track and defeat this bug.

Using GDB to step through your code and see what's happening line by line is also a huge help. It's also very interesting sometimes ;).

R/O/Mprogs are also terrible with reporting errors. Infact, sometimes if you forget to close an if, the entire engine can stop working completely without so much as a peep of an error. Setting up this message to report which mprog it's on, is probably not a bad idea. Also, reading up on WHY this error is being reported is a good idea too. I do the same

if( ++call_level > MAX_CALL_LEVEL )
{
if ( mob )
sprintf( bugbuf, "Progs: MAX_CALL_LEVEL exceeded, vnum %d, mprog vnum %d",
mvnum, pvnum );
else if ( obj )
sprintf( bugbuf, "Progs: MAX_CALL_LEVEL exceeded, vnum %d oprog vnum %d.",
ovnum, pvnum );
else
sprintf( bugbuf, "Progs: MAX_CALL_LEVEL exceeded, vnum %d rprog vnum %d.",
rvnum, pvnum );
bug( bugbuf, 0 );
call_level–;
return;
}
06 Aug, 2010, JohnnyStarr wrote in the 9th comment:
Votes: 0
Agreed. I would like to write a new MobProgs all together.

I really want to finish my Lua interface / library for MERC based muds. I really wish I had more time.
Random Picks
0.0/9