Error accessing Memory

[JaganKumar]

We are trying to execute a request for which Sybase database is queried and the output is returned to the exe.

But we are getting some error in accessing memory.

here is the bt of gdb core.

#0 0x60000000c01d60e0:1 in memmove+0x19e1 () from /usr/lib/hpux32/libc.so.1
(gdb) bt
#0 0x60000000c01d60e0:1 in memmove+0x19e1 () from /usr/lib/hpux32/libc.so.1
#1 0x60000000c582a3a0:0 in pctl_process (ReqObj=90) at pctl.c:153
#2 0x60000000c58239c0:0 in ods_process (req=90) at odsproc.c:60
#3 0x60000000c572e220:0 in BillReg (reqobj=89) at bill_reg.c:213
#4 0x60000000c57226c0:0 in bill_reg (ls=0x7fffd1e0) at add_reg.c:2464
#5 0x60000000c57212c0:0 in bulk_matched_nodup (dbproc=0x4005ab20,
ls=0x7fffd1e0) at add_reg.c:940
#6 0x60000000c571e350:0 in bulk_matched (dbproc=0x4005ab20, ls=0x7fffd1e0)
at add_reg.c:589
#7 0x60000000c571b2d0:0 in add_reg_main (dbproc=0x4005ab20, ls=0x7fffd1e0)
at add_reg.c:433
#8 0x60000000c5718fe0:0 in AddReg (reqobj=87) at add_reg.c:313
#9 0x60000000c57e2cd0:0 in RenewBlk (reqobj=87) at RenewBlk.c:243
#10 0x60000000c5835540:0 in RunFunction (Function=0x77733d60, InputObj=87)
at objctrl.c:423
#11 0x60000000c5831240:0 in pctl_process (ReqObj=87) at pctl.c:299
#12 0x60000000c58239c0:0 in ods_process (req=3) at odsproc.c:60
#13 0x60000000c5825050:0 in ods_processMessage (req=2) at odspkts.c:36
#14 0x400b0f0:0 in Process () at dlbx.c:688
#15 0x4003e20:0 in main (argc=2, argv=0x7ffff084) at dlbx.c:179
(gdb) frame 1
#1 0x60000000c582a3a0:0 in pctl_process (ReqObj=90) at pctl.c:153
153 memcpy( SaveArea, PctlGlobals, sizeof( PCTLGLOBALS ) );
(gdb) info locals
Response = 2004831394
ProcInfo = 90
APInfo = 100090
oReqObj = 90
ProcDetailObj = 0
ShLibName = 0xc58239b0 "\031\b"
APFunction = 0x7fffd130

Arg = 0x186fa

Function = (void *) 0x777f4ca2
rc = 1
hLib = 0x5a
pTime = 0x0
Timeout = 300
RequestCount = 0
WkBuf = Cannot access memory at address 0x200000007fffcb00
(gdb) p SaveArea
Cannot access memory at address 0x200000007fffcc00

Is there a way to check why our application try accessing these memory. is there a chance just because our PA-RISC source code is recompiled in Itanium and we are executing the exe.

[Dennis Handly]

Unfortunately you couldn't print out the values from your memcpy call. Perhaps they were macros?

Ah, the debugger is telling you the adddress of SaveArea is bad.

In any case, you can look at it in assembly mode:
(gdb) frame 0
(gdb) info reg
(gdb) disas $pc-16*8 $pc+16*4

>Is there a way to check why our application try accessing these memory.

Look print the values in hex?
What is the types of SaveArea and PctlGlobals. And what is the value of sizeof(PCTLGLOBALS). And the size of SaveArea.

[JaganKumar]

Thanks Dennis,

we tried looking into the assembly mode but we are not able to understand the output. i have attached the same. Pl. let us know how to analyse. And we are facing same issue in ather module our application also.

FYI,
362 arg0 = pgm;
(gdb)
363 sprintf(arg1, "%d", shmid);
(gdb)
364 cii->isc_return_data_len = 0;
(gdb)
369 switch (r=fork())
(gdb) p shmid
$1 = 327690
(gdb) s
[New process 18664]
Detaching from program: /dnbusr1/montexec/bin/dlsockd, process 18655
Attaching after fork to process 18664
[Switching to process 18664]
377 fd = open("/dev/null", O_RDWR);
(gdb)
(gdb) s
Executing new program: montciid
Cannot insert breakpoint 0:
Error accessing memory address 0x4007660: Not owner.

Fork process intiates the child, in that process we are facing the memory accessing error in first step itself.

[Dennis Handly]

