Hello,
I have a strange problem in one of my BCB 5-projects which occurs
sometimes for the last 2 months or so: Some changes in the project
during normal development, for example adding new classes to the
project, delete or rename existing ones, or even branch to a specific
name, results in an access violation calling pcre_exec in
pcrecpp::TryMatch during application start up and parsing some
configuration information. In one case I "solved" the problem by
deleting and re-adding classes from and to the project, effectively
just changing the order in which those classes occur in the project
file. In one case the error could be "solved" by renaming a branch
from "GUI-Changes for XY" to "GUI_", because with a lot of longer
possible names the error occurred, but not with every longer name.
If the error occurs it always does in the following code in pcrecpp:
int options = 0;
if (anchor != UNANCHORED)
options |= PCRE_ANCHORED;
if (!empty_ok)
options |= PCRE_NOTEMPTY;
int rc = pcre_exec(re, // The regular expression object
&extra,
(text.data() == NULL) ? "" : text.data(),
text.size(),
startpos,
options,
vec,
vecsize);
The access violation depends on the value for options submitted to
pcre_exec: If it's 0 no error occurs, if it's greater than 0 the
access violation states a memory address which equals the value for
options submitted. In my case it would be 16 or hex 10, but it occurs
with 1 and 50 and 255, too. It just doesn't with 0.
I think of two possibilities: There could be a bug in pcre_exec which
results in that some code wants to write to a address which values is
overwritten with something defined by options and is only overwritten
if options is recognized at all, meaning not zero.
The other possibility is that the error in pcre_exec is just a side
effect of some former problems on stack or stuff like that and the
real problem is something else.
Bad for me I'm unable to debug pcre_exec, pcrecpp works, at them
moment, therefore I don't have any clue what might cause the problem.
Any ideas on what might be the problem? Do you think of any
circumstances in which pcre_exec could behave like I tried to
describe?
Thanks for any hints.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
Telefon: Potsdam: 0331-743881-0
E-Mail: tschoening@???
Web: http://www.am-soft.de
AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
