ทันใดนั้นฉันก็ประสบปัญหากับแอปพลิเคชันที่ฉันไม่เคยมีมาก่อน ฉันตัดสินใจตรวจสอบบันทึกข้อผิดพลาดของ Apache และพบข้อความแสดงข้อผิดพลาดว่า "zend_mm_heap เสียหาย" สิ่งนี้หมายความว่า.

ระบบปฏิบัติการ: Fedora Core 8 Apache: 2.2.9 PHP: 5.2.6

หลังจากลองผิดลองถูกมากมายฉันพบว่าถ้าฉันเพิ่มoutput_bufferingค่าในไฟล์ php.ini ข้อผิดพลาดนี้จะหายไป

นี่ไม่ใช่ปัญหาที่จำเป็นต้องแก้ไขได้โดยการเปลี่ยนตัวเลือกการกำหนดค่า

การเปลี่ยนตัวเลือกการกำหนดค่าบางครั้งอาจส่งผลในเชิงบวก แต่ก็สามารถทำให้สิ่งต่างๆแย่ลงหรือไม่ทำอะไรเลย

ลักษณะของข้อผิดพลาดมีดังนี้:

#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

การรันโค้ดด้วย valgrind คุณจะเห็นข้อผิดพลาดของหน่วยความจำจำนวนมากซึ่งเป็นข้อผิดพลาดในการแบ่งส่วน:

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หน่วยความจำที่จัดสรรเป็นฮีป ฮีปหมายถึงพื้นที่ของหน่วยความจำที่พร้อมใช้งานสำหรับโปรแกรมขณะรันไทม์เนื่องจากโปรแกรมร้องขออย่างชัดเจน (กับ malloc ในกรณีของเรา)

หากคุณเล่นกับรหัสที่น่ากลัวคุณจะพบว่าข้อความที่ไม่ถูกต้องที่เห็นได้ชัดทั้งหมดไม่ได้ส่งผลให้เกิดความผิดพลาดในการแบ่งส่วน

ฉันทำข้อผิดพลาดเหล่านั้นอย่างชัดเจนในโค้ดตัวอย่าง แต่ข้อผิดพลาดประเภทเดียวกันนี้เกิดขึ้นได้ง่ายมากในสภาพแวดล้อมที่มีการจัดการหน่วยความจำ: หากโค้ดบางตัวไม่รักษาการอ้างอิงของตัวแปร (หรือสัญลักษณ์อื่น ๆ ) ด้วยวิธีที่ถูกต้องตัวอย่างเช่น ถ้าฟรีมันเร็วเกินไปโค้ดอีกชิ้นอาจอ่านจากหน่วยความจำที่ว่างอยู่แล้วถ้ามันเก็บที่อยู่ผิดรหัสชิ้นอื่นอาจเขียนไปยังหน่วยความจำที่ไม่ถูกต้องมันอาจจะฟรีสองครั้ง ...

สิ่งเหล่านี้ไม่ใช่ปัญหาที่สามารถแก้ไขได้ใน PHP แต่ต้องได้รับความสนใจจากนักพัฒนาภายใน

แนวทางปฏิบัติควรเป็น:

1. เปิดรายงานข้อบกพร่องบนhttp://bugs.php.net
   • หากคุณมี segfault ให้ลองระบุbacktrace
   • รวมข้อมูลการกำหนดค่าให้มากที่สุดเท่าที่เหมาะสมโดยเฉพาะอย่างยิ่งหากคุณใช้ opcache รวมระดับการเพิ่มประสิทธิภาพ
   • หมั่นตรวจสอบรายงานข้อบกพร่องสำหรับการอัปเดตอาจมีการขอข้อมูลเพิ่มเติม
