![]() |
![]() ![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 3 Pomógł: 0 Dołączył: 26.04.2003 Skąd: Konstantynów Łódzki Ostrzeżenie: (0%) ![]() ![]() |
Witam,
Mam problem z systemem, który piszemy z kolegami. Otóż co pewien czas strona budowana poprzez kilkanaście zapytań (SELECT) nie wyświetla się (po prostu biała strona, zero kodu). Błąd ten można osiągnąć częściej Co ciekawsze... Mamy listę rekordów z pewnej tabelki. Do każdego rekordu jest opcja usuń. Po kliknięciu w ten przycisk, jesteśmy przekierowywani na stronę, w której jedynym kodem jest wywołanie usunięcia rekordu (DELETE), przekierowanie headerem do listy rekordów i exit, aby wymusić natychmiastowe przekierowanie. Po powrocie do listy rekordów okazuje się, że rekord nadal tam jest, jednak ponowna próba skasowania kończy się naszym wyjątkiem: rekord nieistnieje. Oczywiście jeśliby odczekać dłużej do obejrzenia listy rekordów - wszystko jest ok. Do obsługi bazy używamy MySQLi (-> query ()). MySQLi jest tworzone podczas działania skryptu co najwyżej raz (specjalny Singleton). Ze względu na problem z wysyłaniem nagłówków (sesja, header), używamy ob_start (), ob_flush (). Mimo, że system ten piszemy od ponad 2 tygodni, problemy zaczęły się wczoraj (a raczej jakiś diametralnych zmian w tym czasie nie było) jakoś koło 14. Dzisiaj z rana przenieśliśmy się na zupełnie inny serwer. Przez jakiś czas wszystko śmigało, jednakże też koło 14 zaczęło się walić. Co śmieszniejsze, w innym projekcie na tym drugim serwerze, którego szczególnie nie modyfikowaliśmy też zaczął się ten problem pojawiać (jak na razie zaobserwowałem nieładowanie się strony). A z tego co pamiętam, tam nieużywamy MySQLi a zwykłego strukturalnego mysql_connect, mysql_query itd. Obecnie przeglądam logi (robię to pierwszy raz). Podejrzewam, że z jakiegoś powodu skrypty przeciążają serwery. Niemal w każdej sekundzie mamy: [Tue Jul 21 14:14:56 2009] [notice] child pid 4983 exit signal Segmentation fault (11) Co jakiś czas: [Tue Jul 21 14:14:56 2009] [error] [client 192.168.0.105] File does not exist: ... No i mój ulubiony: [Tue Jul 21 14:15:30 2009] [error] [client 192.168.0.105] ALERT - canary mismatch on efree() - heap overflow detected (attacker [[IP]], file [[ADRES_PLIKU]]), referer: [[INNY_ADRES_PLIKU]] Problem ten przede wszystkim odczuwamy na Windows. Stąd też mój inny trop. Być może jakiś wirus wkradł się nam w stronę (poprzez kradzież danych z total commandera). Niedawno czytałem o tego typu wirusach, które następnie wklejają jakiś złośliwy kod w stronach internetowych (ale nie wiem dokładnie co to za kod itp.). |
|
|
![]()
Post
#2
|
|
![]() Grupa: Zarejestrowani Postów: 359 Pomógł: 12 Dołączył: 16.01.2009 Ostrzeżenie: (0%) ![]() ![]() |
Witam,
zapytania w MySQL(i) są wykonywane natychmiastowo, chyba że użyjesz transkakcji. Polegają one na wstrzymaniu wszystkich zapytań do momentu, kiedy odpalimy funkcję zatwierdzającą. Przydaje się to w sytuacji, gdy zmieniamy różne dane, i koniecznie wszystkie zapytanie MUSZĄ SIĘ WYKONAĆ i w ogóle nie wchodzi w grę jakieś niepowodzenie, ponieważ zmieniane dane nie mają sensu oddzielnie. Co do Twojej sprawy z DELETE: Podejrzewam, że coś nie gra w skrypcie kasowania. Mógłbyś podać jego kod? Cytat Co ciekawsze... Mamy listę rekordów z pewnej tabelki. Do każdego rekordu jest opcja usuń. Po kliknięciu w ten przycisk, jesteśmy przekierowywani na stronę, w której jedynym kodem jest wywołanie usunięcia rekordu (DELETE), przekierowanie headerem do listy rekordów i exit, aby wymusić natychmiastowe przekierowanie. Po powrocie do listy rekordów okazuje się, że rekord nadal tam jest, jednak ponowna próba skasowania kończy się naszym wyjątkiem: rekord nieistnieje. po header("Location: strona") chyba nie trzeba dawać exit()... chociaż nie jestem w 100% pewien. Co do raportów, zwłaszcza ostatniego... zrób full skan antyvirusem i sprawdź czy nie masz jakiegoś świństwa. -------------------- |
|
|
![]()
Post
#3
|
|
Grupa: Zarejestrowani Postów: 3 Pomógł: 0 Dołączył: 26.04.2003 Skąd: Konstantynów Łódzki Ostrzeżenie: (0%) ![]() ![]() |
Czyli nie trzeba się bawić w jakieś bzdurne reql_query, free_results itd.? Spróbuję wyłuskać kod właściwy.
Powoli skłaniam się do wniosku, że to może być wirus. Na serwerze 1 wiele plików i katalogów ma chmod 777 (a raczej nikt z nas by tego nie ustawiał). Podobnie wielu z nas miało w historii przeglądania następujący adres: neborin.info?... Jak można przeczytać... http://safeweb.norton.com/report/show?name=neborin.info ...nie jest to nic dobrego |
|
|
![]() ![]() |
![]() |
Aktualny czas: 21.08.2025 - 02:53 |