Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Problem with CVS »

Problem with CVS

php.internals

Andi Gutmans

23 years ago
Hi, I've been debugging a problem with my memory manager for quite a while (I was playing with different block sizes) when I discovered there doesn't seem to be a bug but the heap gets corrupted by some other place in PHP. It just happens that the memory manager makes this problem appear sooner. The problem seems to be in xmlCleanupParser() of the simplexml extension. Not sure if this is a bug in simplexml or libXML2. On an empty script I get the following reports from valgrind. Can someone with a more intimate knowledge of this module or libXML2 please take a look? (bug.php is an empty script) Thanks, Andi [andi@ ~/php5]$ valgrind sapi/cli/php bug.php ==2074== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==2074== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==2074== Using valgrind-20030725, a program supervision framework for x86-linux. ==2074== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==2074== Estimated CPU clock rate is 551 MHz ==2074== For more details, rerun with: -v ==2074== ==2074== Invalid read of size 4 ==2074== at 0x403A8D4C: __pthread_mutex_destroy (vg_libpthread.c:1010) ==2074== by 0x40344CFC: xmlFreeMutex (threads.c:138) ==2074== by 0x40344189: xmlCleanupGlobals (globals.c:49) ==2074== by 0x402F7C39: xmlCleanupParser (parser.c:11179) ==2074== Address 0x418FC32C is 4 bytes inside a block of size 24 free'd ==2074== at 0x40025722: free (vg_replace_malloc.c:220) ==2074== by 0x40344D04: xmlFreeMutex (threads.c:142) ==2074== by 0x40344189: xmlCleanupGlobals (globals.c:49) ==2074== by 0x402F7C39: xmlCleanupParser (parser.c:11179) ==2074== ==2074== Invalid write of size 4 ==2074== at 0x403A8D69: __pthread_mutex_destroy (vg_libpthread.c:1019) ==2074== by 0x40344CFC: xmlFreeMutex (threads.c:138) ==2074== by 0x40344189: xmlCleanupGlobals (globals.c:49) ==2074== by 0x402F7C39: xmlCleanupParser (parser.c:11179) ==2074== Address 0x418FC32C is 4 bytes inside a block of size 24 free'd ==2074== at 0x40025722: free (vg_replace_malloc.c:220) ==2074== by 0x40344D04: xmlFreeMutex (threads.c:142) ==2074== by 0x40344189: xmlCleanupGlobals (globals.c:49) ==2074== by 0x402F7C39: xmlCleanupParser (parser.c:11179) ==2074== ==2074== Invalid write of size 4 ==2074== at 0x403A8D70: __pthread_mutex_destroy (vg_libpthread.c:1020) ==2074== by 0x40344CFC: xmlFreeMutex (threads.c:138) ==2074== by 0x40344189: xmlCleanupGlobals (globals.c:49) ==2074== by 0x402F7C39: xmlCleanupParser (parser.c:11179) ==2074== Address 0x418FC330 is 8 bytes inside a block of size 24 free'd ==2074== at 0x40025722: free (vg_replace_malloc.c:220) ==2074== by 0x40344D04: xmlFreeMutex (threads.c:142) ==2074== by 0x40344189: xmlCleanupGlobals (globals.c:49) ==2074== by 0x402F7C39: xmlCleanupParser (parser.c:11179) ==2074== ==2074== Invalid write of size 4 ==2074== at 0x403A8D77: __pthread_mutex_destroy (vg_libpthread.c:1021) ==2074== by 0x40344CFC: xmlFreeMutex (threads.c:138) ==2074== by 0x40344189: xmlCleanupGlobals (globals.c:49) ==2074== by 0x402F7C39: xmlCleanupParser (parser.c:11179) ==2074== Address 0x418FC334 is 12 bytes inside a block of size 24 free'd ==2074== at 0x40025722: free (vg_replace_malloc.c:220) ==2074== by 0x40344D04: xmlFreeMutex (threads.c:142) ==2074== by 0x40344189: xmlCleanupGlobals (globals.c:49) ==2074== by 0x402F7C39: xmlCleanupParser (parser.c:11179) ==2074== ==2074== Invalid free() / delete / delete[] ==2074== at 0x40025722: free (vg_replace_malloc.c:220) ==2074== by 0x40344D04: xmlFreeMutex (threads.c:142) ==2074== by 0x40344189: xmlCleanupGlobals (globals.c:49) ==2074== by 0x402F7C39: xmlCleanupParser (parser.c:11179) ==2074== Address 0x418FC328 is 0 bytes inside a block of size 24 free'd ==2074== at 0x40025722: free (vg_replace_malloc.c:220) ==2074== by 0x40344D04: xmlFreeMutex (threads.c:142) ==2074== by 0x40344189: xmlCleanupGlobals (globals.c:49) ==2074== by 0x402F7C39: xmlCleanupParser (parser.c:11179) ==2074== ==2074== ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 4 from 2) ==2074== malloc/free: in use at exit: 288 bytes in 3 blocks. ==2074== malloc/free: 3457 allocs, 3455 frees, 513425 bytes allocated. ==2074== For a detailed leak analysis, rerun with: --leak-check=yes ==2074== For counts of detected errors, rerun with: -v

