ugrás a tartalomhoz

Nem szokványos memória limit túllépés

gabesz666 · 2015. Már. 28. (Szo), 10.16
Sziasztok!

Kezdeném a hibaüzenettel:

FatalErrorException in Unknown line 0: Allowed memory size of 134217728 bytes exhausted (tried to allocate 139684812116568 bytes)

in Unknown line 0 at
HandleExceptions>fatalExceptionFromError(array('type' => '1', 'message' => 'Allowed memory size of 134217728 bytes exhausted (tried to allocate 139684812116568 bytes)', 'file' => 'Unknown', 'line' => '0')) in HandleExceptions.php line 116
at HandleExceptions->handleShutdown()
Tehát ha jól számolok, akkor 127 TB-ot próbál allokálni, amit picit indokolatlannak érzek. :) A rendszer Laravel 5 alapokon nyugszik, annyi bonyodalom van, hogy nem egy, de egyből két adatbázisból jönnek az adatok: egy MySQL, illetve egy MS SQL Server. Érdekes módon a hiba eltűnik egy pár xhr kérés után (amikben természetesen van db lekérdezés is). Én a MySQL-re gyanakszom, mert a bejelentkezés után egyből jelentkezik a hiba, ahol még az sql server-től nem kérek le semmit. De persze nem zárható ki semmi.

Találkozott már valaki ilyennel?

Ja, és amit próbáltam már némi guglizás után: mysql driver cseréje mysqlnd-re.
‹ miért nem küldiel a képet? localhost ›
 ■
1

Hát kezdetnek találgatás

inf · 2015. Már. 28. (Szo), 14.20
Hát kezdetnek találgatás helyett érdemes lenne megnézni, hogy mi van a 116. sorban, és előtte, aztán leszűkíteni a hibát pár sorra, ha lehet workaround-ot készíteni, és küldeni egy bug reportot a megfelelő szervnek.
3

Hasznos

gabesz666 · 2015. Már. 28. (Szo), 14.35
Köszönöm, ez a nesze semmi, fogd meg jól tanács tipikus esete.
Megnéztem az említett sort és meglepő módon a HandleExceptions.php az exception-öket kezeli, itt konkrétan a shutdown event-et.

leszűkíteni a hibát pár sorra

Elárulod hogyan? Van egy pár ezernyi sor kód és annyi segítségem van, ami a hibaüzenetben is van: "FatalErrorException in Unknown line 0". És akkor indulj tovább amerre gondolod.

küldeni egy bug reportot a megfelelő szervnek.

Ehhez talán előbb ki kéne deríteni, hogy mi okozza a problémát.
5

Ha dev gépen is ugyanez a

inf · 2015. Már. 28. (Szo), 14.54
Ha dev gépen is ugyanez a hiba, akkor 100 soronként beszúrsz egy log(x)-et, aztán ahonnan már nem loggol, onnantól van a hiba. Ugyanígy működhet, ha törölsz dolgokat a kódból, aztán megnézed, hogy úgy is kapod e a hibát.
2

Azt írják, hogy a 127 TB az

inf · 2015. Már. 28. (Szo), 14.33
Azt írják, hogy a 127 TB az nem a valóság, és általában csak annyit jelent, hogy szimplán kifogytál a memóriából. Növeld a memory limitet, esetleg frissíts verziót, mert lehet, hogy az aktuálisban memory leak van valahol.
4

Memory limit állítás

gabesz666 · 2015. Már. 28. (Szo), 14.41
Igen, azt sejtettem, hogy a 127TB nem a valóság, mivel a teljes codebase + a két adatbázis nincs 1 Gb sem.
A memory limit azért nem fog segíteni, mert itt egész biztosan nem a nagy mennyiségű adat miatt fogy el a memória, már ha tényleg elfogy. (a lekérdezések eredménye < 10 rekord)
6

Esetleg ha elméletek gyártása

inf · 2015. Már. 28. (Szo), 14.55
Esetleg ha elméletek gyártása helyett kipróbálnád az biztosan sokat segítene.

Ha dev gépen nem tudod reprodukálni, akkor elég nehéz dolgod lesz.
7

Már kipróbáltam

gabesz666 · 2015. Már. 28. (Szo), 15.10
Nem elméleteket gyártok, mivel kipróbáltam mielőtt írtam a fórumba. Még ha így is lenne, az is komoly problémát jelezne, mert egy tök alap template megjelenítésére és egy tárolt eljárás meghívására, ami kevesebb, mint 10 sort ad vissza, nem mehet el 128M memória.
Dev gépen is előfordul a jelenség. Sőt, ott jött elő először.
9

Akkor meg egyszerűen

inf · 2015. Már. 28. (Szo), 18.55
Akkor meg egyszerűen leszűkíthető. Kezdetnek kiszórod a templatelős részt, aztán egyből kiderül, hogy azzal van e a gond, vagy az adatbázissal. Ha spagetti kódod van, nem moduláris/oo, akkor egy fokkal nehezebb a dolgod, de úgy is ki lehet deríteni a loggolós módszerrel, amit már írtam. Esetleg egy xdebug-gal meg lehet próbálni, hátha azzal gyorsabban megvan, de egyáltalán nem lehetetlen, és találgatnod sem kell.
10

xdebug

janoszen · 2015. Már. 29. (V), 14.12
Nagyon szep kodja van, megneztem. A debugolas azert nehez, mert az unknown azt jelenti, hogy a stacken kivul tortent a hiba, ergo nem fog rafutni az xdebug tul gyorsan.

A tobbit majd gabesz osszegzi ha eljut odaig.
8

Ha nem boldogulsz vele...

janoszen · 2015. Már. 28. (Szo), 17.50
Ha nem boldogulsz vele, en szivesen megneznem kozelrol, mert erdekel. :)
11

Nem ismerem az általad

Tanul0 · 2015. Már. 29. (V), 19.32
Nem ismerem az általad említett alkalmazást, de nálam akkor volt ilyen hibaüzenet, ha túl sok osztályt próbált betölteni a loader a classpath-ra és a php fastcgi-ként futott. Érdemes megnézni az apache által gyártott logot, én is ott leltem a probléma forrására. (félre volt konfigurálva a php-fastcgi, bár ez egyedi fejlesztés volt, teljesen egyedi kiszolgáló konfigot igényelt.)
12

Nem csak ilyesminél jön elő,

inf · 2015. Már. 29. (V), 19.55
Nem csak ilyesminél jön elő, pl egy sima preg függvény miatt is lehet: php-trying-to-allocate-127-tb-of-memory-and-memory-leak-with-preg-match-and-preg

Ez alapján érdemes a warning-ot is nézni a log-ban, ha még nincs beállítva, mert az is nyújthat valamennyi támpontot.
13

Elkaptuk

gabesz666 · 2015. Már. 29. (V), 22.02
Köszönhetően janoszen-nek meglett a hiba forrása. :) A pdo_dblib extensionben van/volt egy hiba, amit ugyan már javítottak, de hivatalos releasebe még nem került be. Tehát megoldásként a php-t újra kellett forgatni a javított kóddal.

Természetesen mindenkinek köszönöm a segítséget!