AV in "Text Find / Replace"

FinalBuilder Bugs
1

A syntax error occured parsing the Regular Expression : Could not substitute regexp reference: Access violation at address 00B2540C in module ‘fbcoreapi.bpl’. Read of address 2812E010

FB 6.2.0.1265

Search String:
(VALUE “CompileDate”,.")(.)(\0")$

Replacement String;
$1%TempDummy%$3

2

Hi Christoph

We were not able to reproduce this here. Can you send us the file that you were searching (to support, don’t post it here) so we can see if we can reproduce the problem. Also, can you look in your temp folder (type %TEMP% and hit enter in the explorer address bar) and see if there is a finalbuilderbugreport.txt file, if there is please email it to us.

3


I have attached a project that demonstrates the problem. With 2 regexp replace actions. One that is ok and one that fails. From my investigation it is the placement of the first " char in the substitute definition.

I have also tried to recreate the problem in a clean project, but was unable to recreate. I had to copy/paste the action from another project to get it to fail.

There was no file in the temp folder.

Best regards,
Christophregexp_fail.zip (3.845 KB)

4

Hi Chris

Thanks for the excellent example, I was able to reproduce the problem here. The problem is a bug in the regex library not dealing with $12009… properly. As a work around, change the regular expression to :

${1}%REGEXP_REPLACE%$3

We’re planning on replacing the library with a more compliant library for the next version of FinalBuilder and I tested this problem with the new library (we added a unit test using your example) and it worked fine.

5

I just checked in a fix for this issue so after the next build you won’t need to use the work around.

6

Here’s a build with the fix included :

https://www.finalbuilder.com/downloads/finalbuilder/620/FB620_1458.exe

7

Hi Vincent,

I already used a workaround, but I thought I better report the bug Christoph

8

We use a Delphi component called TRegExp, however it hasn’t been updated in years and is missing some features that users have requested. It will be replaced with PCRE which supports the full Perl Regex functionality. We actually use PCRE already in places in FB/AT.

9

Hi Vincent,

Actually we also use a unicode version of TRegExp 0.952. We tried to use PCRE and the Jcl included libraries, but we had some difficulties getting it to work properly hitting AV’s all the time when using non-latin based languages, so we returned to TRegExp again.

I am very interested in hearing your experience with PCRE, pro/contra (if you have time).

Best regards,
Christoph

10

Hi Chris

For the next version of FB, we are moving to D2009 so we have had to review every third party library we use. TReExp is missing some features that RegEx gurus expect, so we switched to PCRE, which we already use in FB in some places where we needed the extra functionality. We haven’t seen any problems with PCRE. We wrote a wrapper around it that mimics the .NET regex classes… makes it easier to use. Cogear are possibly going to include that in the Delphi RTL in the future. We have a bunch of unit tests for our wrapper/pcre so if you have any cases where your were getting av’s I’d certainly be interested in seeing them, and adding unit tests for them. Our unit tests include tests with Chinese and Cyrillic languages.

11

Hi Vincent,

I will try to hear what the problem was with the PCRE library, It was not me testing it. All I know this point is, it was the Jedi JCL PCRE wrappers that where used. So maybe the problem was the Jcl implementation part.
I understand you wrote your own wrapper for PCRE, so the problem might not apply to your implementation.

Best regards,
Christoph

12

Actually we do use the JEDI PCRE wrapper.