Thies C. Arntzen

23 years ago
On Sat, Aug 30, 2003 at 04:05:42PM +0300, Andi Gutmans wrote:
> Hi, > > I've been debugging a problem with my memory manager for quite a while (I > was playing with different block sizes) when I discovered there doesn't > seem to be a bug but the heap gets corrupted by some other place in PHP. It > just happens that the memory manager makes this problem appear sooner. > The problem seems to be in xmlCleanupParser() of the simplexml extension. > Not sure if this is a bug in simplexml or libXML2. > On an empty script I get the following reports from valgrind. Can someone > with a more intimate knowledge of this module or libXML2 please take a > look? (bug.php is an empty script)
you are likely to have a buggy version of libXml, that causes this when xmlCleanupParser is called more than once. this happens if two php-modules use libXml and call xmlCleanupParser in the [R|M]SHUTDOWN re, tc
> > Thanks, Andi > > [andi@ ~/php5]$ valgrind sapi/cli/php bug.php > ==2074== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. > ==2074== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. > ==2074== Using valgrind-20030725, a program supervision framework for > x86-linux. > ==2074== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. > ==2074== Estimated CPU clock rate is 551 MHz > ==2074== For more details, rerun with: -v > ==2074== > ==2074== Invalid read of size 4 > ==2074== at 0x403A8D4C: __pthread_mutex_destroy (vg_libpthread.c:1010) > ==2074== by 0x40344CFC: xmlFreeMutex (threads.c:138) > ==2074== by 0x40344189: xmlCleanupGlobals (globals.c:49) > ==2074== by 0x402F7C39: xmlCleanupParser (parser.c:11179) > ==2074== Address 0x418FC32C is 4 bytes inside a block of size 24 free'd > ==2074== at 0x40025722: free (vg_replace_malloc.c:220) > ==2074== by 0x40344D04: xmlFreeMutex (threads.c:142) > ==2074== by 0x40344189: xmlCleanupGlobals (globals.c:49) > ==2074== by 0x402F7C39: xmlCleanupParser (parser.c:11179) > ==2074== > ==2074== Invalid write of size 4 > ==2074== at 0x403A8D69: __pthread_mutex_destroy (vg_libpthread.c:1019) > ==2074== by 0x40344CFC: xmlFreeMutex (threads.c:138) > ==2074== by 0x40344189: xmlCleanupGlobals (globals.c:49) > ==2074== by 0x402F7C39: xmlCleanupParser (parser.c:11179) > ==2074== Address 0x418FC32C is 4 bytes inside a block of size 24 free'd > ==2074== at 0x40025722: free (vg_replace_malloc.c:220) > ==2074== by 0x40344D04: xmlFreeMutex (threads.c:142) > ==2074== by 0x40344189: xmlCleanupGlobals (globals.c:49) > ==2074== by 0x402F7C39: xmlCleanupParser (parser.c:11179) > ==2074== > ==2074== Invalid write of size 4 > ==2074== at 0x403A8D70: __pthread_mutex_destroy (vg_libpthread.c:1020) > ==2074== by 0x40344CFC: xmlFreeMutex (threads.c:138) > ==2074== by 0x40344189: xmlCleanupGlobals (globals.c:49) > ==2074== by 0x402F7C39: xmlCleanupParser (parser.c:11179) > ==2074== Address 0x418FC330 is 8 bytes inside a block of size 24 free'd > ==2074== at 0x40025722: free (vg_replace_malloc.c:220) > ==2074== by 0x40344D04: xmlFreeMutex (threads.c:142) > ==2074== by 0x40344189: xmlCleanupGlobals (globals.c:49) > ==2074== by 0x402F7C39: xmlCleanupParser (parser.c:11179) > ==2074== > ==2074== Invalid write of size 4 > ==2074== at 0x403A8D77: __pthread_mutex_destroy (vg_libpthread.c:1021) > ==2074== by 0x40344CFC: xmlFreeMutex (threads.c:138) > ==2074== by 0x40344189: xmlCleanupGlobals (globals.c:49) > ==2074== by 0x402F7C39: xmlCleanupParser (parser.c:11179) > ==2074== Address 0x418FC334 is 12 bytes inside a block of size 24 free'd > ==2074== at 0x40025722: free (vg_replace_malloc.c:220) > ==2074== by 0x40344D04: xmlFreeMutex (threads.c:142) > ==2074== by 0x40344189: xmlCleanupGlobals (globals.c:49) > ==2074== by 0x402F7C39: xmlCleanupParser (parser.c:11179) > ==2074== > ==2074== Invalid free() / delete / delete[] > ==2074== at 0x40025722: free (vg_replace_malloc.c:220) > ==2074== by 0x40344D04: xmlFreeMutex (threads.c:142) > ==2074== by 0x40344189: xmlCleanupGlobals (globals.c:49) > ==2074== by 0x402F7C39: xmlCleanupParser (parser.c:11179) > ==2074== Address 0x418FC328 is 0 bytes inside a block of size 24 free'd > ==2074== at 0x40025722: free (vg_replace_malloc.c:220) > ==2074== by 0x40344D04: xmlFreeMutex (threads.c:142) > ==2074== by 0x40344189: xmlCleanupGlobals (globals.c:49) > ==2074== by 0x402F7C39: xmlCleanupParser (parser.c:11179) > ==2074== > ==2074== ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 4 from 2) > ==2074== malloc/free: in use at exit: 288 bytes in 3 blocks. > ==2074== malloc/free: 3457 allocs, 3455 frees, 513425 bytes allocated. > ==2074== For a detailed leak analysis, rerun with: --leak-check=yes > ==2074== For counts of detected errors, rerun with: -v > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php
-- Thies C. Arntzen - Looking for all sorts of freelance work - just ask.. http://www.amazon.de/exec/obidos/wishlist/AB9DY62QWDSZ

