"Zend_mm_heap दूषित" का क्या अर्थ है

127

अचानक मुझे अपने आवेदन में समस्या आ रही है जो मैंने पहले कभी नहीं की। मैंने अपाचे के त्रुटि लॉग की जांच करने का फैसला किया, और मुझे "zend_mm_heap दूषित" कहते हुए एक त्रुटि संदेश मिला। इसका क्या मतलब है।

ओएस: फेडोरा कोर 8 अपाचे: 2.2.9 पीएचपी: 5.2.6

php  heap  fedora  php-internals 
— bkulyk
स्रोत
2
मैं USE_ZEND_ALLOC=0त्रुटि लॉग में स्टैकट्रेस प्राप्त करता था और बग ढूंढता था /usr/sbin/httpd: corrupted double-linked list, मुझे पता चला कि opcache.fast_shutdown=1मेरे लिए काम करना टिप्पणी करना था।
— स्पाइडरफेयर
हाँ आपके जैसा। इसके अलावा एक और रिपोर्ट नीचे देखें stackoverflow.com/a/35212026/35946
— lkraav
मेरे पास लारवेल का उपयोग करने की एक ही बात थी। मैंने एक वर्ग को दूसरे वर्ग के कंस्ट्रक्टर में इंजेक्ट किया। जिस वर्ग को मैं इंजेक्ट कर रहा था, उस वर्ग को इंजेक्ट कर रहा था जिसे अंतःक्षिप्त किया गया था, मूल रूप से एक गोलाकार संदर्भ पैदा कर रहा था जिससे ढेर मुद्दा बन गया था।
— थॉमस
1
तेज और अस्थायी समाधान के लिए Apache सर्वर को फिर से शुरू करें :)
— Leopathu

जवाबों:

52

बहुत परीक्षण और त्रुटि के बाद, मैंने पाया कि अगर मैं output_bufferingphp.ini फ़ाइल में मान बढ़ाता हूं , तो यह त्रुटि दूर हो जाती है

— dsmithers
स्रोत
59
क्या बढ़ाएं? यह परिवर्तन इस त्रुटि को दूर क्यों करेगा?
— जेडीएस
2
@JDS यह जवाब समझाने में मदद करता है कि output_buffering क्या है और क्यों इसे बढ़ाने में मदद कर सकता है stackoverflow.com/a/2832179/704803
— andrewtweber
8
@andrewtweber मुझे पता है कि वह क्या है, मैं उन विशिष्ट विवरणों के बारे में सोच रहा था जो डस्मीटर्स के उत्तर से बचे हुए थे, क्योंकि मैं ऑप के समान त्रुटि संदेश दे रहा था। बंद करने के लिए: यह पता चला कि मेरी समस्या एक गलतफहमी सेटिंग थी जो मेमकेच से संबंधित थी। हालांकि धन्यवाद!
— JDS
@JDS सेटिंग क्या गलत है?
— काइल क्रोनिन
3
@KyleCronin हमारा सेवा मंच उत्पादन में मेम्के का उपयोग करता है। हालांकि, कुछ एकल उदाहरण - गैर-उत्पादन / सैंडबॉक्स, ग्राहक एक-बंद - मेम्केच का उपयोग नहीं करते हैं। बाद के मामले में, मेरे पास उत्पादन से एक ग्राहक के लिए एक कॉन्फ़िगरेशन की प्रतिलिपि थी, और मेम्चेचे कॉन्फ़िगरेशन ने एक मेमेकैच सर्वर यूआरआई का संकेत दिया था जो उस वातावरण में उपलब्ध नहीं था। मैंने ऐप में लाइन और डिसेबल मेमेकैच को डिलीट कर दिया और समस्या दूर हो गई। तो, लंबी कहानी छोटी, एक विशिष्ट वातावरण में एक बहुत ही विशिष्ट समस्या सामने आई, जो आमतौर पर लागू नहीं हो सकती है। लेकिन, जब से आपने पूछा ...
— JDS
47

यह एक समस्या नहीं है जो जरूरी रूप से विन्यास विकल्पों को बदलकर हल करने योग्य है।

कॉन्फ़िगरेशन विकल्पों को बदलने से कभी-कभी सकारात्मक प्रभाव पड़ेगा, लेकिन यह आसानी से चीजों को आसानी से खराब कर सकता है, या कुछ भी नहीं कर सकता है।

त्रुटि की प्रकृति यह है:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

int main(void) {
    void **mem = malloc(sizeof(char)*3);
    void *ptr;

    /* read past end */
    ptr = (char*) mem[5];   

    /* write past end */
    memcpy(mem[5], "whatever", sizeof("whatever"));

    /* free invalid pointer */
    free((void*) mem[3]);

    return 0;
}

ऊपर दिए गए कोड के साथ संकलित किया जा सकता है:

gcc -g -o corrupt corrupt.c

