Opened 17 years ago

Closed 17 years ago

#31 closed defect (fixed)

gsarch seg faults

Reported by: oranfry Owned by: nobody
Priority: moderate Milestone:
Component: Greenstone2 Runtime Severity:
Keywords: Cc:

Description

There is something weird going on with gsarch collection. Some documents caused it to seg fault. This is because its trying to get the childtype which doesn't exist: eg. classifytype = response.docInfo[numparents-1].metadatachildtype.values[0]; in browsetools. To stop the seg faulting, I added checks for the existence of childtype metadata before using it. now it doesn't seg fault, but the documents that used to seg fault now have a table of contents full of untitled, empty nodes. Adding format DocumentContents false to the config file makes the gsarch collection look good. But it doesn't fix the underlying problem: some of the documents e.g identifiers like (4.3.2.7.2.20030212094334.00affdf0-mail.wrlc.org) get treated as hierarchical, but others like (3FF885B4.4050402-cs.waikato.ac.nz) don't. Why? Is it because the first one has only numbers in between the dots?

error.txt was getting messages like "receptionist: no childtype element in metadata map!" and "Error: call to filter failed for 433D413B.3090402-gmx.net in OIDtools::get_info (protocol error)". These documents were not getting Title metadata set when viewing the document. Looking in OIDtools.cpp shows that is_top() assumes the presence of a "." in the doc ID means that this is a section and not a document. EMAILPlug has now been changed so that dots are removed from the document ids (we were using the email message id as the unique doc id).

Change History (1)

comment:1 by oranfry, 17 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.