[bug]Memory Exhausted

[Verwijderd]

Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 22600269 bytes) in /mnt/web/react/got/react/global/non-www/classes/rml_advanced.class.inc.php on line 1337

Ik wilde eens kijken hoeveel characters GoT je laat posten in een bericht, dus heb ik het notitieblok vol gecopy/paste met qqqqqqqqqqqqqqq's... Het probleem is, er is geen maximum! GoT laat me doorschrijven totdat de geheugenlimiet vol is, waarna je een php-error krijgt.

Wel mooi dat het precies op lijn 1337 fout gaat.

[Verwijderd]

Duurde zeker wel even, eer dat je 21,5MB geupload had?

[Verwijderd]

Neuh, gaat kwadratisch omhoog als je constant CTRL+A, CTRL+C, 2x CTRL+V, CTRL+A etc... doet.

[ Voor 4% gewijzigd door Verwijderd op 03-09-2006 19:18 ]

[AtleX]

Het vullen zal niet lang geduurt hebben, maar het uploaden (posten) wel. En dit is niet echt iets waar Tweakers wat aan kan doen, alleen maar met een clientside scriptje checken of de inhoud niet te lang is.

[Verwijderd]

Mjah, t kostte een paar seconden. 20MB is niet veel meer in een land van mbits/s. Sowieso maakt compressie het al een stuk kleiner (en een lading 'q's is makkelijk comprimeren).

Textarea heeft helaas de beperking dat het geen maxlength kent. Ik gebruik er zelf altijd javascript voor.

[Erkens]

AtleX schreef op zondag 03 september 2006 @ 19:20:
Het vullen zal niet lang geduurt hebben, maar het uploaden (posten) wel. En dit is niet echt iets waar Tweakers wat aan kan doen, alleen maar met een clientside scriptje checken of de inhoud niet te lang is.

Het me sterk dat Remco56 21MB heeft geupload omdat ik denk dat t.net de post_max_size value van php niet zo hoog heeft staan dat dat zou werken
Dat React zoveel geheugen wil alloceren hoeft namelijk helemaal niet te slaan op die tekst die geupload is, maar ik noem even als voorbeeld een include file oid (nu zullen die niet zo groot zijn, maar toch) of een result set van een sql query, ik noem maar wat.

[crisp]

Erkens schreef op zondag 03 september 2006 @ 19:32:
[...]

Het me sterk dat Remco56 21MB heeft geupload omdat ik denk dat t.net de post_max_size value van php niet zo hoog heeft staan dat dat zou werken

Ik denk (weet wel zeker) dat we die hoger hebben staan aangezien file-uploads ook nog enigszins mogelijk moeten zijn

Dat React zoveel geheugen wil alloceren hoeft namelijk helemaal niet te slaan op die tekst die geupload is, maar ik noem even als voorbeeld een include file oid (nu zullen die niet zo groot zijn, maar toch) of een result set van een sql query, ik noem maar wat.

Als je kijkt naar de files die geinclude worden dan heb je het hooguit over een paar honderd kilobytes. Verder wordt er voor de notepad niet zo gek veel aan queries gedaan.

In ieder geval zou een check op grootte wel handig zijn ook in de notepad en rml_preview voordat de RML-parser wordt opgestart.

[Erkens]

crisp schreef op zondag 03 september 2006 @ 22:30:
[...]

Ik denk (weet wel zeker) dat we die hoger hebben staan aangezien file-uploads ook nog enigszins mogelijk moeten zijn

Ah, ik wist niet dat die upload dingen van React hier aanstonden

[moto-moi]

crisp schreef op zondag 03 september 2006 @ 22:30:
Ik denk (weet wel zeker) dat we die hoger hebben staan aangezien file-uploads ook nog enigszins mogelijk moeten zijn

uhuh, ik ben allang blij dat ik laatst php heb geupgrade zodat die check ook weer werkt op de 64bits systemen als ik dit topic zo lees

