Re: NSRegularExpression segfault
Re: NSRegularExpression segfault
- Subject: Re: NSRegularExpression segfault
- From: Jens Alfke <email@hidden>
- Date: Mon, 15 Dec 2014 11:04:43 -0800
> On Dec 15, 2014, at 8:56 AM, ecir hana <email@hidden> wrote:
>
> I don't seem to have "bt" but I got instead from "Problem Report" window:
Sounds like you're not running the app in Xcode. If you're hitting a crash or other bug you should always try to reproduce it while running the app in Xcode, so the debugger can kick in.
Anyway, please file a bug report with Apple, as this seems to be a bug in NSRegularExpression.
> I would have thought 50 000 characters is not that much. But then again, I
> don't really know how ICU works... Reading the ICU docs further, there it
> says:
>
>> Because ICU does not use program recursion to maintain its backtracking
>> state, stack usage during matching operations is minimal, and does not
>> increase with complex patterns or large amounts of backtracking state.
It's not blowing up the stack. But it has to store backtracking state _somewhere_, and apparently it has a fixed-size buffer for this, which overflows while handling your regex because it's run into some pathological condition. Then, presumably, NSRegularExpression isn't noticing the error and ends up crashing by trying to operate on the nonexistent output.
I'm no expert on regular expressions, but my understanding is that all the implementations have a couple of pathological conditions where for certain expressions the memory usage goes up rapidly with input length, and if you run into one of those you'll need to adjust your expression to work around it.
—Jens
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden