rational purify error
Hi all,
I was facing a strange error while trying to run build after the "make depend" and "make all" was sucessful in solaris 5.4.
When I tried to attach dbx and run the build on solaris 5.4 release , it shows a wrong a memory address which is cascaded and dumps . Neither of the memory is freed.
dbx: cannot access address 0xffffffffffffffd4
When I tried to run with purify it shows:
UMR: Uninitialized memory read:
* This is occurring while in:
_writev [libc.so.1]
ts_tcp_writev [ts_tcp.c:401]
ts_send [trans.c:512]
check_pending_writes [perm.c:956]
PermPoll [perm.c:2233]
flush_perm [cfg.c:839]
* Reading 2092 bytes from 0xff322fdc (misaligned) between the heap and the stack (2060 bytes at 0xff322ffc uninit).
* Address 0xff322fdc is global variable "pack_buff".
This is defined in perm.c.
SBW: Stack array bounds write:
* This is occurring while in:
memcpy [rtlib.o]
smcallback [mgmt_sm.c:2415]
MakeCallback [perm.c:1814]
client_read [perm_client.c:295]
ts_poll [ts_poll.c:336]
PermPoll [perm.c:2263]
* Writing 2000 bytes to 0xffbed130.
* Frame pointer 0xffbed530
* Address 0xffbed130 is local variable "mymsg" in function smcallback.
MSE: Memory segment error:
* This is occurring while in:
MakeCallback [perm.c:1826]
* Accessing a memory range that crosses a memory segment boundary.
Addressing 0xffffffdc for 4 bytes ending at 0xffffffe0,
which is neither in the heap nor the main stack.
COR: Fatal core dump:
* This is occurring while in:
MakeCallback [perm.c:1826]
* Received signal 11 (SIGSEGV - Segmentation Fault)
* Faulting address = 0xffffffdc
* Signal mask: (SIGSEGV)
* Pending signals:
Purify: Searching for all memory leaks...
Memory leaked: 0 bytes (0%); potentially leaked: 0 bytes (0%)
Purify Heap Analysis (combining suppressed and unsuppressed blocks)
Blocks Bytes
Leaked 0 0
Potentially Leaked 1 8200
In-Use 282 970327
-
Total Allocated 283 978527
Can anybody please let me know :
1.why this happens and why this error occurs.
Accessing a memory range that crosses a memory segment boundary.
Addressing 0xffffffdc for 4 bytes ending at 0xffffffe0,
which is neither in the heap nor the main stack.
2. Why this cascading of memory address is happening.
Message was edited by:
sudheer786
