Suppose, in a debugging session I have an address which unfortunately points to some rubbish. And I want to examine memory around it to see what's located near. As expected, the following error occurs:
(gdb) x/64 $t5
0x842da7ac: Cannot access memory at address 0x842da7ac
So, the question is: is there any way to read a range of addresses, some of which are not valid?
(More precise, how can I know that in the example above $t5+n is a valid address for some 0 < n <= 64?)
You can't read invalid addresses (obviously).
On some OSes you can can query the OS about valid addresses while the process is stopped in GDB. For example, on Linux cat /proc/<pid>/maps will give you info about which addresses are valid (and the access mode they are valid for). Other OSes may have similar mechanism.
Since you tagged your question post-mortem, you can't use above mechanism; but then you must have a core file. On Linux (and other ELF systems), readelf -l core will tell you which regions of memory were written into the core, which usually gives you a good idea of what memory was valid at the time of crash. However, read-only mappings are usually not written to core, so you may not see such mappings in readelf output.
All modern OSes use paging, and pages are at least 1K (though 4K is more common), so you can tell that the closest memory to $t5 which could possibly be valid is 0x842da800, and so n >= 84 (bytes).
Finally, if you ask GDB to examine 64 words, and GDB can't examine the first one, it will stop.
However, if you are using GDB-7.x, you can ask GDB to examine one word at a time in Python, and GDB will throw Python exception if it can't examine that particular word. But since you can catch Python exceptions, it is trivial to write a script that will implement "examine next N words, ignoring any unreadable ones" in Python (which I believe answers your "how can this be done" question).