I'm running into an issue with GDB and some buffers allocated in kernel space. The buffers are allocated by a kernel module that is supposed to allocate contiguous blocks of memory, and then memory mapped into userspace via a mmap() call. GDB, however, can't seem to access these blocks at any time. For example, after hitting a breakpoint in GDB:
(gdb) x /10xb 0x4567e000 0x4567e000: Cannot access memory at address 0x4567e000
However, looking at the application's currently mapped memory regions in /proc//smaps shows:
4567e000-456d3000 rwxs 8913f000 00:0d 883 /dev/cmem Size: 340 kB Rss: 340 kB Pss: 0 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 0 kB Referenced: 0 kB Swap: 0 kB
The reason I'm even looking into this is because at some point during the run, this buffer address (or another allocated in a similar manner) causes a SIGSEGV.
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x49aea490 (LWP 652)] 0x402e4ea8 in fwrite () from /lib/libc.so.6 (gdb) (gdb) (gdb) where #0 0x402e4ea8 in fwrite () from /lib/libc.so.6 #1 0x000eb394 in EncryptedWriter::Write (this=0x198600, buffRaw=0x4567e000 <Address 0x4567e000 out of bounds>, iLenRaw=719) at encrypted_writer.cpp:397 #2 0x0006b0f4 in EncryptionWrapper::Write (this=0x3ab2698, buffer=0x4567e000, size=719) at encryption.cpp:54
This segfault occurs despite the fact that the buffer had been used heavily up until the crash, and the /proc//smaps file still shows this buffer to be mapped as above.
I am completely at a loss as to why this might be happening, and why the mapping seems valid in /proc but never in GDB.