Segmentation fault on a memory read, but GDB can read the memory location?

Question

I came across a segmentation fault and used gdb to debug.

the code is:

   static char predata[0xff];
    int i;  
    char* pointer;
    for(i = 1; i < 0xff; i++)
    {

        pointer = 0xb6f00008 + (char*)(i<<12);
        printf("ErrPtr:%p\n", pointer);
        if(pointer == (char*)0xb6f57008) continue;


        if(*(pointer) != predata[i] )
        {
            printf(" err:%p\n",pointer);
            predata[i] = *(pointer);
        }
    }

using gdb disassembly it shows:

   0x000201ee <+266>:   ldr r3, [r7, #20]
=> 0x000201f0 <+268>:   ldrb    r2, [r3, #0]
   0x000201f2 <+270>:   movw    r3, #34424  ; 0x8678
   0x000201f6 <+274>:   movt    r3, #18
   0x000201fa <+278>:   ldr r1, [r7, #32]
   0x000201fc <+280>:   add r3, r1

however the memory it was trying to access seems to be legit here is the command I run to get the register and I also manually read out the data from the address.

(gdb) info register 
r0             0x12 18
r1             0x0  0
r2             0xb6f02008   3069190152
r3             0xb6f02008   3069190152
r4             0xb32db450   3006116944
r5             0xb32db450   3006116944
r6             0x0  0
r7             0xb32dae18   3006115352
r8             0xbefffbc8   3204447176
r9             0x0  0
r10            0x128670 1214064
r11            0xbefffbc8   3204447176
r12            0x0  0
sp             0xb32dae10   0xb32dae10
lr             0x201df  131551
pc             0x201f0  0x201f0 <Func(void*)+268>
cpsr           0x80070030   -2147024848
(gdb) print pointer
$10 = 0xb6f02008 ""
(gdb) print *pointer
$11 = 0 '\000'
(gdb) print *(0xb6f02008)
$12 = 0
(gdb)

any advice on how to continue the debugging ?

Are you running the code on system without any kind of operating system (to-the-metal or bare-bones or similar)? Or any system which allows access to arbitrary addresses like you use? Or is this code from inside the kernel with access to arbitrary virtual or real addresses? — Some programmer dude, Jul 10 '18 at 06:45
with a linux, yes sometimes it can complete 2 loops, sometimes none, sometimes 3 loops. — Henry, Jul 10 '18 at 06:49
You're not debugging a core file or something? I'm trying to imagine a scenario where the address could actually be unmapped, but where `gdb` would create zeros instead of complaining about reading unmapped memory. — Peter Cordes, Jul 10 '18 at 06:50
Linux is uses *protected virtual memory*. That means you can't read from or write to addresses that aren't mapped to your process. Doing so will either lead to segmentation fault or a bus error. Even a privileged process (running with `root` for example) can't just access addresses willy-nilly. What are you *really* trying to do? What is the *actual* problem you want to solve? — Some programmer dude, Jul 10 '18 at 06:51
@Someprogrammerdude: If you run without ASLR, you can hard-code addresses in your source as part of an experiment to learn about paging and memory mappings or something (although normally you can just looking at `/proc/PID/smaps` instead of writing code to see which addresses fault). The question here is not why it faults, but why GDB seems to be able to read from the memory the load faulted on. — Peter Cordes, Jul 10 '18 at 06:52
What does GDB do if you try to read from an address that's definitely not mapped? (Check /proc/PID/maps, or use a low address in the zero page like `p *(int *)0x120`). Are you remote-debugging the kernel? Normally the high half of virtual address space is used by the kernel, on Linux. You are running Linux on your board, right, not just on the system running GDB? — Peter Cordes, Jul 10 '18 at 06:57
yes I am running Linux kernel on my board, the GDB is running on my PC i am debugging via gdbserver — Henry, Jul 10 '18 at 06:59
I am actually trying to solve a malloc(): memory corruption: 0xb6fxx008 issue where xx are random, so I came up with a simple program to debug... — Henry, Jul 10 '18 at 07:08
Suppose you should rather describe this memory corruption issue in more details and seek help for directly solving this one... — Aconcagua, Jul 10 '18 at 07:40
Yeah, this doesn't seem useful for debugging malloc compared to investigating with a debugger. (You can write loops in GDB's command language). But this is still weird and in need of explanation. What happens when you use GDB to read unmapped memory? (Look at `/proc/pid/maps` to find out what is/isn't mapped.) Can you double-check that the memory you segfault on, and that GDB reads, is unmapped? I think you're interpreting GDB's output correctly, that the instruction you fault on a byte load from `[r3]`, so that's weird. — Peter Cordes, Jul 10 '18 at 10:22
What happens if you use `set *pointer = 123`? Can you read back the modified value? Or does it still read as zero (indicating that GDB is giving you zero instead of telling you it can't access an unmapped page.) — Peter Cordes, Jul 10 '18 at 10:22
https://stackoverflow.com/a/1010471/50617 may be relevant here. On Linux, GDB can read memory with `PROT_NONE` (at least on some kernels), which the inferior process can't. — Employed Russian, Jul 11 '18 at 05:47

Segmentation fault on a memory read, but GDB can read the memory location?

0 Answers0