>we tried looking into the assembly mode but we are not able to understand the output. I have attached the same. Pl. let us know how to analyse.

You stopped the register dump too early:
pr22: 0
---Type to continue, or q to quit---q

#0 0x60000000c01d4780:0 in memmove+0x80 /usr/lib/hpux32/libc.so.1

0x60000000c01d4780:0 : (p15) st1 [r32]=r27,2

This indicates that you are storing into the address in R32, or SaveArea is bad.

>Error accessing memory address 0x4007660: Not owner.

I'm not sure why you are getting this. I'll have some debugger experts look at it.

>Fork process initiates the child, in that process we are facing the memory accessing error in first step itself.

Do you know where SaveArea is defined? Is it a global, local or shlib global?

The address SaveArea 0x200000007fffcc00 seems like a local in main or a few frames below that. For PA, if you didn't allocate enough space, you wouldn't abort right away, but with the IPF stack growing in the other direction, you would get an abort like this, depending on the length. A register dump would have shown it.

[JaganKumar]

I have attached entire list of reg. PFA

>we tried looking into the assembly mode but we are not able to understand the output. i have attached the same. Pl. let us know how to analyse.

You stopped the register dump too early:
pr22: 0
---Type to continue, or q to quit---q

#0 0x60000000c01d4780:0 in memmove+0x80 /usr/lib/hpux32/libc.so.1

0x60000000c01d4780:0 : (p15) st1 [r32]=r27,2

This indicates that you are storing into the address in R32, or SaveArea is bad.

>Error accessing memory address 0x4007660: Not owner.

I'm not sure why you are getting this. I'll have some debugger experts look at it.

>Fork process intiates the child, in that process we are facing the memory accessing error in first step itself.

Do you know where SaveArea is defined? Is it a global, local or shlib global?

SaveArea is define on the pctl_process function as local variable. does this error will go if we memset the SaveArea to the size it required.

Cannot access memory at address 0x200000007fffcc00: not owner

this show stopper of our debugging, we are not able to proceed any further to try out any thing.

[Dennis Handly]

>I have attached entire list of reg. PFA

You are moving 2 bytes (R34) from 0x29 (R33) to 0x200000006c76616e (R32).

R32 doesn't match your original value for SaveArea, 0x200000007fffcc00.

R33 is a garbage value. Possibly a NULL pointer with the offset of 41 bytes?
You might want to link with -z so you abort sooner when dereferencing NULL pointers.

The target also isn't valid because you can't store there.

>SaveArea is define on the pctl_process function as local variable.

How long is it?

>does this error will go if we memset the SaveArea to the size it required.

No, it would probably abort the same way

>this show stopper of our debugging, we are not able to proceed any further to try out anything.

What version of gdb are you using? You should download the latest.
http://www.hp.com/go/wdb

Also, what is the version of the compiler you are using?

[Mithun R N]

Hi Jagan,

>WkBuf = Cannot access memory at address 0x200000007fffcb00
>(gdb) p SaveArea
>Cannot access memory at address >0x200000007fffcc00

Do checkout for any corruption happening to the caller to memmove due to any buffer overflow.

>Executing new program: montciid
>Cannot insert breakpoint 0:
>Error accessing memory address 0x4007660: Not owner.

This error might be occuring here because you seem to exec a new program (or even 64-bit program from a 32-bit program). This error only says that some previously inserted breakpoints cannot be inserted after the exec. This problem will be fixed in the next release of WDB (5.8).

As a workaround, please try deleting the breakpoints (especially

breakpoints) just before the exec() and try again. break on function-names will work provided the function has a definition in the program that is being exec`d and the one that is exec`ing.

Thanks and regards,
Mithun
(HP-WDB team).

[JaganKumar]

what is the version of the compiler you are
using?

cc: HP aC++/ANSI C B3910B A.06.10 [Mar 22 2006]

GDB version 5.4


How long is it(SaveArea)?
1344

Hi Mithun,

We are using gdb ver 5.4, is there a possibility that if we use 5.6 this error may go. Please let me know.

and as you said i tried remove break points, but i am getting the same error.

FYI,
362 arg0 = pgm;
(gdb)
(gdb) d b 1
(gdb) s
363 sprintf(arg1, "%d", shmid);
(gdb) s
364 cii->isc_return_data_len = 0;
(gdb) s
369 switch (fork())
(gdb)
[New process 9525]
Detaching from program: /dnbusr1/montexec/bin/dlsockd, process 9483
Attaching after fork to process 9525
[Switching to process 9525]
378 dup2(fd, 0);
(gdb)
(gdb) s
Executing new program: montciid
Cannot insert breakpoint 0:
Error accessing memory address 0x4007660: Not owner.
(gdb) q