मान्य के साथ कोड को निष्पादित करने पर आप कई मेमोरी त्रुटियों को देख सकते हैं, एक विभाजन दोष में समाप्त हो सकते हैं:

krakjoe@fiji:/usr/src/php-src$ valgrind ./corrupt
==9749== Memcheck, a memory error detector
==9749== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==9749== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==9749== Command: ./corrupt
==9749== 
==9749== Invalid read of size 8
==9749==    at 0x4005F7: main (an.c:10)
==9749==  Address 0x51fc068 is 24 bytes after a block of size 16 in arena "client"
==9749== 
==9749== Invalid read of size 8
==9749==    at 0x400607: main (an.c:13)
==9749==  Address 0x51fc068 is 24 bytes after a block of size 16 in arena "client"
==9749== 
==9749== Invalid write of size 2
==9749==    at 0x4C2F7E3: memcpy@@GLIBC_2.14 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==9749==    by 0x40061B: main (an.c:13)
==9749==  Address 0x50 is not stack'd, malloc'd or (recently) free'd
==9749== 
==9749== 
==9749== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==9749==  Access not within mapped region at address 0x50
==9749==    at 0x4C2F7E3: memcpy@@GLIBC_2.14 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==9749==    by 0x40061B: main (an.c:13)
==9749==  If you believe this happened as a result of a stack
==9749==  overflow in your program's main thread (unlikely but
==9749==  possible), you can try to increase the size of the
==9749==  main thread stack using the --main-stacksize= flag.
==9749==  The main thread stack size used in this run was 8388608.
==9749== 
==9749== HEAP SUMMARY:
==9749==     in use at exit: 3 bytes in 1 blocks
==9749==   total heap usage: 1 allocs, 0 frees, 3 bytes allocated
==9749== 
==9749== LEAK SUMMARY:
==9749==    definitely lost: 0 bytes in 0 blocks
==9749==    indirectly lost: 0 bytes in 0 blocks
==9749==      possibly lost: 0 bytes in 0 blocks
==9749==    still reachable: 3 bytes in 1 blocks
==9749==         suppressed: 0 bytes in 0 blocks
==9749== Rerun with --leak-check=full to see details of leaked memory
==9749== 
==9749== For counts of detected and suppressed errors, rerun with: -v
==9749== ERROR SUMMARY: 4 errors from 3 contexts (suppressed: 0 from 0)
Segmentation fault

यदि आप नहीं जानते, तो आप पहले से ही यह पता लगा चुके हैं mem ढेर स्मृति आवंटित है; हीप रनटाइम में प्रोग्राम के लिए उपलब्ध मेमोरी के क्षेत्र को संदर्भित करता है, क्योंकि प्रोग्राम ने स्पष्ट रूप से यह अनुरोध किया था (हमारे मामले में मैलोक के साथ)।

यदि आप भयानक कोड के साथ खेलते हैं, तो आप पाएंगे कि उनमें से सभी स्पष्ट रूप से गलत बयानों के परिणामस्वरूप विभाजन दोष (एक घातक समाप्ति त्रुटि) के परिणामस्वरूप नहीं होते हैं।

मैंने स्पष्ट रूप से उदाहरण कोड में उन त्रुटियों को बनाया है, लेकिन मेमोरी प्रबंधित वातावरण में उसी प्रकार की त्रुटियां बहुत आसानी से होती हैं: यदि कुछ कोड सही तरीके से किसी चर (या किसी अन्य प्रतीक) के रिफेकाउंट को बनाए नहीं रखते हैं, उदाहरण के लिए यदि यह मुफ़्त है तो बहुत जल्दी, कोड का एक और टुकड़ा पहले से ही फ्री होल्ड मेमोरी से पढ़ सकता है, अगर यह किसी तरह पते को गलत रखता है, तो कोड का एक और टुकड़ा अमान्य मेमोरी को लिख सकता है, यह दो बार फ्री होल्ड हो सकता है ...

ये ऐसी समस्याएं नहीं हैं जिन्हें PHP में डिबग किया जा सकता है, उन्हें बिल्कुल एक आंतरिक डेवलपर के ध्यान की आवश्यकता होती है।

