[jira] [Commented] (XERCESC-1866) Crash with regular expression
[
https://issues.apache.org/jira/browse/XERCESC-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16059540#comment-16059540
]
Scott Cantor commented on XERCESC-1866:
---
Boris, feel free to unassign but I was just reviewing open bugs and noticed
this one mentions a "permanent" fix involving an ABI change. I'm guessing no
actual patch with that fix exists, but just checking now that we're able to
change the ABI again.
> Crash with regular expression
> -
>
> Key: XERCESC-1866
> URL: https://issues.apache.org/jira/browse/XERCESC-1866
> Project: Xerces-C++
> Issue Type: Bug
> Components: Utilities
> Environment: Windows XP, Visual Studio 2005
>Reporter: Alexander Hartmann
>Assignee: Boris Kolpackov
> Fix For: 3.2.0, 4.0.0
>
> Attachments: XERCESC-1866.patch
>
>
> when I run the following test code my application crashes on the second
> regEx.matches call:
> {
> XMLBuffer optionsBuf;
> optionsBuf.append('i');
> optionsBuf.append('H');
> RegularExpression regEx(L"^\\W*Excel\\W*$", optionsBuf.getRawBuffer());
> regEx.matches("Excel");
> }
> {
> XMLBuffer optionsBuf;
> optionsBuf.append('i');
> optionsBuf.append('H');
> RegularExpression regEx(L"^\\W*Excel\\W*$", optionsBuf.getRawBuffer());
> regEx.matches("Excel");
> }
> some details I found during debugging:
> - there is an instance of RangeToken where I have no idea where this is
> created. I've set a breakpoint in the constructor but the debugger does not
> stop.
> - when RangeToken::getCaseInsensitiveToken is called a new RangeToken is
> created and stored in fCaseIToken
> - when parsing is finished the newly created RangeToken is deleted (through
> ~RegularExpression -> ~TokenFactory), but the original RangeToken (where I
> don't know where it is created) still exists and references the deleted
> RangeToken in fCaseIToken
> - the next time RangeToken::getCaseInsensitiveToken is called the invalid
> reference fCaseIToken is returned and this leads to a crash when it is
> accessed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Commented: (XERCESC-1866) Crash with regular expression
[
https://issues.apache.org/jira/browse/XERCESC-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12781186#action_12781186
]
David Bertoni commented on XERCESC-1866:
Sorry, I've been traveling for work, and haven't been able to to much for the
last month. Yes, this is a temporary fix, but the permanent fix will break
binary and API compatibility, so it will need to wait.
Crash with regular expression
-
Key: XERCESC-1866
URL: https://issues.apache.org/jira/browse/XERCESC-1866
Project: Xerces-C++
Issue Type: Bug
Components: Utilities
Environment: Windows XP, Visual Studio 2005
Reporter: Alexander Hartmann
Assignee: David Bertoni
Fix For: 3.2.0, 4.0.0
Attachments: XERCESC-1866.patch
when I run the following test code my application crashes on the second
regEx.matches call:
{
XMLBuffer optionsBuf;
optionsBuf.append('i');
optionsBuf.append('H');
RegularExpression regEx(L^\\W*Excel\\W*$, optionsBuf.getRawBuffer());
regEx.matches(Excel);
}
{
XMLBuffer optionsBuf;
optionsBuf.append('i');
optionsBuf.append('H');
RegularExpression regEx(L^\\W*Excel\\W*$, optionsBuf.getRawBuffer());
regEx.matches(Excel);
}
some details I found during debugging:
- there is an instance of RangeToken where I have no idea where this is
created. I've set a breakpoint in the constructor but the debugger does not
stop.
- when RangeToken::getCaseInsensitiveToken is called a new RangeToken is
created and stored in fCaseIToken
- when parsing is finished the newly created RangeToken is deleted (through
~RegularExpression - ~TokenFactory), but the original RangeToken (where I
don't know where it is created) still exists and references the deleted
RangeToken in fCaseIToken
- the next time RangeToken::getCaseInsensitiveToken is called the invalid
reference fCaseIToken is returned and this leads to a crash when it is
accessed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Commented: (XERCESC-1866) Crash with regular expression
[
https://issues.apache.org/jira/browse/XERCESC-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12701848#action_12701848
]
Alexander Hartmann commented on XERCESC-1866:
-
Thanks alot for the quick fix!
The code above does not cause a crash anymore. So far I experienced no other
problems.
Crash with regular expression
-
Key: XERCESC-1866
URL: https://issues.apache.org/jira/browse/XERCESC-1866
Project: Xerces-C++
Issue Type: Bug
Components: Utilities
Environment: Windows XP, Visual Studio 2005
Reporter: Alexander Hartmann
Assignee: David Bertoni
Attachments: XERCESC-1866.patch
when I run the following test code my application crashes on the second
regEx.matches call:
{
XMLBuffer optionsBuf;
optionsBuf.append('i');
optionsBuf.append('H');
RegularExpression regEx(L^\\W*Excel\\W*$, optionsBuf.getRawBuffer());
regEx.matches(Excel);
}
{
XMLBuffer optionsBuf;
optionsBuf.append('i');
optionsBuf.append('H');
RegularExpression regEx(L^\\W*Excel\\W*$, optionsBuf.getRawBuffer());
regEx.matches(Excel);
}
some details I found during debugging:
- there is an instance of RangeToken where I have no idea where this is
created. I've set a breakpoint in the constructor but the debugger does not
stop.
- when RangeToken::getCaseInsensitiveToken is called a new RangeToken is
created and stored in fCaseIToken
- when parsing is finished the newly created RangeToken is deleted (through
~RegularExpression - ~TokenFactory), but the original RangeToken (where I
don't know where it is created) still exists and references the deleted
RangeToken in fCaseIToken
- the next time RangeToken::getCaseInsensitiveToken is called the invalid
reference fCaseIToken is returned and this leads to a crash when it is
accessed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Commented: (XERCESC-1866) Crash with regular expression
[
https://issues.apache.org/jira/browse/XERCESC-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12701631#action_12701631
]
David Bertoni commented on XERCESC-1866:
OK, I'm attaching a patch that should work for the 3.0.x stream.
Unfortunately, while investigating this bug, I discovered that some RangeToken
instances that are part of the static data are often used. Because RangeToken
caches the case-insensitive token in its fCaseIToken data member, the
RangeToken in the static data ends up with a dangling pointer to a RangeToken
that exists only for the lifetime of the RegularExpression instance.
Additionally, instances of RangeToken that are part of the static data should
_never_ cache the range-insensitive token, since it's not thread-safe to do so.
The real fix is to make getCaseInsensitiveToken() a const member function, and
to not cache the created RangeToken. Instead, RegularExpression could contain
a map of case-sensitive tokens to case-insensitive ones.
Alexander, could you please apply this patch to see if it fixes the problem.
Thanks!
Crash with regular expression
-
Key: XERCESC-1866
URL: https://issues.apache.org/jira/browse/XERCESC-1866
Project: Xerces-C++
Issue Type: Bug
Components: Utilities
Environment: Windows XP, Visual Studio 2005
Reporter: Alexander Hartmann
Assignee: David Bertoni
Attachments: XERCESC-1866.patch
when I run the following test code my application crashes on the second
regEx.matches call:
{
XMLBuffer optionsBuf;
optionsBuf.append('i');
optionsBuf.append('H');
RegularExpression regEx(L^\\W*Excel\\W*$, optionsBuf.getRawBuffer());
regEx.matches(Excel);
}
{
XMLBuffer optionsBuf;
optionsBuf.append('i');
optionsBuf.append('H');
RegularExpression regEx(L^\\W*Excel\\W*$, optionsBuf.getRawBuffer());
regEx.matches(Excel);
}
some details I found during debugging:
- there is an instance of RangeToken where I have no idea where this is
created. I've set a breakpoint in the constructor but the debugger does not
stop.
- when RangeToken::getCaseInsensitiveToken is called a new RangeToken is
created and stored in fCaseIToken
- when parsing is finished the newly created RangeToken is deleted (through
~RegularExpression - ~TokenFactory), but the original RangeToken (where I
don't know where it is created) still exists and references the deleted
RangeToken in fCaseIToken
- the next time RangeToken::getCaseInsensitiveToken is called the invalid
reference fCaseIToken is returned and this leads to a crash when it is
accessed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