2. หากคุณโหลด opcache ไว้ให้ปิดใช้งานการเพิ่มประสิทธิภาพ
   • ฉันไม่ได้เลือก opcache มันเยี่ยมมาก แต่การเพิ่มประสิทธิภาพบางอย่างเป็นที่ทราบกันดีว่าทำให้เกิดข้อผิดพลาด
   • หากไม่ได้ผลแม้ว่าโค้ดของคุณอาจช้าลงให้ลองยกเลิกการโหลด opcache ก่อน
   • หากมีการเปลี่ยนแปลงหรือแก้ไขปัญหาให้อัปเดตรายงานข้อบกพร่องที่คุณทำ
3. ปิดการใช้งานส่วนขยายที่ไม่จำเป็นทั้งหมดพร้อมกัน
   • เริ่มเปิดใช้งานส่วนขยายทั้งหมดของคุณทีละรายการทดสอบอย่างละเอียดหลังจากเปลี่ยนการกำหนดค่าแต่ละครั้ง
   • หากคุณพบส่วนขยายของปัญหาให้อัปเดตรายงานข้อบกพร่องของคุณพร้อมข้อมูลเพิ่มเติม
4. กำไร.

อาจไม่มีผลกำไรใด ๆ ... ฉันบอกว่าในตอนเริ่มต้นคุณอาจสามารถหาวิธีเปลี่ยนอาการของคุณได้โดยยุ่งกับการกำหนดค่า แต่นี่เป็นผลกระทบอย่างมากและพลาดและไม่ช่วยในครั้งต่อไปที่คุณมีzend_mm_heap corruptedข้อความเดียวกันมีตัวเลือกการกำหนดค่ามากมายเท่านั้น

เป็นเรื่องสำคัญมากที่เราจะต้องสร้างรายงานข้อบกพร่องเมื่อเราพบข้อบกพร่องเราไม่สามารถสันนิษฐานได้ว่าบุคคลต่อไปที่จะแก้ไขข้อบกพร่องนั้นจะทำเช่นนั้น ... เป็นไปได้มากกว่านั้นการแก้ปัญหาที่แท้จริงจะไม่ลึกลับหากคุณทำ คนที่เหมาะสมตระหนักถึงปัญหา

USE_ZEND_ALLOC

หากคุณตั้งค่าUSE_ZEND_ALLOC=0ในสภาพแวดล้อมสิ่งนี้จะปิดใช้งานตัวจัดการหน่วยความจำของ Zend เอง ตัวจัดการหน่วยความจำของ Zend ช่วยให้มั่นใจได้ว่าแต่ละคำขอมีฮีปเป็นของตัวเองหน่วยความจำทั้งหมดจะว่างเมื่อสิ้นสุดคำขอและได้รับการปรับให้เหมาะสมกับการจัดสรรหน่วยความจำในขนาดที่เหมาะสมสำหรับ PHP

การปิดใช้งานจะปิดใช้งานการเพิ่มประสิทธิภาพเหล่านั้นที่สำคัญกว่านั้นอาจทำให้เกิดการรั่วไหลของหน่วยความจำเนื่องจากมีโค้ดส่วนขยายจำนวนมากที่อาศัย Zend MM เพื่อเพิ่มหน่วยความจำเมื่อสิ้นสุดคำขอ (tut, tut)

นอกจากนี้ยังอาจซ่อนอาการ แต่ฮีปของระบบอาจเสียหายในลักษณะเดียวกับฮีปของ Zend

มันอาจดูเหมือนจะใจกว้างมากขึ้นหรือน้อยใจกว้าง แต่แก้ไขสาเหตุของปัญหาที่เกิดขึ้นมันไม่สามารถ

ความสามารถในการปิดการใช้งานทั้งหมดเป็นไปเพื่อประโยชน์ของนักพัฒนาภายใน คุณไม่ควรปรับใช้ PHP โดยปิด Zend MM

