Pro*C, dbx and check access [message #481459] |
Wed, 03 November 2010 11:42 |
reacher
Messages: 2 Registered: November 2010
|
Junior Member |
|
|
Our organization just moved from Solaris 5.9 to 5.10, and from Oracle 9 to Oracle 11.2
In trying to debug a program with a possible heap corruption, I wanted to turn on memory access checking in dbx (check -access). However, doing this results in a rua (read from unallocated memory) as a result from a simple database connection. I tested it with a smaller Pro*C program and confirmed.
exec sql include sqla.h;
int main(int argc, char *argv[])
{
exec sql begin declare section;
char *pwd = "user/pass@database";
exec sql end declare section;
exec sql connect :pwd;
return 0;
}
This simple program compiles, links and executes just fine. When run through dbx, it also performs as expected. But when access checking is turned on, then the funky stuff starts happening.
(dbx) run
...
RTC: Running program...
Read from unallocated (rua) on thread 1:
Attempting to read 4 bytes at address 0x2b0 in page zero
t@1 (l@1) stopped in kpedbgevpec at 0xe8948f68
0xe8948f68: kpedbgevpec+0x00c4: ld [%i5 + 688], %g1
I read you can suppress certain alerts, so I tried suppressing the rua in the function kpedbgevpec.
(dbx) suppress rua in kpedbgevpec
(dbx) run
...
RTC: Running program...
t@1 (l@1) signal SEGV (no mapping at the fault address) in (unknown) at 0xc0923e94
0xc0923e94: ld [%l5 + %g2], %o4
I was hoping to be able to use access checking on some of our other programs that are having some memory corruption issues. Does dbx access checking not work out of the box on our system? ?Has anyone else seen this before?
|
|
|
|
|
Re: Pro*C, dbx and check access [message #481738 is a reply to message #481459] |
Fri, 05 November 2010 15:03 |
reacher
Messages: 2 Registered: November 2010
|
Junior Member |
|
|
Since the errors are coming from an oracle library (libclntsh.so) I figured this would be a good place to start looking. We are using cc to compile. I also read up on the command "rtc skippatch" to turn off instrumentation for that library, but it still results in the segfault.
|
|
|
|