In ieder geval zou een check op grootte wel handig zijn ook in de notepad en rml_preview voordat de RML-parser wordt opgestart.

Lijkt me een leuk idee, want dit soort foutmeldingen hoor je gewoon nooit te zien te krijgen op onze sites

[crisp]

Erkens schreef op zondag 03 september 2006 @ 22:31:
[...]

Ah, ik wist niet dat die upload dingen van React hier aanstonden

Onze webservers serveren nog meer dan alleen het forum hoor

[Erkens]

crisp schreef op zondag 03 september 2006 @ 22:36:
[...]

Onze webservers serveren nog meer dan alleen het forum hoor

toch niet op dezelfde vhost of wel dan?

edit:
maargoed, dat helpt het probleem natuurlijk niet oplossen, hoewel het wel beter is om in dergelijke gevallen PHP al niet eens de boel te laten starten imo

[ Voor 27% gewijzigd door Erkens op 03-09-2006 22:39 ]

[Spider.007]

Het is logisch dat de RML parser hier op zijn bek gaat; aangezien er een grootte-check wordt uitgevoegd op zowel de geparste; als de ongeparste versie; waar een redelijk groot verschil in kan optreden. Evenwel is het wellicht een idee om zoiets in te bouwen:

PHP:

if (sizeof($userinput)) > $maxsize * 2) die(); else parse_rml($userinput);

[crisp]

ik denk dat als sizeof($userinput) al groter is dan $maxsize * 1 je al een probleem hebt

[Spider.007]

Nee; dat zeg ik juist; de totale grootte van de data kan kleiner worden nadat de RML-parser eroverheen is gegaan; denk aan een [bold] > <b> omzetting bijvoorbeeld. Een factor 2 is dan een veilige factor wmb

[Civil]

De totale grootte van de data kan ook twee maal zo groot worden nadat de RML parser eroverheen is gegaan; denk aan de code tag met highlighting voor een script. Ik ken weinig voorbeelden waar het omgekeerde het geval is, de rml tags zijn meestal een stuk korter dan de uiteindelijke html output. Het voorbeeld dat je zelf aandraagt is niet zo representatief omdat vaak [b] wordt gebruikt in tegenstelling tot [bold]

[moto-moi]

Spider.007 schreef op maandag 04 september 2006 @ 20:30:
Nee; dat zeg ik juist; de totale grootte van de data kan kleiner worden nadat de RML-parser eroverheen is gegaan; denk aan een [bold] > <b> omzetting bijvoorbeeld. Een factor 2 is dan een veilige factor wmb

Is het geen idee om bij een bepaalde hoeveelheid input http://nl3.php.net/manual/en/function.memory-get-usage.php te gaan gebruiken om erachter te komen of de parsing zal stranden?

[chem]

Het is moeilijk te voorspellen hoeveel geheugen de rml parser gaat verbruiken.

[Spider.007]

Civil schreef op maandag 04 september 2006 @ 20:45:
De totale grootte van de data kan ook twee maal zo groot worden nadat de RML parser eroverheen is gegaan

[...]

Uiteraard blijft de geparste versie gecontroleerd worden; ik zie nergens staan dat we die controle plots uit zouden schakelen

[crisp]

Spider.007 schreef op maandag 04 september 2006 @ 21:32:
[...]

Uiteraard blijft de geparste versie gecontroleerd worden; ik zie nergens staan dat we die controle plots uit zouden schakelen

Niet in de notepad though

Maar inderdaad, het gaat voornamelijk om de input voor de parser en dan met name voor de previews. Daar mag je wmb wel een zekere marge voor aanhouden hoewel ik ook van mening ben dat in 99% van de gevallen de geparsede output groter zal uitvallen dan de input.

[Spider.007]

crisp schreef op maandag 04 september 2006 @ 21:39:
[...]

Niet in de notepad though

Sssst; dat had ik me al bedacht

[crisp]

we zien het wel tegemoet