Languages and Scripting
Showing results for 
Search instead for 
Do you mean 

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

SOLVED
Go to Solution
Highlighted
Regular Advisor

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

[ Edited ]

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
Acclaimed Contributor [Founder]

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

[ Edited ]

>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?