ฉันได้รับข้อผิดพลาดเดียวกันนี้ภายใต้ PHP 5.5 และการเพิ่มการบัฟเฟอร์เอาต์พุตไม่ได้ช่วยอะไร ฉันไม่ได้ใช้ APC ด้วยนั่นก็ไม่ใช่ปัญหา ในที่สุดฉันก็ติดตามมันลงไปที่opcacheฉันต้องปิดการใช้งานจาก cli มีการตั้งค่าเฉพาะสำหรับสิ่งนี้:

opcache.enable_cli=0

เมื่อเปลี่ยน zend_mm_heap ข้อผิดพลาดที่เสียหายก็หายไป

หากคุณใช้กล่อง Linux ให้ลองทำตามคำสั่ง

export USE_ZEND_ALLOC=0

ตรวจสอบunset()s. ตรวจสอบให้แน่ใจว่าคุณไม่ได้unset()อ้างอิงถึง$this(หรือสิ่งที่เทียบเท่า) ในตัวทำลายและสิ่งนั้นunset()ในตัวทำลายจะไม่ทำให้จำนวนการอ้างอิงของวัตถุเดียวกันลดลงเป็น 0 ฉันได้ทำการวิจัยและพบว่านั่นคือสิ่งที่มักทำให้เกิดฮีป คอรัปชั่น.

มีรายงานข้อบกพร่องของ PHP เกี่ยวกับข้อผิดพลาดที่เสียหายของ zend_mm_heap ดูความคิดเห็น[2011-08-31 07:49 UTC] f dot ardelian at gmail dot comสำหรับตัวอย่างวิธีการสร้างซ้ำ

ฉันรู้สึกว่า "โซลูชัน" อื่น ๆ ทั้งหมด (เปลี่ยนแปลงphp.iniรวบรวม PHP จากซอร์สที่มีโมดูลน้อยลง ฯลฯ ) เพียงแค่ซ่อนปัญหา

สำหรับฉันคำตอบก่อนหน้านี้ไม่ได้ผลจนกว่าฉันจะลอง:

opcache.fast_shutdown=0

ดูเหมือนว่าจะใช้งานได้จนถึงขณะนี้

ฉันใช้ PHP 5.6 กับ PHP-FPM และ Apache proxy_fcgi ถ้าเป็นเช่นนั้น ...

ในกรณีของฉันสาเหตุของข้อผิดพลาดนี้เป็นหนึ่งในอาร์เรย์ที่มีขนาดใหญ่มาก ฉันได้ตั้งค่าสคริปต์ของฉันให้รีเซ็ตอาร์เรย์ทุกครั้งที่ทำซ้ำและนั่นก็เป็นการจัดเรียงปัญหา

opcache.fast_shutdown=0เป็นต่อข้อผิดพลาดติดตามชุด การปิดระบบอย่างรวดเร็วใช้ตัวจัดการหน่วยความจำ Zend เพื่อล้างความยุ่งเหยิงซึ่งจะปิดใช้งาน

ฉันไม่คิดว่าจะมีคำตอบเดียวที่นี่ดังนั้นฉันจะเพิ่มประสบการณ์ของฉัน ฉันเห็นข้อผิดพลาดเดียวกันนี้พร้อมกับการสุ่ม httpd segfaults นี่คือเซิร์ฟเวอร์ cPanel อาการที่เป็นปัญหาคือ apache จะรีเซ็ตการเชื่อมต่อแบบสุ่ม (ไม่ได้รับข้อมูลใน chrome หรือการเชื่อมต่อถูกรีเซ็ตใน firefox) สิ่งเหล่านี้ดูเหมือนสุ่ม - เกือบตลอดเวลาที่ใช้งานได้บางครั้งก็ไม่ได้ผล

เมื่อฉันมาถึงการบัฟเฟอร์เอาต์พุตฉากปิดอยู่ เมื่ออ่านหัวข้อนี้ซึ่งบ่งบอกถึงการบัฟเฟอร์เอาต์พุตฉันจึงเปิดใช้งาน (= 4096) เพื่อดูว่าจะเกิดอะไรขึ้น ณ จุดนี้พวกเขาทั้งหมดเริ่มแสดงข้อผิดพลาด นี่เป็นเรื่องดีที่ข้อผิดพลาดนี้สามารถทำซ้ำได้แล้ว

