views:

423

answers:

2

Lets state the conditions where sqlcxt() can cause segmentation fault, I am woking on unix, using ProC for database connections to Oracle database.

My program crashes and the core file shows that the crash is due to the sqlcxt() function

A loadobject was found with an unexpected checksum value.
See `help core mismatch' for details, and run `proc -map'
to see what checksum values were expected and found.

...

dbx: warning: Some symbolic information might be incorrect.

...

t@null (l@1) program terminated by signal SEGV

 (no mapping at the fault address)0xffffffffffffffff:     
<bad address 0xffffffffffffffff>
Current function is dbMatchConsortium
  442               **sqlcxt((void **)0, &sqlctx, &sqlstm, &sqlfpn);**
A: 

There is a decent chance that the problem you are having is some sort of pointer-error / memory allocation error in your C code. These things are never easy to find. Some things that you might try:

  1. See if you can comment out (or #ifdef) out sections of your program and if the problem disappears. If so then you can close in on the bad section
  2. Run your program in a debugger.
  3. Do a code review with somebody else - this will often lead to finding more than one problem (Usually works in my code).

I hope that this helps. Please add more details and I will check back on this question and see if I can help you .

Philip Schlump
The code fails occasionally, it means that for some time its success and for some time its getting failed
Sachin Chourasiya
Try to isolate what input data is causing it to fail. Almost certainly if it is an intermittent failure then it is a NULL pointer problem. This sounds ugly but I usually rely on fprintf and fflush and append to a file. Lots of print statements later I find the problem and then I usually don't want anybody to know what a silly thing I did in my C code.
Philip Schlump
Strange enough, this failure and success could not be identified. All I get in the core file is sqltxt() getting failed.
Sachin Chourasiya
If nothing else works - I know that it is ugly - but try lots and lots of fprintf(fp,"Line:%d\n",__LINE__);fflush(fp); to a log file and track what data is related to the failure.
Philip Schlump
A: 

It's probably an allocation error in your program. When I got this kind of behaviour it was always my fault. I develop on Solaris/SPARC and Oracle 10g. Once it was a double free (i.e. I freed the same pointer twice) and the second time I had a core in the Oracle part of the program was when I freed a pointer which was not an allocated memory block. If you're on Solaris you can try the libumem allocation library (google it for details) to see if the behaviour change.

tristopia
Yes even I am also thinking this as the memory issue, but howcome the same code returns success and failure some times
Sachin Chourasiya