Invalid read at zend_objects_store_del_ref_by_handle

16 years ago by Olivier B. — view source

unread

Hello,

I have an other memory corruption problem ; I had the problem on PHP
5.2.6 on Debian Lenny (64bits), so I re-checked with the CVS version
(php5.2-200902060730).

When I run my (really huge) cli-script with valgrind, I obtain this :

==22716== Invalid read of size 4
==22716== at 0x73EC38: zend_objects_store_del_ref_by_handle
(zend_objects_API.c:203)
==22716== by 0x73EAA3: zend_objects_store_del_ref
(zend_objects_API.c:168)
==22716== by 0x7148A1: _zval_dtor_func (zend_variables.c:52)
==22716== by 0x740190: _zval_dtor (zend_variables.h:35)
==22716== by 0x744E02: zend_assign_to_variable (zend_execute.c:804)
==22716== by 0x796752: ZEND_ASSIGN_SPEC_CV_VAR_HANDLER
(zend_vm_execute.h:24593)
==22716== by 0x740F3A: execute (zend_vm_execute.h:92)
==22716== by 0x74169B: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==22716== by 0x742357: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(zend_vm_execute.h:322)
==22716== by 0x740F3A: execute (zend_vm_execute.h:92)
==22716== by 0x74169B: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==22716== by 0x742357: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(zend_vm_execute.h:322)
==22716== Address 0x71f3ac0 is 9,064 bytes inside a block of size
49,152 free'd
==22716== at 0x4C22741: realloc (vg_replace_malloc.c:429)
==22716== by 0x6F4BEB: _erealloc (zend_alloc.c:2314)
==22716== by 0x73E8CA: zend_objects_store_put (zend_objects_API.c:110)
==22716== by 0x73A654: zend_objects_new (zend_objects.c:132)
==22716== by 0x71B49D: _object_and_properties_init (zend_API.c:949)
==22716== by 0x71B5A8: _object_init_ex (zend_API.c:965)
==22716== by 0x4F72F1: do_fetch (pdo_stmt.c:1033)
==22716== by 0x4F8B9D: zim_PDOStatement_fetchObject (pdo_stmt.c:1454)
==22716== by 0x7414CA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:200)
==22716== by 0x742357: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(zend_vm_execute.h:322)
==22716== by 0x740F3A: execute (zend_vm_execute.h:92)
==22716== by 0x74169B: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==22716==
==22716== Invalid read of size 4
==22716== at 0x73ED3B: zend_objects_store_del_ref_by_handle
(zend_objects_API.c:216)
==22716== by 0x73EAA3: zend_objects_store_del_ref
(zend_objects_API.c:168)
==22716== by 0x7148A1: _zval_dtor_func (zend_variables.c:52)
==22716== by 0x740190: _zval_dtor (zend_variables.h:35)
==22716== by 0x744E02: zend_assign_to_variable (zend_execute.c:804)
==22716== by 0x796752: ZEND_ASSIGN_SPEC_CV_VAR_HANDLER
(zend_vm_execute.h:24593)
==22716== by 0x740F3A: execute (zend_vm_execute.h:92)
==22716== by 0x74169B: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==22716== by 0x742357: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(zend_vm_execute.h:322)
==22716== by 0x740F3A: execute (zend_vm_execute.h:92)
==22716== by 0x74169B: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==22716== by 0x742357: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(zend_vm_execute.h:322)
==22716== Address 0x71f3ac0 is 9,064 bytes inside a block of size
49,152 free'd
==22716== at 0x4C22741: realloc (vg_replace_malloc.c:429)
==22716== by 0x6F4BEB: _erealloc (zend_alloc.c:2314)
==22716== by 0x73E8CA: zend_objects_store_put (zend_objects_API.c:110)
==22716== by 0x73A654: zend_objects_new (zend_objects.c:132)
==22716== by 0x71B49D: _object_and_properties_init (zend_API.c:949)
==22716== by 0x71B5A8: _object_init_ex (zend_API.c:965)
==22716== by 0x4F72F1: do_fetch (pdo_stmt.c:1033)
==22716== by 0x4F8B9D: zim_PDOStatement_fetchObject (pdo_stmt.c:1454)
==22716== by 0x7414CA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:200)
==22716== by 0x742357: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(zend_vm_execute.h:322)
==22716== by 0x740F3A: execute (zend_vm_execute.h:92)
==22716== by 0x74169B: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==22716==
==22716== Invalid write of size 4
==22716== at 0x73ED45: zend_objects_store_del_ref_by_handle
(zend_objects_API.c:216)
==22716== by 0x73EAA3: zend_objects_store_del_ref
(zend_objects_API.c:168)
==22716== by 0x7148A1: _zval_dtor_func (zend_variables.c:52)
==22716== by 0x740190: _zval_dtor (zend_variables.h:35)
==22716== by 0x744E02: zend_assign_to_variable (zend_execute.c:804)
==22716== by 0x796752: ZEND_ASSIGN_SPEC_CV_VAR_HANDLER
(zend_vm_execute.h:24593)
==22716== by 0x740F3A: execute (zend_vm_execute.h:92)
==22716== by 0x74169B: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==22716== by 0x742357: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(zend_vm_execute.h:322)
==22716== by 0x740F3A: execute (zend_vm_execute.h:92)
==22716== by 0x74169B: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==22716== by 0x742357: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(zend_vm_execute.h:322)
==22716== Address 0x71f3ac0 is 9,064 bytes inside a block of size
49,152 free'd
==22716== at 0x4C22741: realloc (vg_replace_malloc.c:429)
==22716== by 0x6F4BEB: _erealloc (zend_alloc.c:2314)
==22716== by 0x73E8CA: zend_objects_store_put (zend_objects_API.c:110)
==22716== by 0x73A654: zend_objects_new (zend_objects.c:132)
==22716== by 0x71B49D: _object_and_properties_init (zend_API.c:949)
==22716== by 0x71B5A8: _object_init_ex (zend_API.c:965)
==22716== by 0x4F72F1: do_fetch (pdo_stmt.c:1033)
==22716== by 0x4F8B9D: zim_PDOStatement_fetchObject (pdo_stmt.c:1454)
==22716== by 0x7414CA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:200)
==22716== by 0x742357: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(zend_vm_execute.h:322)
==22716== by 0x740F3A: execute (zend_vm_execute.h:92)
==22716== by 0x74169B: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)

