Closed 0xd34df00d closed 12 years ago
please assign to nikita
Sent from my iPhone
On Aug 12, 2012, at 2:25 PM, Georg Rudoy notifications@github.com wrote:
Autotester script always returns different results:
19:52:02 deadfood Ubuntu-1204-precise-64-minimal ~/barzer/src/autotester % ./autotest.py -r -in ~/queries.big
19:52:06 deadfood Ubuntu-1204-precise-64-minimal ~/barzer/src/autotester % ./autotest.py -r -in ~/queries.big
19:52:10 deadfood Ubuntu-1204-precise-64-minimal ~/barzer/src/autotester % ./autotest.py -r -in ~/queries.big
Please note that even not_passed + passed is always different which is obviously not good.
The sample queries data is on eu.barzer.net:/home/d34df00d/queries.big , barzer is 2861fb4https://github.com/barzerman/barzer/commit/2861fb4ad8cba9351d8abebc2c95d3ec8e5f9cf3
— Reply to this email directly or view it on GitHubhttps://github.com/barzerman/barzer/issues/339.
Already done.
I can reproduce this =( trying to find out the reason (
ok and how is this doing now?
Haven't tried the newer version yet. The dataset is in eu.barzer.net:/home/d34df00d/barzer/src/build/site, it's actually the archive made by @barzerman 's script three days ago at the moment of opening the issue.
three days of investigation no results what the fuck
Гоша, будь добр попробуй разберись что со скрипиом не так? Никита работает по полчаса в день толком без интернета - это хуйня какаято
В барзер какая-то херь приходит. Я вставил дебаговый вывод в матчер:
424 auto res = matches(patBarz, resBarz, settings);
425 if (res > 1)
426 std::cout << "!!!!!!!!!!!!!!!!!!! score " << res
<< std::endl << std::string (pattern, patSize) << std::endl << "----" << std::endl << std::string (res, resSize) << std::endl << "=============" << std::endl;
Получается такая муть: https://paste.lugons.org/show/pwCCUF3lvuKXzxzqZkNj/
На скрипт я уже посмотрел, нашел проблему, почему сумма была разной — там не лочился мьютексом доступ к глобальной таблице со статистикой. Почему в барзер приходит говно — я не понял.
Ok, compiling barzer with -fomit-frame-pointer -march=native
"fixes" this, but this sucks as a fix. I'd try to move code around a bit with plain -O2/-O3.
-fomit-frame-pointer -march=native - how do these affect performance?
They actually are good for performance. For example, these two are recommended for those Gentoo users who care about performance :)
isn't gcc always omitting frame pointer with -O? I thought it was
According to the manual:
-O also turns on -fomit-frame-pointer on machines where doing so does
not interfere with debugging.
Not sure whether x86/amd64 are among those platforms. I'd rather say they are not.
Also, I've tried rewriting the whole string parsing algorithm there or replacing C strings and strstr
with std::string
and find
/substr
, but the bug still reproduces.
Once again, I have a couple of ideas why that may happen, and I'd check them tomorrow.
please document the exact steps to reproduce the problem in the ticket
i have huge doubts this is an ASIO bug as we're using it in a very vanilla way and O3 is a vanilla optimization, for which I am sure boost has been tested well enough
/home/d34df00d/barzer/src/build/site
/home/d34df00d/queries.big
I don't think it's a dangling reference or anything. -O3 is surely a vanilla optimization but gcc is buggy after all, and when quite strange things happen in your code, it's time to start blaming the compiler for generating shit. After all, I already encountered quite a lot misbehaviors in gcc.
I spent quarter of the day moving code around trying to fix this by forcing the compiler to generate some other code and another quarter for staring at disasm. That's hardly a dangling anything.
After all, what the fuck is this?
uint16_t matches(const char *pattern, size_t patSize, const char *result, size_t resSize,
const ParseContext& ctx, const CompareSettings& settings)
{
Barz patBarz, resBarz;
EnbarzParser(patBarz, *ctx.m_gp.getUniverse(ctx.m_userId))(pattern, patSize);
EnbarzParser(resBarz, *ctx.m_gp.getUniverse(ctx.m_userId))(result, resSize);
auto res = matches(patBarz, resBarz, settings);
std::string resStr (result, resSize);
if (res > 1)
std::cout << "!!!!!!!!!!!!!!!!!!! score " << res << std::endl << std::string (pattern, patSize) << std::endl << "----" << std::endl << std::string (res, resSize) << std::endl << "++++++++" << std::endl << resStr << std::endl << "=============" << std::endl;
return res;
}
And then you get something like this:
!!!!!!!!!!!!!!!!!!! score 70
<barz u="84">
<bead n="1">
<fluff>over</fluff>
<srctok>OverBoard</srctok>
</bead>
<bead n="2">
<token>broad</token>
<srctok>OverBoard</srctok>
</bead>
<spell>
<correction before="OverBoard" after="over broad"/>
</spell>
<traceinfo>
<match gram="7" file="site/alpha/0/fluff.xml" stmt="143490" emit="344"/>
</traceinfo>
<query>OverBoard</query>
</barz>
----
pppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp
++++++++
<barz u="84">
<bead n="1">
<fluff>over</fluff>
<srctok>OverBoard</srctok>
</bead>
<bead n="2">
<token>broad</token>
<srctok>OverBoard</srctok>
</bead>
<spell>
<correction before="OverBoard" after="over broad"/>
</spell>
<traceinfo>
<match gram="7" file="site/alpha/0/fluff.xml" stmt="143490" emit="344"/>
</traceinfo>
<query>OverBoard</query>
</barz>
=============```
autotester.py -r hangs for me on my ubuntu 12.04 about once out of three times
server stalls on executable compiled with clang as well
Could you please show where it stalls? Like running it from gdb and pressing Ctrl+C when it seems stalled, and printing the corresponding backtrace.
In fact, this issue is far more interesting and sane to be dealt with then the original one.
i ran a server with 6 threads ran 6 autotester.py scripts sequentially - as one stalled i launched a new one without bouncing barzer.exe now im on the 8th task - this is NOT a deadlock - the client apparently waits for connection close
good news is that this is likely a client problem (i am now talking about the stalls while GENERATING answers) the situation with comparisons (and supposed buffer inconsistencies is different)
This info is unfortunately not the one I can derive productive info from. Could you please still send me the stack traces of all the frames during such stalls, as I've asked initially?
consolidating https://github.com/barzerman/barzer/issues/331 into this
fixed by upgrading boost to 1.50
Are you sure the original issue is fixed, not the stall? As I said, these two are different.
Georg Rudoy http://leechcraft.org 25.08.2012 20:11 пользователь "barzerman" notifications@github.com написал:
fixed by upgrading boost to 1.50
— Reply to this email directly or view it on GitHubhttps://github.com/barzerman/barzer/issues/339#issuecomment-8024717.
the original issue hasnt really bothered us yet :) if and when it does we'll reopen
On Sat, Aug 25, 2012 at 12:16 PM, Georg Rudoy notifications@github.comwrote:
Are you sure the original issue is fixed, not the stall? As I said, these two are different.
Georg Rudoy http://leechcraft.org 25.08.2012 20:11 ÐÏÌØÚÏ×ÁÔÅÌØ "barzerman" notifications@github.com ÎÁÐÉÓÁÌ:
fixed by upgrading boost to 1.50
Reply to this email directly or view it on GitHub< https://github.com/barzerman/barzer/issues/339#issuecomment-8024717>.
Reply to this email directly or view it on GitHubhttps://github.com/barzerman/barzer/issues/339#issuecomment-8024763.
www.barzer.net
Autotester script always returns different results:
Please note that even
not_passed + passed
is always different which is obviously not good.The sample queries data is on eu.barzer.net:/home/d34df00d/queries.big , barzer is 2861fb4ad8cba9351d8abebc2c95d3ec8e5f9cf3