Re: [PHP4BETA] stack overflow in long running script. found the problem!

On Mon, 5 Jul 1999, Zeev Suraski wrote: > AI_COUNT is probably the flakiest part of Zend (it'll be fine once it's > 100% stable, but we're only at around 99% stability right now). > > Calling any AI_COUNT macros is probably wrong, unless you really really > know what you're doing. I'll need access to your machine in order to try > and figure out what's wrong... that's tons of code - and it's my girlfriends birthday today, so i'll be in trouble if i "hack" too long! > > About your piece of code, this piece of code may be problematic for Zend to > handle, and may confuse the garbage collector into a situation where it > would not free any hashes/objects until the method call ends. We decided > that was an acceptable limitation, since you would rarely have a case that > both 'stalls' the garbage collector, and also generates a considerable > amount of garbage. Still, if that does happen, Zend's memory consumption > will rise significantly. It should still not cause stability problems, > unless you run out of memory. bu we have a hard limit the stack-depth is a short which limits us to 2^16 entries until it'll try to allocate a negative amount of memory! wouldn't it make sense to force a gb when the stack contains > n entries? there are only a few places where you put stuff into the gc stack - and it would make things more robust? tc > > Zeev > > At 16:28 05/07/99 , Thies C. Arntzen wrote: > > >whua.... > > > >did some digging: > > > >zend_variables.c:85 pushes thingies on the "garbage" stack, which > >overflows! > > > >zend_execute does not call DEC_AI_COUNT() "often" enough! > > > >i helped myself by calling sometimg like "DEC_AI_COUNT" in zval_dtor - and > >it helped! > > > >which is what we call a "pfusch" in germany (hack would be a too positive > >word for this;-) > > > >so, please check if you forgot to call DEC_AI_COUNT somewhere > > > >BTW: > >the script in question does something like: > > > > > >$dok = new Dossier; > > > >while ($db->getrow()) > > { $dok->loadFromDB($db->getid()); // loadFromDB is ~300 lines of code! > > $dok->save(); // ~500 lines of code > > } > > > >so maybe you forget to call your garbage-collector while just beeing in a > >loop? > > > >regards, > >tc > > > > > > > >On Mon, 5 Jul 1999, Thies C. Arntzen wrote: > > > > > hi, > > > this could be a tough one: > > > > > > a script that runs thru thousands of records (using classses etc) crashes > > > after some time saying: > > > > > > FATAL: erealloc(): Unable to allocate -131072 bytes > > > FATAL: erealloc(): Unable to allocate 0 bytes > > > > > > i traced it down to zend_ptr_stack_push and added a debug line like this: > > > > > > if (stack->top > 1000) > > > fprintf(stderr, "> 0x%08x %d opcode %d on opline %d of %s() at > > %s:%d\n", > > > stack, > > > stack->top - 1, > > > active_opline->opcode, > > > active_opline-EG(active_op_array)->opcodes, > > > get_active_function_name(), > > > zend_get_executed_filename(ELS_C), > > > zend_get_executed_lineno(ELS_C)); > > > > > > (dunno if the debug-output shows the correct script-line, but...) > > > > > > what i get is: > > > > > > > > > ..... > > > > 0x000e010c 8219 opcode 57 on opline 6 of _gettabletype() at > > ../../php/package/phpbasic/phpsite/functions/dossier.fnc:2368 > > > > 0x000e010c 8220 opcode 57 on opline 6 of _gettabletype() at > > ../../php/package/phpbasic/phpsite/functions/dossier.fnc:2368 > > > > 0x000e010c 8221 opcode 57 on opline 2078 of filtabexists() at > > ../../php/package/phpbasic/phpsite/functions/dossier.fnc:1220 > > > > 0x000e010c 8222 opcode 58 on opline 12 of modify() at > > ../../php/package/phpbasic/phpsite/functions/dossier.fnc:556 > > > > 0x000e010c 8223 opcode 58 on opline 12 of modify() at > > ../../php/package/phpbasic/phpsite/functions/dossier.fnc:556 > > > > 0x000e010c 8224 opcode 58 on opline 12 of modify() at > > ../../php/package/phpbasic/phpsite/functions/dossier.fnc:556 > > > > 0x000e010c 8225 opcode 58 on opline 12 of modify() at > > ../../php/package/phpbasic/phpsite/functions/dossier.fnc:556 > > > ..... > > > > 0x000e010c 16399 opcode 57 on opline 48 of _parse() at > > ../../php/package/phpbasic/phpsite/functions/dossier.fnc:1982 > > > > 0x000e010c 16400 opcode 57 on opline 48 of _parse() at > > ../../php/package/phpbasic/phpsite/functions/dossier.fnc:1982 > > > > 0x000e010c 16401 opcode 1515870810 on opline -60479576Segmentation > > fault (core dumped) > > > > > > and so on - this stack is never ever popped, which causes the overflow > > & the crash. > > > > > > there's a lot of php code running - if you want i can get you access to > > one of my boxes! > > > > > > regards, > > > tc > > > > > > > > > Thies C. Arntzen "One Big-Mac, Small Fries and a Coke!" > > > Digital Collections Phone +49 40 235350 Fax +49 40 23535180 > > > Hammerbrookstr. 93 20097 Hamburg / Germany > > > > > > > > > -- > > > PHP 4 Beta > > > > > > > > > > > >Thies C. Arntzen "One Big-Mac, Small Fries and a Coke!" > >Digital Collections Phone +49 40 235350 Fax +49 40 23535180 > >Hammerbrookstr. 93 20097 Hamburg / Germany > > > > > >-- > >PHP 4 Beta > > -- > Zeev Suraski <zeev@zend.com> http://www.zend.com/ > For a PGP public key, finger bourbon@netvision.net.il > > Thies C. Arntzen "One Big-Mac, Small Fries and a Coke!" Digital Collections Phone +49 40 235350 Fax +49 40 23535180 Hammerbrookstr. 93 20097 Hamburg / Germany