Error reading memory

[rajanandhini]

Hi,

We are trying to migrate the application from HP 11.00 to ll.23i v2. We have compiled the code successfully. But during runtime, we are facing issues while reading the memory of a character pointer. Please find the below details and kindly help.

char * UserProfId

UserProfId = 0x1634


Please let me know in case you need any more information.

Thanks,

nan

[Don Morris_1]

A lot more information, I'm afraid.

First, are you really assigning a constant to this pointer and expecting that to just work? (It is almost certain not to).

Assuming what you really meant above is that the pointer had this value at the time of the read [not that you assigned to it], then you have to determine where this address came from. Was it malloc'd? Returned via some other system call? Did you check for failure of said system call? Could this memory have been free'd and this pointer is stale?

There's really no way to know what's happened from the information given -- and the odds are quite high that this s a programmatic error in the code which wasn't sufficient to halt compilation (there may be an interesting warning in some cases... it never hurts to go back through the compiler output and determine why you got any warnings you got).

One other thought -- if you are also going from running on 32-bit kernels to 64-bit kernels, it would be worth checking that you aren't failing to include stdlib.h and casting the return value of malloc(). Doing that will cause malloc to be treated as returning an implicit int instead of the void * it really returns.

[Sandman!]

Can you post the source that is throwing this error if it isn't too big. Because as stated before a pointer cannot be equated to an address, it can only point to one. Unless the code was equating a char pointer to a string of chars i.e. char *UserProfId = "0x1634". A little more explanation alongwith the source listing would be of much help in debugging this issue.

~cheers

[Dennis Handly · Accepted solution]

The value 0x1634 would be a perfectly valid pointer value on PA but not on IPF. Pointers to rodata strings would start at 0x04000000.

As mentioned by Don, you need to track where that value came from. You could compile with +check=uninit. You can also set a gdb watchpoint on it:
(gdb) watch UserProfId

>Sandman: Because as stated before a pointer cannot be equated to an address

?? Why were you saying this? This output is from gdb:
UserProfId = 0x1634