ฉันผ่านและเริ่มปิดการใช้งานส่วนขยาย ในหมู่พวกเขา eaccellerator, pdo, ioncube loader และอีกมากมายที่ดูน่าสงสัย แต่ไม่มีใครช่วย

ในที่สุดฉันก็พบส่วนขยาย PHP ที่ซุกซนเป็น "homeloader.so" ซึ่งดูเหมือนจะเป็นโมดูล cPanel-easy-installer บางประเภท หลังจากนำออกฉันไม่พบปัญหาอื่น ๆ

ในบันทึกนั้นดูเหมือนว่านี่เป็นข้อความแสดงข้อผิดพลาดทั่วไปดังนั้นค่าไมล์ของคุณจะแตกต่างกันไปตามคำตอบเหล่านี้แนวทางปฏิบัติที่ดีที่สุดที่คุณสามารถทำได้:

• ทำให้ข้อผิดพลาดเกิดซ้ำได้ (เงื่อนไขอะไร?) ทุกครั้ง
• ค้นหาปัจจัยร่วม
• เลือกปิดใช้งานโมดูล PHP ตัวเลือกและอื่น ๆ (หรือหากคุณเร่งรีบให้ปิดการใช้งานทั้งหมดเพื่อดูว่าช่วยได้หรือไม่จากนั้นเลือกเปิดใช้งานใหม่จนกว่าจะแตกอีกครั้ง)
• หากสิ่งนี้ไม่สามารถช่วยได้คำตอบเหล่านี้หลายคำบอกเป็นนัยว่าอาจเกี่ยวข้องกับรหัส อีกครั้งที่สำคัญคือทำให้ข้อผิดพลาดเกิดซ้ำทุกคำขอเพื่อให้คุณสามารถ จำกัด ให้แคบลงได้ หากคุณสงสัยว่ามีโค้ดบางส่วนกำลังทำสิ่งนี้อีกครั้งหลังจากที่เกิดข้อผิดพลาดซ้ำแล้วให้ลบโค้ดออกจนกว่าข้อผิดพลาดจะหยุดลง เมื่อหยุดแล้วคุณจะรู้ว่าโค้ดชิ้นสุดท้ายที่คุณลบออกไปคือตัวการ

หากล้มเหลวทั้งหมดข้างต้นคุณสามารถลองทำสิ่งต่างๆเช่น:

• การอัพเกรดหรือคอมไพล์ PHP ใหม่ หวังว่าข้อบกพร่องใด ๆ ที่ทำให้เกิดปัญหาของคุณได้รับการแก้ไข
• ย้ายรหัสของคุณไปยังสภาพแวดล้อม (การทดสอบ) อื่น หากวิธีนี้ช่วยแก้ปัญหาได้มีอะไรเปลี่ยนแปลงบ้าง? php.ini ตัวเลือก? เวอร์ชัน PHP? ฯลฯ ...

โชคดี.

ฉันต่อสู้กับปัญหานี้เป็นเวลาหนึ่งสัปดาห์สิ่งนี้ได้ผลสำหรับฉันหรืออย่างน้อยก็ดูเหมือนว่า

ใน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 วินาที ฉันทำการทดสอบนี้ไม่กี่ครั้งและทุกครั้งก็เหมือนเดิม ฉันคิดว่าแทนที่จะสร้างออบเจ็กต์ใหม่ทุกครั้ง (มีลูปยาวอยู่ที่นี่) ฉันควรใช้อ็อบเจกต์ซ้ำ ฉันได้ทดสอบสคริปต์มากกว่าสิบครั้งแล้วและข้อผิดพลาดของหน่วยความจำก็หายไป!