कार्रवाई का क्रम होना चाहिए:

  1. Http://bugs.php.net पर बग रिपोर्ट खोलें
    • यदि आपके पास सेगफॉल्ट है, तो बैकट्रेस प्रदान करने का प्रयास करें
    • उचित रूप में अधिक से अधिक कॉन्फ़िगरेशन जानकारी शामिल करें, विशेष रूप से, यदि आप opcache का उपयोग कर रहे हैं तो अनुकूलन स्तर शामिल है।
    • अपडेट के लिए बग रिपोर्ट की जांच करते रहें, अधिक जानकारी के लिए अनुरोध किया जा सकता है।
  2. यदि आपके पास opcache भरा हुआ है, तो अनुकूलन को अक्षम करें
    • मैं opcache पर नहीं उठा रहा हूँ, यह बहुत अच्छा है, लेकिन इसके कुछ अनुकूलन दोष का कारण बन गए हैं।
    • यदि वह काम नहीं करता है, भले ही आपका कोड धीमा हो, तो पहले अपाचे को उतारने का प्रयास करें।
    • यदि इनमें से कोई भी समस्या को बदलता है या ठीक करता है, तो आपके द्वारा बनाई गई बग रिपोर्ट को अपडेट करें।
  3. एक बार में सभी अनावश्यक एक्सटेंशन अक्षम करें ।
    • अपने सभी एक्सटेंशन को व्यक्तिगत रूप से सक्षम करना शुरू करें, प्रत्येक कॉन्फ़िगरेशन परिवर्तन के बाद पूरी तरह से परीक्षण करें।
    • यदि आप समस्या विस्तार पाते हैं, तो अपनी बग रिपोर्ट को अधिक जानकारी से अपडेट करें।
  4. फायदा।

कोई लाभ नहीं हो सकता है ... मैंने कहा शुरुआत में, आप कॉन्फ़िगरेशन के साथ खिलवाड़ करके अपने लक्षणों को बदलने का एक तरीका खोजने में सक्षम हो सकते हैं, लेकिन यह बेहद हिट और मिस है, और अगली बार आपके पास मदद नहीं करता है वही zend_mm_heap corrupted संदेश, केवल बहुत सारे विन्यास विकल्प हैं।

यह वास्तव में महत्वपूर्ण है कि हम बग रिपोर्ट बनाते हैं जब हम बग पाते हैं, तो हम यह नहीं मान सकते हैं कि बग को हिट करने वाला अगला व्यक्ति ऐसा करने जा रहा है ... अधिक संभावना नहीं है, वास्तविक संकल्प किसी भी तरह से रहस्यमय नहीं है, यदि आप इसे बनाते हैं समस्या के बारे में सही लोगों को पता है।

USE_ZEND_ALLOC

यदि आप सेट करते हैं USE_ZEND_ALLOC=0 वातावरण में करते हैं, तो यह Zend के अपने मेमोरी मैनेजर को निष्क्रिय कर देता है; ज़ेंड की मेमोरी मैनेजर यह सुनिश्चित करती है कि प्रत्येक अनुरोध का अपना ढेर हो, कि सभी मेमोरी एक अनुरोध के अंत में मुफ्त है, और यह PHP के लिए सही आकार की मेमोरी के चोक के आवंटन के लिए अनुकूलित है।

इसे अक्षम करना उन अनुकूलन को अक्षम कर देगा, अधिक महत्वपूर्ण बात यह है कि यह मेमोरी लीक की संभावना पैदा करेगा, क्योंकि बहुत सारे एक्सटेंशन कोड हैं जो एक अनुरोध के अंत में उनके लिए मुफ्त मेमोरी के लिए Zend MM पर निर्भर करता है (tut, tut)।

यह लक्षणों को छिपा भी सकता है, लेकिन सिस्टम हीप को ठीक उसी तरह से भ्रष्ट किया जा सकता है जैसे कि ज़ेंड का ढेर।

यह अधिक सहिष्णु या कम सहिष्णु लग सकता है, लेकिन समस्या के मूल कारण को ठीक कर सकता है, यह नहीं कर सकता ।

इसे बिल्कुल अक्षम करने की क्षमता, आंतरिक डेवलपर्स के लाभ के लिए है; आपको कभी भी PHP को Zend MM से डिसेबल नहीं करना चाहिए ।

— जो वाटकिंस
स्रोत
तो अंतर्निहित समस्या यह हो सकती है कि आप PHP का कौन सा संस्करण चला रहे हैं?
— इस्माईल
@ इस्माइल हां, साथ ही सभी एक्सटेंशन के संस्करण, क्योंकि चेतावनी एक एक्सटेंशन से उत्पन्न हो सकती है।
— बिशप
2
यह उत्तर मुझे सबसे अच्छा लगता है। मैंने व्यक्तिगत रूप से समस्या को कुछ समय का अनुभव किया है और यह हमेशा एक दोषपूर्ण विस्तार (मेरे मामले में, एंचेंट वर्तनी पुस्तकालय) से संबंधित था। स्वयं php के अलावा, यह एक खराब वातावरण (गलत संस्करण बेमेल, गलत निर्भरता, आदि) भी हो सकता है
— Fractalizer
1
अब तक, इस सवाल का सबसे अच्छा जवाब है, और इसी तरह के कई अन्य सवालों के लिए
— निकिता
यह उत्तर वास्तव में शिक्षाप्रद है, लेकिन मेरा मानना ​​है कि यह सर्वर कोर को डीबग करने के लिए एक एप्लिकेशन डेवलपर का काम नहीं है। यदि आपके पास पूर्ण स्टैक ट्रेस है, तो वास्तव में यह अधिक आसान है लेकिन आगे क्या है? पुल अनुरोध पर इसे ठीक करने के लिए कहें? हर कोई सी की तरह निम्न स्तर की भाषा को समझने या समझने में सक्षम नहीं है। विपरीत भी सच है। इसलिए अंत में मेरा मानना ​​है कि यह बहुत आसान होगा कि डेवलपर्स पहली बार में मेमोरी मैनेजमेंट की गलतियाँ नहीं करेंगे। जैसा कि आप सुझाव देते हैं कि अपाचे के साथ थोड़े सामान्य हैं, लेकिन आश्चर्यजनक रूप से सभी मॉड्यूल के साथ नहीं, क्योंकि आप जानते हैं कि कुछ देव जानते हैं कि कैसे देवता हैं।
— job3dot5
46