Andi Gutmans

23 years ago
At 03:09 PM 8/30/2003 +0200, Thies C. Arntzen wrote:
> you are likely to have a buggy version of libXml, that > causes this when xmlCleanupParser is called more than once. > > this happens if two php-modules use libXml and call > xmlCleanupParser in the [R|M]SHUTDOWN
Ouch. Now the question is how do we solve this? Do we make ./configure bail out on such versions or do we hack something into PHP so that it doesn't call this function more than once? I really want to reduce the block size in my mem manager from 256KB to 16KB but I can't do it right now because it kills PHP quicker (it will die in any case but it will take longer). Thanks, Andi

Rob Richards

23 years ago
From: Andi Gutmans
> Ouch. Now the question is how do we solve this? Do we make ./configure
bail
> out on such versions or do we hack something into PHP so that it doesn't > call this function more than once? > I really want to reduce the block size in my mem manager from 256KB to
16KB
> but I can't do it right now because it kills PHP quicker (it will die in > any case but it will take longer).
Do you know what happens if another apache mod were to be using libxml (there are some)? Would they be sharing the same space as in, if the other mod were to change libxml globals, would that affect the libxml globals within the php scope? I believe they would clash but dont know for sure. If so, then libxml 2.5.8 would have to be marked bad unless you can also know when the other mods call their cleanup. This is a 2.5.8 issue only as it was introduce in that version and fixed in 2.5.9. Rob

Andi Gutmans

23 years ago
At 09:56 AM 8/30/2003 -0400, Rob Richards wrote:
>From: Andi Gutmans > > Ouch. Now the question is how do we solve this? Do we make ./configure >bail > > out on such versions or do we hack something into PHP so that it doesn't > > call this function more than once? > > I really want to reduce the block size in my mem manager from 256KB to >16KB > > but I can't do it right now because it kills PHP quicker (it will die in > > any case but it will take longer). > >Do you know what happens if another apache mod were to be using libxml >(there are some)? Would they be sharing the same space as in, if the other >mod were to change libxml globals, would that affect the libxml globals >within the php scope? I believe they would clash but dont know for sure.
They probably would.
>If so, then libxml 2.5.8 would have to be marked bad unless you can also >know when the other mods call their cleanup. This is a 2.5.8 issue only as >it was introduce in that version and fixed in 2.5.9.
Can someone who knows configure well please add a check and bail out on 2.5.8? Thanks, Andi