มองหาโมดูลที่ใช้บัฟเฟอร์และเลือกปิดใช้งาน

ฉันใช้ PHP 5.3.5 บน CentOS 4.8 และหลังจากทำสิ่งนี้ฉันพบว่า eaccelerator จำเป็นต้องอัปเกรด

ฉันเพิ่งมีปัญหานี้เช่นกันบนเซิร์ฟเวอร์ที่ฉันเป็นเจ้าของและสาเหตุหลักคือ APC ฉันแสดงความคิดเห็นเกี่ยวกับส่วนขยาย "apc.so" ในไฟล์ php.ini โหลด Apache ใหม่และไซต์ก็สำรองข้อมูลทันที

ฉันได้ลองทุกอย่างข้างต้นแล้วzend.enable_gc = 0- การตั้งค่าการกำหนดค่าเดียวที่ช่วยฉันได้

PHP 5.3.10-1ubuntu3.2 พร้อม Suhosin-Patch (cli) (สร้าง: 13 มิ.ย. 2555 17:19:58 น.)

ฉันมีข้อผิดพลาดนี้โดยใช้ไดรเวอร์ Mongo 2.2 สำหรับ PHP:

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

^^ ไม่ได้ผล

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

^^ ได้ผล! (?!)

บน PHP 5.3 หลังจากการค้นหาจำนวนมากนี่เป็นวิธีแก้ปัญหาที่เหมาะกับฉัน:

ฉันได้ปิดใช้งานการรวบรวมขยะ PHPสำหรับหน้านี้โดยเพิ่ม:

<? gc_disable(); ?>

ไปยังจุดสิ้นสุดของหน้าที่มีปัญหาซึ่งทำให้ข้อผิดพลาดทั้งหมดหายไป

แหล่ง

ฉันคิดว่าหลายเหตุผลอาจทำให้เกิดปัญหานี้ และในกรณีของฉันฉันตั้งชื่อคลาส 2 คลาสด้วยชื่อเดียวกันและอีกอันจะพยายามโหลดคลาสอื่น

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

และมันทำให้เกิดปัญหานี้ในกรณีของฉัน

(ใช้ laravel framework เรียกใช้ php artisan db: seed ในแบบจริง)

ฉันมีปัญหาเดียวกันนี้และเมื่อฉันมี IP ที่ไม่ถูกต้องสำหรับ session.save_path สำหรับเซสชัน memcached การเปลี่ยนเป็น IP ที่ถูกต้องช่วยแก้ปัญหาได้

หากคุณใช้ลักษณะและลักษณะถูกโหลดหลังจากคลาส (เช่นกรณีของการโหลดอัตโนมัติ) คุณต้องโหลดลักษณะก่อน

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

หมายเหตุ: ข้อผิดพลาดนี้เป็นแบบสุ่มมาก เนื่องจากเป็นธรรมชาติ

สำหรับฉันปัญหาคือการใช้ pdo_mysql การค้นหาส่งคืนผลลัพธ์ 1960 ฉันพยายามส่งคืนระเบียน 1900 และใช้งานได้ ดังนั้นปัญหาคือ pdo_mysql และอาร์เรย์ใหญ่เกินไป ฉันเขียนข้อความค้นหาใหม่ด้วยนามสกุล mysql ดั้งเดิมและใช้งานได้

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

Apache ไม่ได้รายงานข้อผิดพลาดใด ๆ ก่อนหน้านี้

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)

"zend_mm_heap เสียหาย" หมายถึงปัญหาเกี่ยวกับการจัดการหน่วยความจำ อาจเกิดจากโมดูล PHP ใดก็ได้ ในกรณีของฉันการติดตั้ง APC ได้ผล ในทางทฤษฎีแพ็คเกจอื่น ๆ เช่น eAccelerator, XDebug เป็นต้นอาจช่วยได้เช่นกัน หรือหากคุณติดตั้งโมดูลประเภทนั้นไว้ให้ลองปิดโมดูลเหล่านี้