मुझे PHP 5.5 के तहत यही त्रुटि मिल रही थी और आउटपुट बफ़रिंग बढ़ाने से कोई मदद नहीं मिली। मैं एपीसी नहीं चला रहा था, इसलिए यह मुद्दा नहीं था। मैंने आखिरकार इसे अपाचे से नीचे ट्रैक किया , मुझे बस इसे क्ली से अक्षम करना था। इसके लिए एक विशिष्ट सेटिंग थी: 

opcache.enable_cli=0

एक बार zend_mm_heap को दूषित करने पर त्रुटि दूर हो गई।

— जस्टिन मैकलेओड
स्रोत
वही समस्या और समाधान यहाँ! धन्यवाद!
— मौरिसियो सांचेज़ 20
2
इस पद के लिए विशाल प्लस 1। हमने सब कुछ करने की कोशिश की लेकिन अंत में केवल यही काम किया।
— जेफ्री बैरियर
7
मुझे यकीन है कि आपको पता है कि cli php का कमांड लाइन संस्करण है और इसका उदाहरण के लिए Apache वेब सर्वर के साथ उपयोग किए गए php मॉड्यूल से कोई लेना-देना नहीं है और मैं उत्सुक हूं कि cli के साथ opcache को कैसे अक्षम किया गया? (मैं मान रहा हूं कि यह वेब सर्वर पर हो रहा है)
— BIOHAZARD
@BioHazard, cli के अलावा सामान्य सेटिंग opcache.enable = 0 है। लेकिन यह आवश्यक नहीं है कि मामले में मदद मिलती है
— कॉन्स्टेंटिन इवानोव
यह इस प्रश्न का स्वीकृत उत्तर होना चाहिए। Php.ini में प्रलेखन के अनुसार, output_buffering को उठाना उत्तर नहीं है, क्योंकि इससे आपकी वेबसाइट या एप्लिकेशन पर नकारात्मक दुष्प्रभाव पड़ सकते हैं।
— ब्लूकोला
41

यदि आप लिनक्स बॉक्स पर हैं, तो कमांड लाइन पर यह कोशिश करें 

