Process crash

[Chris Williams]

For the second time in the last two months we have had processes crash and refuse to start. The solution has been to rename the process, but we don’t know why that works.

The problem is not resolved by shutting down all of Cloverleaf, or doing the usual clean-up like removing monitorShmemFile, vista.taf, etc. The process does an orderly shutdown, and the error log will say it received a Signal 6. The process log stated

Quote:

*** glibc detected *** free(): invalid pointer: 0x0829ba30 ***

We’re running 5.6 on Red Hat and scratching our heads. Does anyone have a clue?

Thanks.

Topic

[Troy Morton]

Chris,

It looks like this is a internal error to the engine C code.  I found this web-link that explains what this error means, but it doesn’t really explain what it means in the context of Cloverleaf.

Hope this helps.  http://www.gidforums.com

[Max Drown (Infor)]

Chris, have you checked the recovery and error databases after the process crashes?

hcidbdump -r -U foo

hcidbdump -e -U bar

-- Max Drown (Infor)

[Sundeep Kumar]

I would make sure the recovery and error queues are empty. Also is it possible that some file got corrupted in the installation ? It is possible to delete bin and lib directories. If the code uses dyamic linking (I am not sure if the engine does that) it could just be a wrong version of the library (DLL) that it is looking at.

[Chris Williams]

As part of the clean-up process we emptied and initialized the databases, but we still had the problem.

[Bob Moriarty]

I experienced this problem today. In my case, it was caused by an inbound transaction having a single ampersand in a field that an Xlate was trying to copy. The Xlate also had the following in-line code operrating on the field in question:

set xlateOutVals [string range $xlateInVals 1 [expr [string length $xlateInVals]]]

5.6.2 on RedHat 4

[Chris Williams]

Hi Bob,

Nice to know that I’m not imagining the problem. Ampersands can be a pain when they get used where they shouldn’t be. I’ll go back and see if that was our problem.

Just as an aside, since I seem to be in teaching mode today, there is an easier way to write your string range command:

Code:

set xlateOutVals [string range $xlateInVals 1 [expr [string length $xlateInVals]]]

can also be written as

Code:

set xlateOutVals [list [string range [lindex $xlateInVals 0] 1 end]]

Since the command’s pointers are offsets from the beginning (zero-based), using the string length command gives you 1 beyond the end of the string. Character positions for a string with a length of 10, are from 0 through 9. You can also use the keyword “end” in the form “end-1”, “end-2”, etc. Don’t forget that xlateInVals and xlateOutVals are Lists.

Cheers.

[Charlie Bursell]

Well said Chris  😀   I keep preaching this.  One day it will get through  😀

[Bob Moriarty]

Thanks for the tcl tip. I’ll pass it along to the developer.

And Charlie, whenever I’m at a loss for an answer to any question, I blurt out, “Remember, it’s a list”.   😀

I replaced the inline tcl code with the new-improved version but still get a glibc error and core dump.

Might this be considered a Cloverleaf bug?

[Bob Moriarty]

I’ve dug a little further and discovered  that the crash actually occurs in an Xlate IF statement that is examining a field containing an ampersand. This makes sense and is referenced in the logfile line immediately preceding the glibc line.

Quote:

[xpm :xlt :WARN/0:Cerner_ORU_xlate:01/27/2010 13:46:33] IF data fetch produced multiple values.

*** glibc detected *** free(): invalid pointer: 0x0829ba30 ***

I didn’t understand what

Quote:

IF data fetch…

meant and now feel really stupid.

IF I only had a brain…    😕

[Bob Moriarty]

Not to beat a dead horse (again)…

I’ve suggested to the developer to add another layer of specificity to the IF’s Condition statement.

Code:

{ COND { 0(0).OBR(0).#31(0).[0].[0]  ne @null} }

not

Code:

{ COND { 0(0).OBR(0).#31(0).[0]  ne @null} }

[Author]

Replies