Re: Search Index Crash While Indexing Webarchive
Re: Search Index Crash While Indexing Webarchive
- Subject: Re: Search Index Crash While Indexing Webarchive
- From: Philip Dow <email@hidden>
- Date: Tue, 27 Feb 2007 22:27:51 +0100
I can reliably reproduce the bug on my system with a large batch of
files, but not by indexing the single file that it always crashes
on. I think we're out of luck until Apple fixes this, though,
unfortunately. (please file a bug report!)
Exactly. Indexing the file by itself does not produce the problem.
I've also discovered that calling SKIndexAddDocument() for each item
in the batch job from a second thread does not produce an immediate
crash but a delayed one on another item. It is consistently the same
file.
I will definitely file a report, but I'm seriously hoping someone can
suggest a workaround. This crash is happening during the upgrade to
the newer version of the program. I rebuild the search index and must
re-add every item in the data set to it. I definitely don't need a
crash while the user is upgrading their data, but I must rebuild the
index as the data model has changed.
-Phil
On Feb 27, 2007, at 8:03 PM, Adam R. Maxwell wrote:
On Tuesday, February 27, 2007, at 09:51AM, "Philip Dow"
<email@hidden> wrote:
Hi all,
I am encountering a crash when indexing a web archive using search
kit. You can see from the attached stack trace that I'm running cocoa
calling carbon which itself is starting up some more cocoa goodness
when the exception is raised. The console says " -[NSCFString
delegate]: selector not recognized ".
What gets me is I've surrounded my call to SKIndexAddDocument() with
a @try @catch @finally block, but I'm not catching the exception and
the program is going down. I've set a breakpoint on -[NSException
raise] and can watch the exception get thrown inside an xml/html
parser, but I cannot catch it. The document in question is a web
archive that opens fine in Safari.
I filed rdar://problem/4988303 last week with a virtually identical
backtrace. I was running with NSZombieEnabled set to YES, which
leads me to believe there's a memory smasher here.
#0 0x9297c008 in -[NSException raise]
#1 0x9297be5c in +[NSException raise:format:]
#2 0x92a2ebd0 in -[_NSZombie forward::]
#3 0x90a440b0 in _objc_msgForward
#4 0x92a2add8 in _structuredErrorFunc
#5 0x92c92cd8 in __xmlRaiseError
I can reliably reproduce the bug on my system with a large batch of
files, but not by indexing the single file that it always crashes
on. I think we're out of luck until Apple fixes this, though,
unfortunately. (please file a bug report!)
Also, be careful if you use kSKProximityIndexing; I also reported a
crash when searching an index created with that option (rdar://
problem/4988691); looked like SKQueryProcessProximityNode calls
CFStringCompare with garbage or a NULL pointer.
-- adam
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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