mod_perl के तहत MySQL ड्राइवर segfaulting -

Question

समस्या के लिए कहां देखना है मेरे पास एक वेबपैप है जो डेटाबेस को पुनरारंभ करने पर segfaults करता है और यह पुराने कनेक्शन का उपयोग करने का प्रयास करता है। gdb --args apache -X के तहत यह चल रहा है निम्न उत्पादन की ओर जाता है:

Program received signal SIGSEGV, Segmentation fault. 
[Switching to Thread -1212868928 (LWP 16098)] 
0xb7471c20 in mysql_send_query() from /usr/lib/libmysqlclient.so.15 

मैं देख लिया है कि ड्राइवरों और डेटाबेस सभी अद्यतित (DBD::mysql 4.0008, MySQL 5.0.32-Debian_7etch6-लॉग) कर रहे हैं।

Annoyingly मैं एक छोटी सी स्क्रिप्ट के साथ इस पुन: पेश नहीं कर सकते:

use DBI; 
use Test::More tests => 2; 

my $dbh = DBI->connect("dbi:mysql:test", 'root'); 

sub test_db { 
    my ($number) = $dbh->selectrow_array("select 1 "); 
    return $number; 
} 

is test_db, 1, "connected to db"; 

warn "restart db now"; 
getc; 

is test_db, 1, "connected to db"; 

निम्नलिखित में से कौन देता है:

ok 1 - connected to db 
restart db now at dbd-mysql-test.pl line 23. 

DBD::mysql::db selectrow_array failed: MySQL server has gone away at dbd-mysql-test.pl line 17. 
not ok 2 - connected to db 
# Failed test 'connected to db' 
# at dbd-mysql-test.pl line 26. 
#   got: undef 
#  expected: '1' 

यह सही ढंग से व्यवहार करती है, मुझे बता क्यों अनुरोध विफल रहा।

मुझे क्या स्टंप है कि यह segfaulting है, जो इसे नहीं करना चाहिए। जैसा कि यह तब होता है जब पूरा ऐप चल रहा है (जो DBIx::Class का उपयोग करता है) इसे परीक्षण केस में कम करना मुश्किल है।

मुझे इसे डीबग करने के लिए कहां देखना शुरू करना चाहिए? क्या किसी और ने इसे देखा है?

अद्यतन: आगे प्रोडिंग से पता चला कि यह mod_perl के तहत एक लाल हेरिंग था। इसे एक साधारण परीक्षण स्क्रिप्ट में कम करने के बाद मैंने अब DBI mailing list पर पोस्ट किया है। आपके उत्तरों के लिए धन्यवाद।

Answer 1

यह पुराने डीबीडी :: mysql में एक ज्ञात समस्या है। इसे अपग्रेड करें (4.008 अद्यतित नहीं है)।

https://rt.cpan.org/Public/Bug/Display.html?id=37027 से जुड़ी एक साधारण परीक्षण स्क्रिप्ट है जो इस बग को ट्रिगर करेगी।

Answer 2

इसका क्या अर्थ है इसका मतलब यह है कि आपके mod_perl पर्यावरण और जिसकी आप अपनी स्क्रिप्ट के माध्यम से परीक्षण कर रहे थे, के बीच एक अंतर है। कुछ बातें की जांच करने के:

• अपने मोड-पर्ल पर्ल का एक ही संस्करण के साथ संकलित किया गया

• @ कांग्रेस के दोनों

• के लिए एक ही कर रहे हैं आप अपने मोड-पर्ल सेटअप में धागे का उपयोग कर रहे हैं? मुझे विश्वास नहीं है कि डीबीडी :: mysql पूरी तरह से थ्रेड-सुरक्षित है।

Answer 3

मैंने यह समस्या देखी है, लेकिन मुझे यकीन नहीं है कि यह आपके जैसा ही कारण है। क्या आप अपने आवेदन से मेल भेजने के लिए एक निश्चित मॉड्यूल का उपयोग कर रहे हैं (नाम भूल गए हैं, क्षमा करें)? जब हमें किसी प्रोजेक्ट में समस्या थी, तो डिबगिंग के दिनों के बाद हमने पाया कि यह मेल मॉड्यूल ओपन फाइल डिस्क्रिप्टर के साथ अजीब चीजें कर रहा था, फिर कंसोल टूल sendmail नामक एक और प्रक्रिया को फोर्क किया, जिसने फाइल डिस्क्रिप्टर के साथ फिर से अजीब चीजें कीं। मुझे लगता है कि फाइल डिस्क्रिप्टरों में से एक यह है कि यह डेटाबेस के साथ कनेक्शन था, लेकिन मुझे अभी भी इसके बारे में निश्चित नहीं है। जब हम मेल भेजने के लिए किसी अन्य मॉड्यूल पर स्विच करते थे तो समस्या गायब हो गई। शायद यह भी आपके लिए एक लायक है।

Answer 4

यदि आप एक सेगफॉल्ट प्राप्त कर रहे हैं, तो क्या आपके पास कोर फ़ाइल है? यदि नहीं, तो ulimit -c जांचें। यदि वह 0 लौटाता है, तो आपका सिस्टम कोर फाइल नहीं बनाएगा और आपको इसे बदलना होगा। यदि आपके पास कोर फ़ाइल है, तो आप इसे डीबग करने के लिए जीडीबी या इसी तरह के टूल्स का उपयोग कर सकते हैं। यह विशेष रूप से मजेदार नहीं है, लेकिन यह संभव है।

gbd /usr/bin/httpd core 

वेब के बारे में बिखरे हुए debugging core files के लिए ट्यूटोरियल के बहुत सारे हैं: आदेश के शुरू होने से कुछ ऐसी दिखाई देगी।

अद्यतन: बस ensuring you get core dumps from mod_perl के लिए एक संदर्भ मिला। यह मदद करनी चाहिए।