export USE_ZEND_ALLOC=0
— Hittz
स्रोत
इसने मुझे बचाया! मैं इसे php-fpm सेवा फ़ाइल (
— सिस्टमड
इसने मेरे लिए यह किया। इस लाइन को जोड़ने के लिए याद रखें /etc/apache2/envvarsअगर आप इसे पीपा (एप्ट) से अपाचे और php दोनों के साथ ubuntu सर्वर पर चला रहे हैं। जब मैंने इसे ondrej के रिपॉजिटरी से इंस्टॉल किया तो PHP 7.0-RC4 ने इस एरर को फेंकना शुरू कर दिया।
— पेड्रो कॉर्डेइरो
और यह भी खिड़कियों पर काम करता है:set USE_ZEND_ALLOC=0
— नबी
22

के लिए जाँच करें unset()। सुनिश्चित करें कि आप डिस्ट्रक्टर्स में (या समतुल्य) का unset()संदर्भ नहीं देते हैं $thisऔर डिस्ट्रक्टर्स में unset()एस उसी संदर्भ ऑब्जेक्ट काउंट को ड्रॉप करने का कारण नहीं बनता है। 0. मैंने कुछ शोध किया है और पाया है कि आमतौर पर ढेर का कारण बनता है। भ्रष्टाचार।

Zend_mm_heap दूषित त्रुटि के बारे में एक PHP बग रिपोर्ट है । [2011-08-31 07:49 UTC] f dot ardelian at gmail dot comएक उदाहरण के लिए टिप्पणी देखें कि इसे कैसे पुन: पेश किया जाए।

मुझे लगता है कि अन्य सभी "समाधान" (परिवर्तन php.ini, कम मॉड्यूल के साथ स्रोत से PHP संकलित करें), बस समस्या को छिपाते हैं।

— f.ardelian
स्रोत
6
मैं साधारण html डोम के साथ इस मुद्दे को प्राप्त कर रहा था, और एक परेशान से बदलकर $ simplehtmldom-> स्पष्ट () जिसने मेरी समस्याओं को हल किया, धन्यवाद!
— अलेक्सबीर
9

मेरे लिए पिछले जवाबों में से कोई भी काम नहीं किया, जब तक कि मैंने कोशिश नहीं की:

opcache.fast_shutdown=0

ऐसा लगता है कि अभी तक काम कर रहा है।

अगर यह मायने रखता है तो मैं PHP 5.6 का उपयोग PHP-FPM और Apachexy_fcgi के साथ कर रहा हूँ ...

— जेसुएस करेरा
स्रोत
1
सभी अलग-अलग परिदृश्यों के लिए "मुझे भी" प्रतिक्रियाओं का एक टन है, लेकिन यह मेरे कॉन्फ़िगरेशन, और उछाल के समान था - इस सटीक परिवर्तन ने मेरे मुद्दे को समाप्त कर दिया है।
— lkraav
6

मेरे मामले में, इस त्रुटि का कारण सरणियों में से एक बहुत बड़ा हो रहा था। मैंने अपनी स्क्रिप्ट को हर पुनरावृत्ति पर सरणी को रीसेट करने के लिए सेट किया है और इस समस्या को हल किया है।

— पायोत्र
स्रोत
यह मेरे लिए यह किया - धन्यवाद! मुझे नहीं लगता था कि कचरा संग्रहकर्ता एक चक्रीय संदर्भ की स्मृति को मुक्त करेगा, इसलिए मैंने इसकी जांच नहीं की।
— आधा-उपवास
5

बग ट्रैकर के अनुसार, सेट करें opcache.fast_shutdown=0। फास्ट शटडाउन अपनी मेमोरी को साफ करने के लिए Zend मेमोरी मैनेजर का उपयोग करता है, यह अक्षम करता है।

— टैको डी वोल्फ
स्रोत
यह हमारे CentOS लिनक्स रिलीज 7.2.1511, PHP 5.5.38 पर "zend_mm_heap दूषित" तय किया गया। अब हम opcode कैश का उपयोग कर फिर से शुरू करने में सक्षम हैं। इसके बिना रात और दिन।
— रिचर्ड जिंसबर्ग
अनुस्मारक के लिए धन्यवाद, यह वास्तव में मेरी समस्या थी!
— वीसलर
4

मुझे नहीं लगता कि यहां एक उत्तर है, इसलिए मैं अपना अनुभव जोड़ूंगा। मैं यादृच्छिक httpd segfaults के साथ इसी त्रुटि को देखा। यह एक cPanel सर्वर था। विचाराधीन लक्षण अपाचे यादृच्छिक रूप से कनेक्शन को रीसेट कर देगा (क्रोम में प्राप्त कोई भी डेटा, या कनेक्शन फ़ायरफ़ॉक्स में रीसेट नहीं किया गया था)। ये प्रतीत होता है यादृच्छिक थे - अधिकांश समय यह काम करता था, कभी-कभी यह नहीं होता था।

जब मैं दृश्य आउटपुट पर आया तो बफरिंग ऑफ थी। इस धागे को पढ़कर, जो आउटपुट बफ़रिंग पर संकेत देता है, मैंने इसे (= 4096) चालू किया, यह देखने के लिए कि क्या होगा। इस बिंदु पर, वे सभी त्रुटियों को दिखाने लगे। यह अच्छा था कि अब त्रुटि दोहराई जा रही थी।

मैंने विस्तार किया और एक्सटेंशन को अक्षम करना शुरू कर दिया। इनमें eaccellerator, पीडीओ, ionCube लोडर, और बहुत सारे है कि देखा संदेह, लेकिन कोई भी मदद की।

मुझे आखिरकार शरारती होम एक्सटेंशन "homeloader.so" के रूप में मिला, जो किसी प्रकार के cPanel-easy-इंस्टॉलर मॉड्यूल के रूप में प्रतीत होता है। हटाने के बाद, मैंने अन्य मुद्दों का अनुभव नहीं किया है।

उस नोट पर, ऐसा प्रतीत होता है कि यह एक सामान्य त्रुटि संदेश है, इसलिए आपका माइलेज इन सभी उत्तरों के साथ अलग-अलग होगा, आपके द्वारा की जा सकने वाली कार्रवाई का सबसे अच्छा तरीका है:

  • त्रुटि को हर बार दोहराएं (क्या स्थितियां?)
  • सामान्य कारक ज्ञात कीजिए
  • किसी भी PHP मॉड्यूल, विकल्प, आदि को चुनिंदा रूप से अक्षम करें (या, यदि आप एक भीड़ में हैं, तो उन सभी को यह देखने के लिए अक्षम करें कि क्या यह मदद करता है, फिर उन्हें तब तक फिर से सक्षम करें जब तक कि यह फिर से टूट न जाए)
  • यदि यह मदद करने में विफल रहता है, तो इनमें से कई उत्तर संकेत देते हैं कि यह कोड से संबंधित हो सकता है। फिर, कुंजी त्रुटि को हर अनुरोध को दोहराने योग्य बनाने के लिए है ताकि आप इसे कम कर सकें। यदि आपको संदेह है कि कोड का एक टुकड़ा ऐसा कर रहा है, तो त्रुटि के बाद एक बार फिर से, बस कोड को हटा दें जब तक कि त्रुटि बंद न हो जाए। एक बार जब यह बंद हो जाता है, तो आपको पता है कि आपके द्वारा हटाए गए कोड का अंतिम टुकड़ा अपराधी था।

उपरोक्त सभी को विफल करते हुए, आप भी इस तरह की चीजों की कोशिश कर सकते हैं:

  • उन्नयन या PHP recompiling। आशा है कि जो कुछ भी बग पैदा कर रहा है वह आपकी समस्या तय है।
  • अपने कोड को एक अलग (परीक्षण) वातावरण में ले जाएँ। यदि यह समस्या को ठीक करता है, तो क्या बदला? php.ini विकल्प? PHP संस्करण? आदि...

सौभाग्य।

— एबी कैरोल
स्रोत
3

मैंने इस मुद्दे के साथ कुश्ती की, एक हफ्ते के लिए, इसने मेरे लिए काम किया, या कम से कम ऐसा लगता है

में php.iniइन परिवर्तनों को करने 

report_memleaks = Off  
report_zend_debug = 0

मेरा सेट अप है 

Linux ubuntu 2.6.32-30-generic-pae #59-Ubuntu SMP  
with PHP Version 5.3.2-1ubuntu4.7

यह काम नहीं किया।

इसलिए मैंने एक बेंचमार्क स्क्रिप्ट का उपयोग करने की कोशिश की, और रिकॉर्डिंग की कोशिश की जहां स्क्रिप्ट लटक रही थी। मुझे पता चला कि त्रुटि से ठीक पहले, एक php ऑब्जेक्ट को तुरंत किया गया था, और ऑब्जेक्ट को जो करना चाहिए था उसे पूरा करने में 3 सेकंड से अधिक समय लगा, जबकि पिछले छोरों में अधिकतम 0.4 सेकंड लगे थे। मैंने इस परीक्षा को कई बार चलाया, और हर बार वही। मैंने हर बार एक नई वस्तु बनाने के बजाय सोचा था, (यहां एक लंबा लूप है), मुझे ऑब्जेक्ट का पुन: उपयोग करना चाहिए। मैंने अब तक एक दर्जन से अधिक बार स्क्रिप्ट का परीक्षण किया है, और मेमोरी त्रुटियां गायब हो गई हैं!

— सैम
स्रोत
1
यह थोड़ी देर के लिए काम किया, लेकिन त्रुटि वापस आ गई है। मैं इसे कैसे रोकूं?
— सैम
यह वही मेरे लिए मैक mvericks पर MAMP PRO 2.1.1 के साथ काम किया।
— मुत्तनमहेश
इस समाधान ने समस्या को स्थायी रूप से ठीक नहीं किया मैं फिर से इस त्रुटि को प्राप्त करना शुरू करता हूं।
— उत्पतमहेश
7
निश्चित रूप से यह समस्या को ठीक करने के बजाय त्रुटियों की रिपोर्टिंग को बंद कर रहा है?
— रॉबर्ट वेंट
2

किसी भी मॉड्यूल के लिए देखें जो बफरिंग का उपयोग करता है, और चुनिंदा रूप से इसे अक्षम करता है।

मैं CentOS 4.8 पर PHP 5.3.5 चला रहा हूं, और ऐसा करने के बाद मैंने पाया कि एक्सेलरेटर को अपग्रेड की जरूरत है।

— स्कॉट डेवी
स्रोत
2

मैं सिर्फ इस मुद्दे के साथ ही एक सर्वर पर था, और मूल कारण APC था। मैंने php.ini फ़ाइल में "apc.so" एक्सटेंशन पर टिप्पणी की, अपाचे को फिर से लोड किया, और साइटें सही तरीके से वापस आ गईं।

— वांस लुकास
स्रोत
2

मैंने ऊपर सब कुछ करने की कोशिश की है zend.enable_gc = 0- और केवल विन्यास सेटिंग, जिसने मेरी मदद की।

PHP 5.3.10-1ubuntu3.2 के साथ सुहोसिन-पैच (cli) (निर्मित: Jun 13 2012 17:19:58)

— Bethrezen
स्रोत
2

मुझे PHP के लिए Mongo 2.2 ड्राइवर का उपयोग करने में यह त्रुटि आई:

$collection = $db->selectCollection('post');
$collection->ensureIndex(array('someField', 'someOtherField', 'yetAnotherField'));

^ ^ काम नहीं करता है

$collection = $db->selectCollection('post');
$collection->ensureIndex(array('someField', 'someOtherField')); 
$collection->ensureIndex(array('yetAnotherField'));

^ ^ काम करता है! (?!)

— hernanc
स्रोत
इस जवाब ने मुझे डिबग करने में मदद की, मानगो मुद्दे के रास्ते पर। मेरे मामले में, PHP 5.6 + Mongo 1.6.9 ड्राइवर, zend_mm_heap दूषित संदेश को फेंक दिया गया था जब पुनरावृति और क्वेरी मानों को पहले से पॉप्युलेट किए गए सरणी सेforeach(selectCollection()->find()) { $arr = .. }
— Mihai MATEI
2

PHP 5.3 पर, बहुत खोज के बाद, यह वह समाधान है जो मेरे लिए काम करता है:

मैंने इस पृष्ठ के लिए PHP कचरा संग्रह को जोड़कर निष्क्रिय कर दिया है:

<? gc_disable(); ?>

समस्याग्रस्त पृष्ठ के अंत में, जिसने सभी त्रुटियों को गायब कर दिया।

स्रोत ।

— KUF
स्रोत
2

मुझे लगता है कि बहुत सारे कारण इस समस्या का कारण बन सकते हैं। और मेरे मामले में, मैं 2 वर्गों को एक ही नाम देता हूं, और एक दूसरे को लोड करने का प्रयास करेगा।

class A {} // in file a.php
class A // in file b.php
{
  public function foo() { // load a.php }
}

और यह मेरे मामले में इस समस्या का कारण बनता है।

(लार्वा ढांचे का उपयोग करके, php कारीगर db: वास्तविक में बीज)

— Yarco
स्रोत
1

मेरे पास यही मुद्दा था और जब मेरे पास सत्र के लिए एक गलत IP था। memcached सत्रों के लिए save_path। इसे सही आईपी में बदलने से समस्या ठीक हो गई।

— ट्रैविस डेरौइन
स्रोत
1

यदि आप लक्षण का उपयोग कर रहे हैं और विशेषता वर्ग के बाद लोड की गई है (यानी ऑटोलडिंग का मामला) तो आपको पहले से ही लोड करने की आवश्यकता है।

https://bugs.php.net/bug.php?id=62339

नोट: यह बग बहुत यादृच्छिक है; यह प्रकृति के कारण है।

— srcspider
स्रोत
1

मेरे लिए समस्या pdo_mysql का उपयोग कर रही थी। क्वेरी ने 1960 के परिणाम लौटाए। मैंने 1900 रिकॉर्ड वापस करने की कोशिश की और यह काम करता है। तो समस्या pdo_mysql और बहुत बड़ी सरणी है। मैंने मूल mysql एक्सटेंशन के साथ क्वेरी फिर से लिखी और यह काम किया।

$link = mysql_connect('localhost', 'user', 'xxxx') or die(mysql_error());
mysql_select_db("db", $link);

अपाचे ने पिछली किसी त्रुटि की सूचना नहीं दी थी। 

zend_mm_heap corrupted
zend_mm_heap corrupted
zend_mm_heap corrupted
[Mon Jul 30 09:23:49 2012] [notice] child pid 8662 exit signal Segmentation fault (11)
[Mon Jul 30 09:23:50 2012] [notice] child pid 8663 exit signal Segmentation fault (11)
[Mon Jul 30 09:23:54 2012] [notice] child pid 8666 exit signal Segmentation fault (11)
[Mon Jul 30 09:23:55 2012] [notice] child pid 8670 exit signal Segmentation fault (11)
— ब्रॉडबैंड
स्रोत
1

"zend_mm_heap दूषित" का अर्थ है स्मृति प्रबंधन की समस्याएं। किसी भी PHP मॉड्यूल के कारण हो सकता है। मेरे मामले में एपीसी स्थापित करने से काम चला। सिद्धांत रूप में अन्य संकुल जैसे eAccelerator, XDebug आदि भी मदद कर सकते हैं। या, यदि आपके पास उस तरह के मॉड्यूल स्थापित हैं, तो उन्हें बंद करने का प्रयास करें।

— Muto
स्रोत
1

मैं एक php एक्सटेंशन लिख रहा हूं और इस समस्या का सामना भी कर रहा हूं। जब मैं अपने विस्तार से जटिल मापदंडों के साथ एक बाहरी फ़ंक्शन को कॉल करता हूं, तो यह त्रुटि पॉप अप होती है।

कारण यह है कि मैं बाहरी कार्य में पैरामीटर (चार *) के लिए मेमोरी आवंटित नहीं कर रहा हूं। यदि आप एक ही तरह का एक्सटेंशन लिख रहे हैं, तो कृपया इस पर ध्यान दें।

— cedricliang
स्रोत
0

मेरे लिए, यह ZendDebugger था जिसने मेमोरी लीक कर दी और MemoryManager को क्रैश कर दिया।

मैंने इसे अक्षम कर दिया है और मैं वर्तमान में एक नए संस्करण की खोज कर रहा हूं। अगर मुझे एक नहीं मिल रहा है, तो मैं xdebug पर जा रहा हूं ...

— structed
स्रोत
0

क्योंकि मुझे इसका कोई हल नहीं मिला, मैंने अपने LAMP वातावरण को अपग्रेड करने का निर्णय लिया। मैं PHP 5.3.x के साथ Ubuntu 10.4 LTS पर गया। ऐसा लगता है कि मेरे लिए समस्या बंद हो गई है।

— bkulyk
स्रोत
0

मेरे मामले में, मैं कोड में निम्नलिखित भूल गया:

);

मैं इधर-उधर कोड में खेलता रहा और इसे भूल गया - कुछ जगहों पर मुझे ढेर भ्रष्टाचार मिला, कुछ मामलों में सिर्फ सादे राजपूत ":

[बुध जून ० child:२३:२१ २०११] [नोटिस] बच्चा ५ exit२० एक्जिट सिग्नल सेगमेंटेशन फॉल्ट (११)

मैं मैक 10.6.7 और xampp पर हूं।

— dsomnus
स्रोत
0

मैंने इस त्रुटि और SIGSEGV के पुराने कोड को चलाने पर भी ध्यान दिया है जो PHP 5.2+ में इसे चलाने के दौरान संदर्भों को स्पष्ट रूप से लागू करने के लिए 'और' का उपयोग करता है।

— फिलिप व्हेलन
स्रोत
0

स्थापना 

assert.active = 0

php.ini ने मेरे लिए मदद की (इसने php5UTF8पुस्तकालय में प्रकार के दावे बंद कर दिए और zend_mm_heap corruptedचला गया)

— Vasiliy
स्रोत
0

मेरे लिए समस्या दुर्घटनाग्रस्त हो चुके डेमॉन की थी, क्योंकि PHP को मेम्केड में सत्र जानकारी संग्रहीत करने के लिए कॉन्फ़िगर किया गया था। यह 100% सीपीयू और अभिनय अजीब खा रहा था। मेमकेश्ड रीस्टार्ट के बाद समस्या दूर हो गई है।

— जस्टिनस जारोनिस
स्रोत
0

चूंकि किसी भी अन्य उत्तर ने इसे संबोधित नहीं किया, इसलिए मुझे php 5.4 में यह समस्या हुई जब मैंने गलती से एक अनंत लूप चलाया।

— मिकायला माकी
स्रोत
0

कुछ सुझाव जो कुछ मदद कर सकते हैं

फेडोरा 20, php 5.5.18

public function testRead() {
    $ri = new MediaItemReader(self::getMongoColl('Media'));

    foreach ($ri->dataReader(10) as $data) {
       // ...
    }
}

public function dataReader($numOfItems) {
    $cursor = $this->getStorage()->find()->limit($numOfItems);

    // here is the first place where "zend_mm_heap corrupted" error occurred
    // var_dump() inside foreach-loop and generator
    var_dump($cursor); 

    foreach ($cursor as $data) {
        // ...
        // and this is the second place where "zend_mm_heap corrupted" error occurred
        $data['Geo'] = [
            // try to access [0] index that is absent in ['Geo']
            'lon' => $data['Geo'][0],
            'lat' => $data['Geo'][1]
        ];
        // ...
        // Generator is used  !!!
        yield $data;
    }
}

var_dummp () का उपयोग करना वास्तव में कोई त्रुटि नहीं है, इसे केवल डिबगिंग के लिए रखा गया था और इसे उत्पादन कोड पर हटा दिया जाएगा। लेकिन वास्तविक स्थान जहां zend_mm_heap हुआ था, वह दूसरा स्थान है।

— lexand
स्रोत
0

मैं यहाँ भी उसी स्थिति में था, ऊपर कुछ भी मदद नहीं की, और अधिक गंभीरता से जाँचने पर मुझे अपनी समस्या का पता चला, इसमें कोशिश है कि मरने के बाद (हैडर ()) बफर में कुछ आउटपुट भेजने के बाद, कोड में ऐसा करने वाला व्यक्ति CakePHP संसाधनों के बारे में भूल गया। और एक सिमेंट नहीं बनाया "रिटर्न $ दिस-> रिडायरेक्ट ($ url)"।

कुएं को फिर से आविष्कार करने की कोशिश कर रहा था, यह समस्या थी।

मुझे आशा है कि यह संबंध किसी की मदद करेगा!

— न्यूटन पासक्लिनी फिल्हो
स्रोत
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.