สมมติว่ากระบวนการทำงานในสภาพแวดล้อมที่มีตัวคั่น:
(
ulimit ... -v ... -t ... -x 0 ...
./program
)
โปรแกรมถูกยกเลิก
อาจมีสาเหตุหลายประการ: เกินขีด จำกัด หน่วยความจำ / เวลา / ไฟล์; segfault ง่าย ๆ หรือการเลิกจ้างปกติด้วยรหัสส่งคืน 0
จะตรวจสอบสาเหตุของการยกเลิกโปรแกรมได้อย่างไรโดยไม่ต้องแก้ไขโปรแกรม
PS ฉันหมายถึง "เมื่อได้รับไบนารี" บางทีเสื้อคลุม (ptrace-ing ฯลฯ ) อาจช่วยได้บ้าง?
คำตอบ:
โดยทั่วไปแล้วฉันไม่คิดว่าคุณจะโชคร้าย (ระบบปฏิบัติการบางระบบอาจมีให้ แต่ฉันไม่ทราบถึงสิ่งที่ฉันรู้ว่าสนับสนุน)
เอกสารอ้างอิงสำหรับข้อ จำกัด ทรัพยากร: getrlimitจาก POSIX 2008
RLIMIT_CPUใช้ตัวอย่างเช่นขีด จำกัด ของ CPU
SIGXCPUSIGKILLหากคุณสามารถเกี่ยวกับโปรแกรมของคุณคุณสามารถบอกได้ว่ามันถูกฆ่าตายโดยwait() SIGXCPUแต่คุณไม่สามารถแยกแยะความแตกต่างที่SIGKILLถูกส่งไปเพื่อฝ่าฝืนข้อ จำกัด อย่างหนักจากการฆ่าแบบธรรมดาจากภายนอก ยิ่งไปกว่านั้นหากโปรแกรมจัดการกับXCPUคุณจะไม่เห็นเลยว่าจากภายนอก
RLIMIT_FSIZEสิ่งเดียวกันสำหรับ คุณสามารถดูSIGXFSZจากwait()สถานะหากโปรแกรมไม่จัดการ แต่เมื่อเกินขีด จำกัด ขนาดไฟล์สิ่งเดียวที่เกิดขึ้นคือ I / O เพิ่มเติมที่พยายามทดสอบขีด จำกัด นั้นอีกครั้งจะได้รับเพียงอย่างEFBIGเดียว - สิ่งนี้จะได้รับการจัดการ (หรือไม่น่าเสียดาย) โดยโปรแกรมภายใน หากโปรแกรมจัดการSIGXFSZเช่นเดียวกับด้านบน - คุณจะไม่รู้เกี่ยวกับมัน
RLIMIT_NOFILE? คุณไม่ได้รับสัญญาณด้วยซ้ำ openและเพื่อน ๆ ก็กลับEMFILEไปที่โปรแกรม มันไม่ได้ใส่ใจเป็นอย่างอื่นดังนั้นมันจะล้มเหลว (หรือไม่) ไม่ว่าด้วยวิธีใดก็ตามที่มีการกำหนดให้ล้มเหลวในสถานการณ์นั้น
RLIMIT_STACK? ดีมากSIGSEGVไม่สามารถแยกความแตกต่างจากคะแนนของเหตุผลอื่นเพื่อให้ได้รับมอบ (คุณจะรู้ว่านั่นคือสิ่งที่ฆ่ากระบวนการแม้ว่าจากwaitสถานะ)
RLIMIT_ASและRLIMIT_DATAจะทำmalloc()และคนอื่น ๆ จะเริ่มล้มเหลว (หรือรับSIGSEGVถ้าขีด จำกัด AS ถูกกระทบในขณะที่พยายามขยายสแต็กบน Linux) ถ้าโปรแกรมนั้นเขียนได้ดีมากมันอาจจะล้มเหลวแบบสุ่มพอสมควร ณ จุดนั้น
ดังนั้นโดยทั่วไปความล้มเหลวอาจไม่แตกต่างอย่างเห็นได้ชัดจากเหตุผลการเสียชีวิตของกระบวนการอื่นดังนั้นคุณจึงไม่สามารถมั่นใจได้หรือสามารถจัดการได้อย่างสมบูรณ์จากโปรแกรมในกรณีที่มันตัดสินใจว่า / เมื่อ / วิธีการดำเนินการไม่ใช่คุณ จากด้านนอก.
สิ่งที่ดีที่สุดที่คุณสามารถทำได้เท่าที่ฉันรู้ก็คือเขียนโค้ดที่ใช้ในโปรแกรมของคุณรออยู่และ:
SIGXCPUและSIGXFSZ(AFAIK สัญญาณเหล่านั้นจะถูกสร้างขึ้นโดยระบบปฏิบัติการสำหรับปัญหาการ จำกัด ทรัพยากร) ขึ้นอยู่กับความต้องการที่แน่นอนของคุณคุณสามารถสันนิษฐานได้SIGKILLและSIGSEGVเกี่ยวข้องกับข้อ จำกัด ของทรัพยากร แต่นั่นก็เป็นเรื่องเล็กน้อยgetrusage(RUSAGE_CHILDREN,...)การนำไปใช้ของคุณเพื่อรับคำแนะนำเกี่ยวกับสิ่งอื่นสิ่งอำนวยความสะดวกเฉพาะสำหรับ OS อาจมีอยู่เพื่อช่วยเหลือที่นี่ (อาจเป็นเช่นptraceLinux หรือ Solaris dtrace) หรืออาจเป็นเทคนิคการดีบั๊กชนิดหนึ่ง
(ฉันหวังว่าคนอื่นจะตอบด้วยเวทมนตร์บางอย่างที่ฉันไม่รู้)
LD_PRELOADไอเอ็นจีว่าเส้นเขตแดนของคุณ "ไม่ได้ปรับเปลี่ยนกระบวนการ" ข้อ จำกัด และมันจะช่วยเล็กน้อย แต่ไม่ได้จริงๆ - malloc, brk, sbrkและmmapจะล้มเหลวด้วยENOMEMตรงเช่นถ้าคุณเป็นจริงในสถานการณ์ที่หน่วยความจำต่ำ (แต่ต่ำกว่าขีด จำกัด หน่วยความจำ) กำหนดเวลาคือRLIMIT_CPUฉันไม่รู้เวลา จำกัด ของนาฬิกาแขวน
brkขอขอบคุณสำหรับการสร้างความมั่นใจเกี่ยวกับฉัน ตามที่ฉันเห็นความต้องการ 'โปรแกรมไม่ได้จัดการสัญญาณ X, Y, Z ... ' จะแก้ปัญหาของ SIGXCPU, SIGXFSZ, SIGSEGV ขอบคุณ waitpid (ถ้าฉันผิดโปรดแก้ไขฉันด้วย)
brkขอขอบคุณสำหรับการสร้างความมั่นใจเกี่ยวกับฉัน อย่างที่ฉันเห็นความต้องการ 'โปรแกรมไม่ได้จัดการสัญญาณ X, Y, Z ... ' จะแก้ปัญหาของ SIGXCPU, SIGXFSZ, SIGSEGV ขอบคุณ waitpid ฉันถูกไหม?
ฉันกำลังทำงานบางอย่างเกี่ยวกับปัญหาเดียวกัน ฉันสามารถแก้ปัญหาบางส่วนได้ ฉันใช้ระบบตรวจสอบระบบแล้ว คุณสามารถติดตามงานที่ [1]
mallocแต่น่าเสียดายที่มันไม่ได้แก้ปัญหาหน่วยความจำโดยทั่วไปทำให้เกิดโดยทั่วไปเกี่ยวกับการโทรของระบบbrk(ฉันใช่ไหม?)