Jani Taskinen

23 years ago
On Sat, 30 Aug 2003, Andi Gutmans wrote:
>>If so, then libxml 2.5.8 would have to be marked bad unless you can also >>know when the other mods call their cleanup. This is a 2.5.8 issue only as >>it was introduce in that version and fixed in 2.5.9. > >Can someone who knows configure well please add a check and bail out on 2.5.8?
I can add that..but shouldn't we just go ahead and require 2.5.9 or greater instead of skipping ONE version?? --Jani

Andi Gutmans

23 years ago
At 12:59 AM 8/31/2003 +0300, Jani Taskinen wrote:
>On Sat, 30 Aug 2003, Andi Gutmans wrote: > > >>If so, then libxml 2.5.8 would have to be marked bad unless you can also > >>know when the other mods call their cleanup. This is a 2.5.8 issue only as > >>it was introduce in that version and fixed in 2.5.9. > > > >Can someone who knows configure well please add a check and bail out on > 2.5.8? > > I can add that..but shouldn't we just go ahead and require > 2.5.9 or greater instead of skipping ONE version??
I think that's probably a good idea although it might piss some people off :) Andi

Timm Friebe

23 years ago
On Sun, 2003-08-31 at 06:18, Andi Gutmans wrote: [...libxml2 requirements...]
> > I can add that..but shouldn't we just go ahead and require > > 2.5.9 or greater instead of skipping ONE version?? > > I think that's probably a good idea although it might piss some people off :)
Just FYI, I had problems with 2.5.9 here on FreeBSD, getting "PHP in free: chunk is already free" twice at shutdown - upgrading to 2.5.10 fixed it. - Timm

Rob Richards

23 years ago
From: Andi Gutmans
> > I can add that..but shouldn't we just go ahead and require > > 2.5.9 or greater instead of skipping ONE version?? > > I think that's probably a good idea although it might piss some people off
:) Since this is still a beta why not just skip that one version. 2.5.4 is included with some of the major distros so for now why not just limit the collateral damage this will cause by not requiring the latest version. Probably reduce the amount of questions of how to get and install libxml as well. By the time php 5 gets to a release, 2.5.9 and higher will most likely be more common and it could be revisited then if need be. Rob

Jani Taskinen

23 years ago
On Sun, 31 Aug 2003, Rob Richards wrote:
>From: Andi Gutmans > >> > I can add that..but shouldn't we just go ahead and require >> > 2.5.9 or greater instead of skipping ONE version?? >> >> I think that's probably a good idea although it might piss some people off >:) > >Since this is still a beta why not just skip that one version. 2.5.4 is >included with some of the major distros so for now why not just limit the >collateral damage this will cause by not requiring the latest version. >Probably reduce the amount of questions of how to get and install libxml as >well. By the time php 5 gets to a release, 2.5.9 and higher will most likely >be more common and it could be revisited then if need be.
Someone said 2.5.7 is buggy too? So which versions are good and which not? Range? :) --Jani

Jani Taskinen

23 years ago
On Sun, 31 Aug 2003, Rob Richards wrote:
>From: Andi Gutmans > >> > I can add that..but shouldn't we just go ahead and require >> > 2.5.9 or greater instead of skipping ONE version?? >> >> I think that's probably a good idea although it might piss some people off >:) > >Since this is still a beta why not just skip that one version. 2.5.4 is >included with some of the major distros so for now why not just limit the >collateral damage this will cause by not requiring the latest version. >Probably reduce the amount of questions of how to get and install libxml as >well. By the time php 5 gets to a release, 2.5.9 and higher will most likely >be more common and it could be revisited then if need be.
And do you really want to hunt after all ghost bugs that are really caused by buggy libxml versions..? And like you said, PHP 5 is still beta. Nobody should be using it for real anyway. :) (and they can always do '--disable-xml' etc.) So I say we just require libxml 2.5.10 or higher. --Jani

Rob Richards

