Corrupt Next Header

foosh101 · Post by **foosh101** » Wed May 12, 2004 10:05 am

abnormal program termination

This is the error that I recently started getting on my site. Please help. I have run kdbfchk and it didn't help, nor do I believe I have different versions (32 vs. 64 bit) of texis running as I have only ever installed one version. What causes a corrupt next header? Is it a bad peice of data, and by data, would you mean a bad character that Texis cannot handle. How do I prevent my tables and indexes from becoming corrupt?

Post by **mark** » Wed May 12, 2004 11:48 am

Did kdbfchk find the corruption? Did you run kdbfchk in fix mode to actually fix it? The default is to just check it, not fix anything.

Make sure you never use singleuser mode, that your disks don't get full, and that texis processes don't get hard killed (not given a chance to cleanup).

foosh101 · Post by **foosh101** » Wed May 12, 2004 1:01 pm

As for the kdbfchk goes, I do the following:

kdbfchk -o fix.tbl SYSINDEX.tbl

I then overwrite SYSINDEX.tbl with fix.tbl. Is that correct? I think I actually found my problem with that, as the error seemed to be on SYSINDEX.tbl, and I did my original kdbfchk on SYSTABLE.tbl.

My problem though is that I cannot afford for the table to become corrupt ever, as this is a live system. I thus need to prevent it from ever happening in the first place. The disks are no where near full. As for the processes getting hard killed, I don't think that is possible either, but am looking further into it.

Is it possible that bad data or characters could cause this to happen? I dump my data to a pipe delimited text file and then use timport to get it into Texis. Would a wierd character, or a row that did not follow the correct schema cause this error to happen? Would timport erroring on a ill-formatted row count as a hard kill, or would Texis just handle that accordingly?

foosh101 · Post by **foosh101** » Wed May 12, 2004 1:02 pm

Also, I have never set it to run in singleuser mode. Its not that way by default is it?

Post by **mark** » Wed May 12, 2004 1:54 pm

No, it's not single user by default. And odd data won't cause corruption or a hard kill. A hard kill is someone sending it signal 9 or the OS killing it because the system is low on memory.

What's your texis version and platform? (texis -version)

Did you keep a copy of the bad SYSINDEX.tbl? Maybe we can see in what way it was corrupt. If you want to send it to us open a ticket from the tech support link on the left.

foosh101 · Post by **foosh101** » Wed May 12, 2004 2:08 pm

I am running Commercial Version 4.00.1022784280 if May 30, 2002 (i686-intel-winnt-32)

Is there a newer verion that I should upgrade to? I did not save a copy of the currupted table, however I definitely will if this happens again.

Post by **mark** » Wed May 12, 2004 5:20 pm

There are more recent versions but I don't know of any known/fixed issues related to what you describe.

foosh101 · Post by **foosh101** » Thu May 13, 2004 1:07 pm

Ok cool, thanks for the help. Aside from this issue, should I upgrade Texis. If so, where would I be able to get the update from?

Thanks,
-Josh

Post by **mark** » Thu May 13, 2004 1:58 pm

Your version is a bit old. Contact sales to discuss updates.

foosh101 · Post by **foosh101** » Fri May 14, 2004 9:43 am

This issue happened again. I was hoping that this was a unique situation and that perhaps something was accidentally hard killed. This apparently is not the case. I got the same corrupt next header again on SYSINDEX.tbl. This time, I repaired it, and it fixed it to some degree, however a good when I access one of the tables/indexes, I get the following:

115 [market]:129: Query ` "CatID2.1001483"' would require post-processing: Term `CatID2.1001483' only partially matches index expression(s)
011 [market]:129: Buffer size 4 too small (need 16) for item 213 of page 0x2617A of index d:\MORPH3\Texis\mktDB\T02452d_T.btr in the function vbtgetnext
000 [market]:129: Assertion `0' failed at s:\texis\nt\vbtree.c:1173

These happened at the end of the last set of errors. What do these errors mean? Was the kdbfchk simply insufficient in fixing the problem? I do have a copy of SYSINDEX.tbl prior to fixing it and I will open a case and send it. I also have a copy of T02453d_T.btr I will send. This is a live system that has come to a screeching halt twice this week because of these corrupt next headers and from all I can tell, none of the possible causes for this error you have mentioned are occuring.