On 1 July 2013 15:57, Yuki Matsushita <matsushy at creo.co.jp> wrote:
In addition, I found a typo in line 251.
This! Domo arigato Yuki-san!
Yes, this has been bugging me for almost 2 years (when I reported the resultant segfault it to the List). I haven't been able to use any "trigger" clauses in all that time. It's still broken in the current trunk (rev 7257).
I'm guessing, from reading the code, that I could work around this by always have exactly the same number of "trigger" lines as "ignore" lines - perhaps padding out with bogus "trigger" or "ignore" lines.
But obviously would be better to have it fixed. Henrik, do you need a patch submitted for this one-line fix?
J
(2013/08/09 16:44), Jeremy Laidman wrote:
On 1 July 2013 15:57, Yuki Matsushita <matsushy at creo.co.jp> wrote:
In addition, I found a typo in line 251.
This! Domo arigato Yuki-san!
Yes, this has been bugging me for almost 2 years (when I reported the resultant segfault it to the List). I haven't been able to use any "trigger" clauses in all that time. It's still broken in the current trunk (rev 7257).
Thanks for your response, Jeremy. Dou itashimashite.
I'm guessing, from reading the code, that I could work around this by always have exactly the same number of "trigger" lines as "ignore" lines - perhaps padding out with bogus "trigger" or "ignore" lines.
Thanks for analysing this issue. I think so too.
Regards, Yuki
On 9 August 2013 21:05, Yuki Matsushita <matsushy at creo.co.jp> wrote:
perhaps padding out with bogus "trigger" or "ignore" lines.
I'm guessing, from reading the code, that I could work around this by always have exactly the same number of "trigger" lines as "ignore" lines
Thanks for analysing this issue. I think so too.
Yes, and no. It now goes past the code with the typo. However, it now dumps core when it actually uses the trigger and the number of bytes in matching lines is large. gdb tells me that it fails in line 315, in the logdata() function:
memmove(triggerendpos, skipend, bytesleft);If I push out the filesize limit to the max (1024k) then this line doesn't get executed and no more segfault. But I think I'm just being lucky that the volume of matching lines is less than 100k, and if it reached 100k, I'd be getting the segfault again.
So, still a problem, just a different one. And this code is waaaay too complicated for me to grok.
J
participants (2)
-
jlaidman＠rebel-it.com.au
-
matsushy＠creo.co.jp