2011-08-24 2 views
1

Valgrind의이 보고서가 무엇인지 파악하기 :어떻게 잘못의 주소

==4538== Invalid read of size 4 
==4538== at 0x822D3C6: _zval_ptr_dtor (zend.h:385) 
==4538== by 0x823C1FF: _zval_ptr_dtor_wrapper (zend_variables.c:189) 
==4538== by 0x824E1A1: zend_hash_destroy (zend_hash.c:529) 
==4538== by 0x826655A: zend_object_std_dtor (zend_objects.c:45) 
==4538== by 0x8266A28: zend_objects_free_object_storage (zend_objects.c:126) 
==4538== by 0x826C43D: zend_objects_store_del_ref_by_handle_ex (zend_objects_API.c:220) 
==4538== by 0x826C0AC: zend_objects_store_del_ref (zend_objects_API.c:172) 
==4538== by 0x823BD77: _zval_dtor_func (zend_variables.c:52) 
==4538== by 0x822B99B: _zval_dtor (zend_variables.h:35) 
==4538== by 0x822D463: _zval_ptr_dtor (zend_execute_API.c:443) 
==4538== by 0x823C1FF: _zval_ptr_dtor_wrapper (zend_variables.c:189) 
==4538== by 0x824E518: zend_hash_apply_deleter (zend_hash.c:614) 
==4538== Address 0x44c1718 is 8 bytes inside a block of size 20 free'd 
==4538== at 0x4026E9C: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) 
==4538== by 0x8216374: _efree (zend_alloc.c:2358) 
==4538== by 0x822D48E: _zval_ptr_dtor (zend_execute_API.c:444) 
==4538== by 0x469B2C5: zim_ASTTree___destruct (parser.c:336) 
==4538== by 0x822F8CE: zend_call_function (zend_execute_API.c:986) 
==4538== by 0x825A8E2: zend_call_method (zend_interfaces.c:97) 
==4538== by 0x8266978: zend_objects_destroy_object (zend_objects.c:112) 
==4538== by 0x826C2AD: zend_objects_store_del_ref_by_handle_ex (zend_objects_API.c:206) 
==4538== by 0x826C0AC: zend_objects_store_del_ref (zend_objects_API.c:172) 
==4538== by 0x823BD77: _zval_dtor_func (zend_variables.c:52) 
==4538== by 0x822B99B: _zval_dtor (zend_variables.h:35) 
==4538== by 0x822D463: _zval_ptr_dtor (zend_execute_API.c:443) 

가 어떻게 잘못된 읽기의 주소를 찾을 수 있습니다 ?

답변

2

유효하지 않은 읽기가 zend_hash_destroy()라는 함수 내에서 발생합니다.

그러나 메모리는 이미 zend_objects_destroy_object() 함수에 의해 할당이 해제되었습니다.

"zend"내부에서 일어나는 모든 현상이 "zend"의 문제를 가리키는 것으로 보입니다. PHP를 디버깅하려는 경우 valgrind를 사용하여 여기까지 (이 도구를 많이 사용함) 많이 사용하게 될지 확신 할 수 없습니다.

+0

나는 내 코드가 100 % 확신합니다. 버기, 나는 refcounting (쓰레기 수집기 카운터)를 엉망으로 만들었고 ZE는 거기에 다른 값을 기대합니다. 그래서 그 일이 일어나고 있습니다. 그래서 번호가 정말 필요합니다. 포인터, 구체적으로. – Flavius

+1

실마리는이 메시지 "주소 0x44c1718은 크기가 20 인 free'd 블록 안에 8 바이트입니다. - 훨씬 이전에 20 바이트 블록 안에 8 바이트 인 0x44c1718을 읽으려고합니다. 블록을 누가 malloc했는지 알고 싶다면 --track-origins = yes 플래그와 --leak-check = yes 플래그로 valgrind를 실행할 수 있습니다. –

+0

그렇다면 올바르게 이해하면 블록의 시작 부분은'0x44c1710'입니까? – Flavius