On the other hand these three variables need to be per-request because emalloc()'ed memory can't survive in between requests.
Does anyone have any interesting solutions? If not I guess we can start hacking at the libbcmath sources.
Andi
At 09:44 AM 10/29/2002 -0800, Michael Sisolak wrote:
> I'm seeing a memory overrun under PHP 4.3.0pre2 (debug) running under > Windows 2000 ISAPI. [ . . . ] > --------------------------------------- > C:\Work\php-source\php-4.3.0pre2\ext\bcmath\libbcmath\src\init.c(72): > Freeing 0x01B85050 (1 bytes), script=c:\inetpub\wwwroot\test.php > Last leak repeated 2 times > C:\Work\php-source\php-4.3.0pre2\ext\bcmath\libbcmath\src\init.c(57): > Freeing 0x01B84FF8 (29 bytes), script=c:\inetpub\wwwroot\test.php > Last leak repeated 2 timesBased on seeing these leaks I disabled BCMath and recompiled PHP. Without BCMath active I do not have any of the memory overruns that I reported in my previous message. Looking in the CVS logs for php4/ext/bcmath/bcmath.c I believe there may be an issue with the changes introduced in version 1.37 (by Andi, who is CCed also). This patch moved the allocation and freeing of the static BC numbers _zero_, _one_, and _two_ to a per-request basis instead of at module initilzation and shutdown. It looks like the storage locations for those values are global externs, however, which multiple threads are now allocating and deallocating at the same time. Is there somewhere that I'm not understanding in the code that would keep multiple threads from smashing each other here? Michael Sisolak [EMAIL PROTECTED] __________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/ -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
-- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
