2013-05-02 19 views
6

Edytuj.Kod PHP generuje błąd segmentacji

Otrzymuję błąd segmentacji od operacji trójskładnikowej PHP. Używam PHP (5.4.13).

<?php 

$t = empty($_GET['t2']) ? $_GET['t2'] : 'test'; 
$t = empty($_GET['t2']) ? 'test' : $_GET['t2']; 

echo '<pre>'.print_r($t, true).'</pre>'; 

?> 

Sprawozdanie:

$t = empty($_GET['t2']) ? $_GET['t2'] : 'test'; 
$t = empty($_GET['t2']) ? 'test' : $_GET['t2']; 

wywołuje winy segmentacji (sprawdziłem apache dziennik błędów na ten temat). Skomentowane powyższe instrukcje nie powodują usterki segmentacji.

Wątpię, żeby to był jedyny błąd źródłowy, ale właśnie to udało mi się zawęzić. Prawie wszystkie witryny korzystające z tego php mają teraz ten problem.

Nie sądzę, że to błąd! Bardziej błąd w instalacji php lub w jednej z zależności. Ale ponieważ użyto tylko języka, pomyślałem, że można go łatwo zawęzić.

EDIT: Chciałem wiedzieć, jakie są wspólne problemy, które powoduje błąd segmentacji, a jeśli jeden z nich może być identyfikowane z powyższego kodu tak, że będę wiedział gdzie szukać rozwiązań i jak działają . (To jest pytanie dla tych, którzy zastanawiają się nim)

EDIT 2: Gotowy teraz, nie ma więcej przypisanie w $ _GET, więc myślę, że teraz jest advisable i ważne. Ale błąd nadal istnieje.

EDIT 3: dla valgrind, ślad jest:

==3775== Process terminating with default action of signal 11 (SIGSEGV) 
==3775== Bad permissions for mapped region at address 0x0 
==3775== at 0x0: ??? 
==3775== by 0xF60F9F7: execute (in /opt/rh/php54/root/usr/lib64/httpd/modules/libphp5.so) 
==3775== by 0xF5A619F: zend_execute_scripts (in /opt/rh/php54/root/usr/lib64/httpd/modules/libphp5.so) 
==3775== by 0xF548E87: php_execute_script (in /opt/rh/php54/root/usr/lib64/httpd/modules/libphp5.so) 
==3775== by 0xF650A94: ??? (in /opt/rh/php54/root/usr/lib64/httpd/modules/libphp5.so) 
==3775== by 0x133BAF: ap_run_handler (in /usr/sbin/httpd) 
==3775== by 0x13746D: ap_invoke_handler (in /usr/sbin/httpd) 
==3775== by 0x142B2F: ap_process_request (in /usr/sbin/httpd) 
==3775== by 0x13F9A7: ??? (in /usr/sbin/httpd) 
==3775== by 0x13B6B7: ap_run_process_connection (in /usr/sbin/httpd) 
==3775== by 0x147976: ??? (in /usr/sbin/httpd) 
==3775== by 0x147C45: ??? (in /usr/sbin/httpd) 

i dla gdb jest:

#0 0x0000000000000000 in ??() 
#1 0x00007fc4dd8a49f8 in execute() from /etc/httpd/modules/libphp54-php5.so 
#2 0x00007fc4dd83b1a0 in zend_execute_scripts() from /etc/httpd/modules/libphp54-php5.so 
#3 0x00007fc4dd7dde88 in php_execute_script() from /etc/httpd/modules/libphp54-php5.so 
#4 0x00007fc4dd8e5a95 in ??() from /etc/httpd/modules/libphp54-php5.so 
#5 0x00007fc4e818dbb0 in ap_run_handler() 
#6 0x00007fc4e819146e in ap_invoke_handler() 
#7 0x00007fc4e819cb30 in ap_process_request() 
#8 0x00007fc4e81999a8 in ??() 
#9 0x00007fc4e81956b8 in ap_run_process_connection() 
#10 0x00007fc4e81a1977 in ??() 
#11 0x00007fc4e81a1c46 in ??() 
#12 0x00007fc4e81a2293 in ap_mpm_run() 
#13 0x00007fc4e8179900 in main() 

Finał Edit

Jak podejrzewałem od początku to na pewno pochodzi z uszkodzonej instalacji php i jej rozszerzeń. Kod sam w sobie nie miał problemu, ale domyślam się, że użył jakiejś części błędnej instalacji. Można dodać więcej, ale ponieważ nie znalazłem dokładnej przyczyny i rozwiązania, ale udało mi się sprawić, by działało to ponownie, dziękuję wszystkim za kierowanie mnie do rozwiązania.

+6

Nie sądzę, że ustawienie wartości w '$ _GET' jest uważane za dobrą praktykę. Co chcesz z tym zrobić? – Aquillo

+0

Co oznacza @Aquillo, jest prawdziwe. Jeśli jest to błąd, lepiej jest zgłaszać się do bazy danych błędów PHP. – datasage

+0

Przebiegłem to i nie miałem żadnego uszkodzenia. Jeśli jednak t2 nie jest zdefiniowany, pojawia się błąd dla niezdefiniowanego indeksu: t2.Ale ustawienie wartości, jak wspomniano powyżej, nie jest dobrą praktyką. – o0rebelious0o

Odpowiedz

1

Patrząc na twój kod, nie wierzę, że masz jakiekolwiek błędy.

Powiedziawszy, że masz problemy z wieloma swoimi witrynami. Zastanawiam się, czy dostają się teraz złośliwe roboty, które mogą powodować błąd podobny do tego [Raport o błędach PHP] [1] https://bugs.php.net/bug.php?id=59748. [1] :.

Chciałbym sprawdzić dzienniki i sprawdzić, czy ruch na tych stronach został zmieniony, aby zacząć wykorzystywać ten problem.

+1

Właściwie to była połowa mojej winy w konfiguracji instalacji php i jej rozszerzeń. – khael

Powiązane problemy