#foswiki 2017-07-17,Mon

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)

WhoWhatWhen
***ChanServ sets mode: +o Lynnwood__ [00:29]
..................... (idle for 1h44mn)
geetar has left [02:13]
.................................................... (idle for 4h16mn)
ChanServ sets mode: +o MichaelDaum [06:29]
................................................................... (idle for 5h34mn)
ChanServ sets mode: +o gac410 [12:03]
...... (idle for 25mn)
ChanServ sets mode: +o Lynnwood [12:28]
gac410Hi MichaelDaum ... I found what might be another possible performance problem, or at least some room for imrpovement, in Item14437 [12:38]
FoswikiBothttps://foswiki.org/Tasks/Item14437 [ Item14437: Macro expansion runs away, reprocessing some macros many times. ] [12:38]
gac410When the macro processor hits a well formed "common tags" macro like %TABLE{sort="off"}% it tries to expand it, passing sort="off" to Foswiki::Attrs. when that fails, it appends to the next %, and tries again. Repeats for every % until end of topic. [12:40]
FoswikiBothttps://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Attrs [12:40]
gac410so on a topic like System.SpreadSheetPlugin, it called Attrs 200 times, gradually growing the argument string up to 65K bytes.
Also it "disarms" !% style commented macros, removing them from consideration, but it does not disarm %<nop> style macros, which causes them to be considered as well.
[12:41]
.... (idle for 16mn)
The reprocessing may not have a good fix, other than possibly setting a limit on the number of iterations. Otherwise expansion of %T%ABLE%% - having variables build macros by concatenation.
But, if core knew that %TABLE...% was a well-formed macro that would *never* expand, it could just disarm it, preventing the whole issue. Maybe by adding an ability to register "common tags" that should be ignored. TABLE, CALC, etc.
[13:01]
..... (idle for 20mn)
MichaelDaumHi George [13:24]
gac410Howdy MichaelDaum [13:25]
MichaelDaumI've seen your bug report and was wondering myself wtf is going on there...
what I do know is that commonTagsHandler is called many many times no matter how many unparsed macros there are left
[13:25]
gac410I was trying to debug the friendly parser, and noticed it was being called much more than I expected, so I went back to Release 2.1, and it had the same behavior ... it's working like that by design. :( [13:26]
MichaelDaumopening a can of worms, basically, the reason for %CALC and %TABLE to be implemented that way is their positional context being adjacent to a table which is then processed of course [13:26]
gac410Right. But there is no reason for the "registered" tag parsing code to attempt to expand them over and over. It should ignore them. [13:27]
MichaelDaumyea maybe. and why does it accumulate 65k of an arg string? what is making it grow like this?
I am really not good in this area of the code, the macro parser. Crawford is our parser guru.
[13:27]
gac410It breaks the topic into a stack, delimted by %. So when it hits (%) (table{sort="off"}) (%) It calls the parser with sort=off, and tries to run the table subroutine. Which obviously doesn't work.
So now it thinks, maybe it needs to concatenate, so it skips to the next % on the stack and tries again. One iteration for every % found in the topic.
There must be 200 % signs in the SpreadSheetPlugin topic, so off it goes.
y I figured any changes in this area would need careful vetting by Crawford. It's a minefield for sure.
[13:29]
................................... (idle for 2h54mn)
***ChanServ sets mode: +o Lynnwood__ [16:25]
..... (idle for 21mn)
plujonI'd like to use Facebook for user authentication. Possible? [16:46]
.................. (idle for 1h26mn)
MichaelDaumplujon, ModellAachen have implemented it https://github.com/modell-aachen/UnifiedAuthContrib. Maybe you can ask them to contribute it back to Foswiki. [18:12]
......................... (idle for 2h0mn)
Lynnwood__Anyone run across this error on page load: "Not a SCALAR reference"? I've getting it on some topics after updating a site to 2.1.4
Just beginning to troubleshoot it but don't see anything that looks related on Foswiki.org
[20:12]
......... (idle for 42mn)
gac410do you know in what module / line? [20:54]
.... (idle for 17mn)
Lynnwood__sorry... not paying attention.
gac410 - There's a whole series of errors, but the first in series (on each page load) is this:
Not a SCALAR reference at /path/to/foswiki/lib/Foswiki/Plugins/DBCachePlugin/Core.pm line 1256.
[21:11]
gac410Ah... DBCachePlugin ... not one I'm familiar with or use.
We are using that extension on blog.foswiki.org, but not on foswiki.org
blog.f.o is running DBCachePlugin 16 Jan 2017, 10.00
[21:13]
Lynnwood__Can't imagine how you do without it... ;-)
present moment excepted...
[21:15]
gac410hm Line 1256 is a close } That doesn't make sense for triggering a SCALAR Ref issue. [21:18]
Lynnwood__i think i'm going to try rebuilding the DBCACHE
well... that accomplished nothing
[21:19]
Ok, i've narrowed it down. _Appears_ to be associated with "remote" parameter.
If i include remote="on", it blows up. Remove it and everything is fine.
[21:30]
........ (idle for 35mn)
very interesting. I can blow up any DBQUERY by adding that option.
may actually have a bug to report here...
[22:06]

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)