Unable to start sybase

[csreenivas]

Server was restarted.When our DBA tried to start sybase it is showing the follwing error.

./RUN_DSSS2[8]: 5662 Memory fault(coredump)

The core dump is /sybase/home/ASE-12_0/install/core on dsss2. I have no other error messages that I can use to debug the problem

[spex · Accepted solution]

Hello,

The obvious place to start is with the core dump.

$ strings /sybase/home/ASE-12_0/install/core |more
should give you some information. If you're feeling ambitious, use gdb to analyze the file:

$ gdb /sybase/home/ASE-12_0/install/startserver /sybase/home/ASE-12_0/install/core

But before digging too deep, ask yourself:

"What has changed recently?"

http://hpux.connect.org.uk/hppd/hpux/Gnu/gdb-5.3/

PCS

[Steven E. Protter]

Shalom,

It would appear something has gone wrong with the sybase binaries. Perhaps the disk had a problem due to the suddenness of the reboot.

If there is a sybase equivalent to an oracle relink, thats where I would look. Otherwise see if there is an error message with sybase support or on the web and see if there is a binary that can be "borrowed" from another machine.

SEP

[A. Clay Stephenson]

Doing a strings /sybase/home/ASE-12_0/install/core is absolutely, positively useless. All a strings command can do is list any 4 or more adjacent printable ASCII characters it finds. It could print all the potential error messages plus any embedded strings plus a lot of nonsense --- but none of this is useful. The suggestion for using a debugger to get a stack trace is more useful although without corresponding source code, it's diffilcult to do too much. You might try to start the process under tusc and then you will have a much better idea of where the problem is occurring. Perhaps the most significant suggestion was to ask yourself what has changed? Also, why was the server restarted? The problem may have actually started before the reboot.

[spex]

A. Clay,

I disagree with your statement. The ASCII strings in a core file can provide valuable insight into the root cause of a problem, including the actual command line used in execution, options specified, environmental variables in place at run-time (e.g. SHLIB_PATH, PATH, USER, SHELL, TERM, PWD), and any libraries linked dynamically. Of course, much of what is displayed must be ignored, as the core dump contains any strings originally present in the program's image. However, after a little practice, it's not difficult to differentiate between the useful nuggets and background noise, based on a string's position in the dump and its context.

Analyzing a core dump may not provide a "silver bullet" every time. In fact, oftentimes very little new information can be gleaned from one, and there's no guarantee that anything useful is present in the Sybase core in question. But there are certainly times in which a useful clue or insight can be obtained from the exercise.

That said, I fail to see how "Doing a strings [...] is absolutely, positively useless." Maybe we're just looking at different core dumps.

PCS