[Mithun R N]

>We are using gdb ver 5.4, is there a >possibility that if we use 5.6 this error >may go. Please let me know.

You might get the same error even with WDB 5.6. But, it is always advised you use the latest version of WDB to leverage the new fetures put in.

>and as you said i tried remove break >points, but i am getting the same error.
>(gdb) d b 1

>(gdb) s
>Executing new program: montciid
>Cannot insert breakpoint 0:
>Error accessing memory address 0x4007660: >Not owner.

Are you sure you have removed all breakpoints including the one you have placed at PC 0x4007660 ?
(gdb) delete
Delete all breakpoints? (y or n) y

Regards,
Mithun
HP-WDB team

[Dennis Handly]

>How long is it(SaveArea)?
1344

How long does the gdb think it is:
(gdb) p sizeof SaveArea
(gdb) ptype SaveArea
(gdb) p /x SaveArea
(gdb) p &SaveArea

And the same for PctlGlobals.

>cc: HP aC++/ANSI C A.06.10 [Mar 22 2006]

The latest patch for this is A.06.14, PHSS_35974.

Have you thought of using some of the +check= options? +check=uninit +check=bounds +check=malloc

>Mithun: Are you sure you have removed all breakpoints

Does single stepping set a temp breakpoint that causes JaganKumar's problems? If so, he should just continue after it displays the fork below.
(gdb) s
369 switch (fork())

[Mithun R N]

>Mithun: Are you sure you have removed all breakpoints

>Dennis: Does single stepping set a temp >breakpoint that causes JaganKumar's >problems? If so, he should just continue >after it displays the fork below.
>(gdb) s
>369 switch (fork())

The breakpoints that are posing a problem here are probably those that have been set before exec (w.r.t the older program). So, the workaround of deleting those breakpoints would work.

Regards,
Mithun
HP-WDB team

[JaganKumar]

>>The breakpoints that are posing a problem here are probably those that have been set before exec (w.r.t the older program). So, the workaround of deleting those breakpoints would work.

Mithun,

I tried debugging after delete all the break points, but still i am getting the same error. please let us know if any other work around for this to proceed further.

[Dennis Handly · Accepted solution]

>I tried debugging after delete all the break points,

Have you tried not single stepping into fork?

[Mithun R N]

>I tried debugging after delete all the break points,

>Dennis: Have you tried not single stepping into fork?

Did you try not to step into fork ?

Can you show us the output of this gdb command ?
(gdb) maint info break

And also let us know how you are invoking gdb, the options used.

Mithun

[Mithun R N]

>I tried debugging after delete all the break points,

>Dennis: Have you tried not single stepping into fork?

>Did you try not to step into fork ?

Workaround:
1> ensure that you do not have any breakpoints corresponding to the child`s pre-exec`d parent.

2> Do not use the "step" command to step over fork, exec.
If you want to debug the new exec`d program, use the "next" command and before using "next" over fork, exec, you can plant breakpoints w.r.t the "being exec`d" process,
say (gdb) break

3> Use the latest gdb 5.6 from
http://www.hp.com/go/wdb

Do let me know whether this works.

Mithun
HP-WDB team

[Mithun R N]

>Workaround:
>1> ensure that you do not have any >breakpoints corresponding to the child`s pre-exec`d parent.

>2> Do not use the "step" command to step >over fork, exec.
>If you want to debug the new exec`d program, use the "next" command and before using "next" over fork, exec, you can plant breakpoints w.r.t the "being exec`d" process,
>say (gdb) break

>3> Use the latest gdb 5.6 from
>http://www.hp.com/go/wdb

I could get to reproduce a problem similar to yours. Do try the first 2 workaround steps with gdb 5.4.
You can download the latest gdb 5.6 and still use these workarounds as stated above. There are some fixes that have gone into 5.6 which might even help your type of scenario.

Mithun
HP-WDB team

[JaganKumar]

>2> Do not use the "step" command to step >over fork, exec.

yes it is working for next.

we have installed gdb5.6 and we are trying to debug with that.

Thanks for your valuable suggestion and comments.

Thanks a lot

[Dennis Handly]

>yes it is working for next.

Have you solved your problem with memcpy?

[JaganKumar]

Have you solved your problem with memcpy?

we just tried memset the SaveArea and now we are not facing the issue to the length as much as it is going to copy


Now we are able to debug our exe's but still we are facing some segmentation violation faults. may be i should start new thread for that. i will try to fix and let u know if ur help requires.