23 years ago
From: Jani Taskinen
> And do you really want to hunt after all ghost bugs that are really > caused by buggy libxml versions..? And like you said, PHP 5 is still > beta. Nobody should be using it for real anyway. :) > > (and they can always do '--disable-xml' etc.) > > So I say we just require libxml 2.5.10 or higher.
Going with 2.5.10 is fine with me, but this does bring up the issue I had raised before beta 1 was released. This has NOTHING to do with bundling arguments, so no one use this to start that thread again please. If any version is going to be allowed to be used by the end user, looks like 2.5.10+, there needs to be one or more versions that are considered supported, meaning the extensions have been tested against those versions and those are what are primarily used to test bug reports against. We have clearly seen that libxml does break things in its versions, even though the API is considered stable (which was one of the arguments against this idea in the first place). The changes can affect any one if not all of the xml based extensions and as you mentioned: "And do you really want to hunt after all ghost bugs that are really caused by buggy libxml versions..?". This is exactly where we are right now. Rob

Zeev Suraski

23 years ago
At 14:01 31/08/2003, Rob Richards wrote:
>From: Jani Taskinen > > And do you really want to hunt after all ghost bugs that are really > > caused by buggy libxml versions..? And like you said, PHP 5 is still > > beta. Nobody should be using it for real anyway. :) > > > > (and they can always do '--disable-xml' etc.) > > > > So I say we just require libxml 2.5.10 or higher. > >Going with 2.5.10 is fine with me, but this does bring up the issue I had >raised before beta 1 was released. This has NOTHING to do with bundling >arguments, so no one use this to start that thread again please. If any >version is going to be allowed to be used by the end user, looks like >2.5.10+, there needs to be one or more versions that are considered >supported, meaning the extensions have been tested against those versions >and those are what are primarily used to test bug reports against. > >We have clearly seen that libxml does break things in its versions, even >though the API is considered stable (which was one of the arguments against >this idea in the first place). The changes can affect any one if not all of >the xml based extensions and as you mentioned: "And do you really want to >hunt after all ghost bugs that are really caused by buggy libxml >versions..?". This is exactly where we are right now.
I agree, except I think it has a lot to do with bundling. For now, I say let's require 2.5.10+. Zeev

Unnamed Person

23 years ago
The current support for references is mediocre at best. For instance: class foobar { var $variable; function foobar() { $variable = "foobar"; } } //This form of new assignment should be the default $a = & new foobar(); $b = & new foobar(); $b->variable = "Hello"; $array = array(&$a, &$b); //The foreach construct uses copies instead of references. foreach ($array as $element) $element->variable = "Hi"; echo $a->variable; //echoes "foobar" echo $b->variable; //echoes "Hello"; //In order for the above to work, a loop is required. for ($i = 0, $count = count($array); $i < $count; $i++) { $element = &$array[$i]; //shown explicitly. $element->variable = "Hi"; } echo $a->variable; //echoes "Hi" echo $b->variable; //echoes "Hi"; //Variable args are always copies, Function foo() { $args = func_get_args() //even loop doesn't work: for ($i = 0, $count = count($args); $i < $count; $i++) { $element = &$args[$i]; $element->variable = "Hello"; } } foo(&$a, &$b); echo $a->variable; //echoes "Hi" echo $b->variable; //echoes "Hi"; Thanks for your time, LingWitt@insightbb.com

Derick Rethans

23 years ago
On Sat, 30 Aug 2003 LingWitt@insightbb.com wrote:
> The current support for references is mediocre at best. For instance: > > class foobar > { > var $variable; > > function foobar() > { > $variable = "foobar"; > } > } > > //This form of new assignment should be the default > $a = & new foobar(); > $b = & new foobar(); > $b->variable = "Hello";
Try PHP 5, and stop mailing those user questions to the internals development list. Derick
-- "Interpreting what the GPL actually means is a job best left to those that read the future by examining animal entrails." ------------------------------------------------------------------------- Derick Rethans http://derickrethans.nl/ International PHP Magazine http://php-mag.net/ -------------------------------------------------------------------------

Unnamed Person

23 years ago
Firstly, thanks for the tip. Secondly, since you fixed the problems I enumerated in another version, it would seem that my posting is relevant to development. Thanks, LingWitt@insightbb.com On Saturday, Aug 30, 2003, at 10:22 America/New_York, Derick Rethans wrote:

Derick Rethans

23 years ago
On Sat, 30 Aug 2003 LingWitt@insightbb.com wrote:
> Firstly, thanks for the tip. > Secondly, since you fixed the problems I enumerated in another version, > it would seem that my posting is relevant to development.
That's not your decision to make. It's totally irrelevant. Derick
-- "Interpreting what the GPL actually means is a job best left to those that read the future by examining animal entrails." ------------------------------------------------------------------------- Derick Rethans http://derickrethans.nl/ International PHP Magazine http://php-mag.net/ -------------------------------------------------------------------------