ฉันกำลังเขียนนามสกุล php และพบปัญหานี้ด้วย เมื่อฉันเรียกใช้ฟังก์ชันภายนอกที่มีพารามิเตอร์ที่ซับซ้อนจากส่วนขยายของฉันข้อผิดพลาดนี้จะปรากฏขึ้น

เหตุผลคือฉันไม่ได้จัดสรรหน่วยความจำสำหรับพารามิเตอร์ (ถ่าน *) ในฟังก์ชันภายนอก หากคุณกำลังเขียนส่วนขยายประเภทเดียวกันโปรดใส่ใจกับสิ่งนี้

สำหรับฉันมันเป็น ZendDebugger ที่ทำให้หน่วยความจำรั่วไหลและทำให้ MemoryManager พัง

ฉันปิดการใช้งานและฉันกำลังค้นหาเวอร์ชันที่ใหม่กว่า ถ้าหาไม่เจอผมจะเปลี่ยนไปใช้ xdebug ...

เพราะฉันไม่เคยพบวิธีแก้ปัญหานี้ฉันจึงตัดสินใจอัพเกรดสภาพแวดล้อม LAMP ของฉัน ฉันไปที่ Ubuntu 10.4 LTS ด้วย PHP 5.3.x. ดูเหมือนว่าจะหยุดปัญหาสำหรับฉันได้แล้ว

ในกรณีของฉันฉันลืมรหัสต่อไปนี้:

);

ฉันเล่นไปเรื่อย ๆ และลืมมันในรหัสที่นี่และที่นั่น - ในบางแห่งฉันได้รับความเสียหายจากกองบางกรณีก็เป็นเพียงความผิดปกติของ seg:

[พ. 08 มิ.ย. 17:23:21 น. 2554] [ประกาศ] สัญญาณออกของเด็ก pid 5720 ความผิดปกติของการแบ่งส่วน (11)

ฉันใช้ mac 10.6.7 และ xampp

ฉันยังสังเกตเห็นข้อผิดพลาดนี้และ SIGSEGV เมื่อเรียกใช้โค้ดเก่าซึ่งใช้ '&' เพื่อบังคับใช้การอ้างอิงอย่างชัดเจนในขณะที่รันใน PHP 5.2+

การตั้งค่า

assert.active = 0 

ใน php.ini ช่วยฉันได้ (มันปิดการยืนยันประเภทในphp5UTF8ห้องสมุดและzend_mm_heap corruptedจากไป)

สำหรับฉันปัญหาคือ memcached daemon ล้มเหลวเนื่องจาก PHP ได้รับการกำหนดค่าให้เก็บข้อมูลเซสชันใน memcached มันกิน cpu 100% และทำตัวแปลก ๆ หลังจากปัญหาการรีสตาร์ท memcached หายไป

เนื่องจากไม่มีคำตอบอื่นใดที่กล่าวถึงฉันจึงมีปัญหานี้ใน php 5.4 เมื่อฉันวิ่งวนรอบที่ไม่มีที่สิ้นสุดโดยบังเอิญ

เคล็ดลับบางอย่างที่อาจช่วยได้

fedora 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 เกิดขึ้นคือสถานที่ที่สอง

ฉันอยู่ในสถานการณ์เดียวกันที่นี่ไม่มีอะไรข้างต้นช่วยและตรวจสอบอย่างจริงจังมากขึ้นฉันพบปัญหาของฉันมันประกอบด้วย try do die (header ()) หลังจากส่งเอาต์พุตไปยังบัฟเฟอร์คนที่ทำสิ่งนี้ใน Code ลืมทรัพยากร CakePHP และไม่ได้สร้าง simples "return $ this-> redirect ($ url)"

การพยายามประดิษฐ์บ่อน้ำขึ้นมาใหม่นี่คือปัญหา

ฉันหวังว่าสิ่งนี้จะช่วยใครสักคน!