I'm really not sure to can give a "test case" to reproduce the problem ;
so, is this valgrind output suffisant ?

16 years ago by Antony Dovgal — view source

unread

Hello,

I have an other memory corruption problem ; I had the problem on PHP
5.2.6 on Debian Lenny (64bits), so I re-checked with the CVS version
(php5.2-200902060730).

When I run my (really huge) cli-script with valgrind, I obtain this :

<skip> > I'm really not sure to can give a "test case" to reproduce the problem ; > so, is this valgrind output suffisant ?

No, it's not enough, a (short) reproduce script is required.
Also please try to run the same script with 5_3.

--
Wbr,
Antony Dovgal

16 years ago by Christopher Jones — view source

unread

Olivier Bonvalet wrote:

And... if I'm not able to identify which part of the script do that ?

I don't know valgrind, is it possible to obtain some informations about
the partion of code which produce that ?
I suppose the name of the C functions should help to identify that, no ?
And zend_objects_store_del_ref is about object creation or destruction ?
And, it's an object created thought zim_PDOStatement_fetchObject ?

The function zim_PDOStatement_fetchObject would be the implementation
of PDOStatement->fetchObject, i.e.
http://www.php.net/manual/en/pdostatement.fetchobject.php
Look for uses of that method in your script.

Good luck,

Chris

--
Email: christopher.jones@oracle.com Tel: +1 650 506 8630
Twitter: http://twitter.com/ghrd Free PHP Book: http://tinyurl.com/UGPOM

16 years ago by Antony Dovgal — view source

unread

And... if I'm not able to identify which part of the script do that ?

Remove parts of the code one by one, trying to see which parts affect it and which do not.
Finally you should get only those parts of the code, which are required to reproduce it.

I don't know valgrind, is it possible to obtain some informations about
the partion of code which produce that ?

It does show the part of the code which produces it, but the problem is
that it's part of C code, not PHP code and your issue happens on shutdown,
which means something somewhere went wrong BEFORE that point.

I suppose the name of the C functions should help to identify that, no ?
And zend_objects_store_del_ref is about object creation or destruction ?

Object destruction, right.

And, it's an object created thought zim_PDOStatement_fetchObject ?

It seems so, yes.
It makes sense to start looking into that direction if you want to create a reproduce script.

--
Wbr,
Antony Dovgal