WSE 8.1.5 LUW Trap file not written as claimed?

[aj]

DB2 WSE LUW 8.1 Fixpak 5
Red Hat AS 2.1

Has anyone ever seen a db2diag.log indicate that a trap file
was written, but it is *not* written?

For the 3rd time in 18 months, I had a production server abend
and shut itself down w/ a signal 11 ala:

2005-10-30-02.05.02.430065 Instance:md Node:000
PID:5772(db2gds) TID:8192 Appid:none
oper system services sqloEDUSIGCHLDHandler Probe:50

Detected the death of an EDU with process id 30157
The signal number that terminated this process was 11
Look for trap files (t30157.*) in the dump directory

2005-10-30-02.05.02.566374 Instance:md Node:000
PID:5772(db2gds) TID:8192 Appid:none
oper system services sqloEDUCodeTrapHandler Probe:10

ADM0503C An unexpected internal processing error has occurred. ALL DB2
PROCESSES ASSOCIATED WITH THIS INSTANCE HAVE BEEN SHUTDOWN. Diagnostic
information has been recorded. Contact IBM Support for further assistance.

//(Isn't it funny how these always happen in the wee hours?)

But no t30157.* files are in the dump dir. I do, however,
see a t5772.000 file there - so I don't think there's some
misconfiguration that prevents the engine from writing trap
files.

Yes, yes..I know - I need to call IBM support, and I will.
But I've gone thru this before - they will be unable to assist
me w/o that 30157 trap file. The 5772 trap will not indicate
the root cause of the problem.

A signal 11 is a segmentation violation - a memory problem.

I'm on Dell h/w.

Has anyone ever seen behavior like this? Any ideas?

thanks

aj

[Matt Emmerton]

"aj" <ro****@mcdonalds.com> wrote in message
news:11*************@news.supernews.com...

DB2 WSE LUW 8.1 Fixpak 5
Red Hat AS 2.1

Has anyone ever seen a db2diag.log indicate that a trap file
was written, but it is *not* written?

For the 3rd time in 18 months, I had a production server abend
and shut itself down w/ a signal 11 ala:

2005-10-30-02.05.02.430065 Instance:md Node:000
PID:5772(db2gds) TID:8192 Appid:none
oper system services sqloEDUSIGCHLDHandler Probe:50

Detected the death of an EDU with process id 30157
The signal number that terminated this process was 11
Look for trap files (t30157.*) in the dump directory

2005-10-30-02.05.02.566374 Instance:md Node:000
PID:5772(db2gds) TID:8192 Appid:none
oper system services sqloEDUCodeTrapHandler Probe:10

ADM0503C An unexpected internal processing error has occurred. ALL DB2 PROCESSES ASSOCIATED WITH THIS INSTANCE HAVE BEEN SHUTDOWN. Diagnostic information has been recorded. Contact IBM Support for further assistance.
//(Isn't it funny how these always happen in the wee hours?)

But no t30157.* files are in the dump dir. I do, however,
see a t5772.000 file there - so I don't think there's some
misconfiguration that prevents the engine from writing trap
files.

Yes, yes..I know - I need to call IBM support, and I will.
But I've gone thru this before - they will be unable to assist
me w/o that 30157 trap file. The 5772 trap will not indicate
the root cause of the problem.

A signal 11 is a segmentation violation - a memory problem.

I'm on Dell h/w.

Has anyone ever seen behavior like this? Any ideas?

Since this is a SEGV issue, DB2 will likely dump core, which will be placed
in the dump directory in a directory called c<pid>.000. If you have a
multi-GB machine with tons of bufferpool configured, this core file can fill
up your filesystem which prevents the trap file from being successfully
written to the filesystem.

--
Matt Emmerton

[Larry]

Wonder if a SIG is initiated by the os or the hw ... whether DB2 would
have had a chance to write out its trap files. I seem to remember coming
across something like this before. If a SIG is under DB2's control, it
shouldn't have a problem. But if not, and if DB2 is simply killed before
it has a chance? I'd leave it to the service team to comment.

Larry Edelstein

aj wrote:

DB2 WSE LUW 8.1 Fixpak 5
Red Hat AS 2.1

Has anyone ever seen a db2diag.log indicate that a trap file
was written, but it is *not* written?

For the 3rd time in 18 months, I had a production server abend
and shut itself down w/ a signal 11 ala:

2005-10-30-02.05.02.430065 Instance:md Node:000
PID:5772(db2gds) TID:8192 Appid:none
oper system services sqloEDUSIGCHLDHandler Probe:50

Detected the death of an EDU with process id 30157
The signal number that terminated this process was 11
Look for trap files (t30157.*) in the dump directory

2005-10-30-02.05.02.566374 Instance:md Node:000
PID:5772(db2gds) TID:8192 Appid:none
oper system services sqloEDUCodeTrapHandler Probe:10

ADM0503C An unexpected internal processing error has occurred. ALL DB2
PROCESSES ASSOCIATED WITH THIS INSTANCE HAVE BEEN SHUTDOWN. Diagnostic
information has been recorded. Contact IBM Support for further assistance.

//(Isn't it funny how these always happen in the wee hours?)

But no t30157.* files are in the dump dir. I do, however,
see a t5772.000 file there - so I don't think there's some
misconfiguration that prevents the engine from writing trap
files.

Yes, yes..I know - I need to call IBM support, and I will.
But I've gone thru this before - they will be unable to assist
me w/o that 30157 trap file. The 5772 trap will not indicate
the root cause of the problem.

A signal 11 is a segmentation violation - a memory problem.

I'm on Dell h/w.

Has anyone ever seen behavior like this? Any ideas?

thanks

aj