Operating System - HP-UX
1753765 Members
5662 Online
108799 Solutions
New Discussion

"Cannot access memory at address" is not written to a log file in HP wdb

 
SOLVED
Go to solution
blackwater
Regular Advisor

"Cannot access memory at address" is not written to a log file in HP wdb

In HP gdb 6.3  the message"Cannot access memory at address" is not written in a logging file while everything else is written. Is it on intention or by mistake? You see it is printed on my display even though I set a logging file. As a result backtrace printed on a display differs from backtrace saved to a log file.

 

By the way if it is done on intention it seems HP wdb does not give any way to somehow send these error messages also to the same log file.

 

 

(gdb) f
#18 0xc0000000196b5860:0 in cache_operations::get_data_impl (
    perftimer=@0x9fffffff0c2aee20, ctx=@0x9fffffff0c2af318,
    aOwner=@0x60000000023634a8, aCache=0x6000000000d53240, aDirectExec=1,
    aIndexID=@0x9fffffff0c2aee18, aIndexName=@0x9fffffff0c2aee40,
    sql=@0x9fffffff0c2aee48, aRaiseException=Cannot access memory at address 0x0
)
    at cache_source/cache_operations.cpp:299
299     in cache_source/cache_operations.cpp
(gdb) set logging file test_output_f.log
(gdb) set logging on
Redirecting output to test_output_f.log.
(gdb) f
Cannot access memory at address 0x0
(gdb) set logging off
(gdb) shell cat test_output_f.log
#18 0xc0000000196b5860:0 in cache_operations::get_data_impl (perftimer=@0x9fffffff0c2aee20, ctx=@0x9fffffff0c2af318, aOwner=@0x60000000023634a8, aCache=0x6000000000d53240, aDirectExec=1, aIndexID=@0x9fffffff0c2aee18, aIndexName=@0x9fffffff0c2aee40, sql=@0x9fffffff0c2aee48, aRaiseException=) at cache_source/cache_operations.cpp:299
299     in cache_source/cache_operations.cpp
(gdb)

1 REPLY 1
Dennis Handly
Acclaimed Contributor
Solution

Re: "Cannot access memory at address" is not written to a log file in HP wdb

>Is it on intention or by mistake?

Not sure.  I've assumed it is written by some lower level function that detects an error and just splats out a message.

I would be surprised that it is even written to the same file.

I guess I'm glad that gdb doesn't abort when it gets that message.  ;-)

 

You could check the latest FSF gdb and see what it does?