1

When I use GDB to debug OpenGL programs, there is a misleading behavior of GDB.

I get a address from glMapBufferARB, the address in GDB shows 

$35 = (GLubyte *) 0xb74bb000 <Address 0xb74bb000 out of bounds>

And I can't print its content.

However, I can access its content in my program.

Is the address returned from glMapBufferARB different from ordinary memory address? Why GDB can't access it?

Martin Wang
  • 957
  • 14
  • 18

2 Answers2

2

Is the address returned from glMapBufferARB different from ordinary memory address?

Yes it may be a DMA buffer or memory on the GPU mapped into your process address space. Hence the memory lives outside your process allocation.

datenwolf
  • 159,371
  • 13
  • 185
  • 298
  • Is it the reason why GDB fail to access it? – Martin Wang Jul 08 '12 at 10:29
  • 1
    @MartinWang: Well it depends. Technically GDB should be able to see whatever the process sees. However since address space mappings are done on a per-process base by the kernel, and the debugger is executed in a separate process, with just some parts of the address space separation lifted, its perfectly possible, that a debugger doesn't get so see all of another process's memory. The usual way to debug this, is by injecting helper code into the target process, that does the reading in the target process's context. – datenwolf Jul 08 '12 at 12:32
  • @datenwolf "Hence the memory lives outside your process allocation." -- that explanation makes no sense. There is no such thing as "process allocation", and besides the process itself can see that memory, so it's not "outside of the process address space". – Employed Russian Jul 08 '12 at 21:20
  • @EmployedRussian: Each process has an associated page mapping table. This page table is unique to each process and allows the OS to translate virtual addressed in in the process address space to physical addresses. However not all page mappings map to system memory. Some map into PCI mapped memory, and this kind of mapping may behave different from regular memory mappings, as the code path executed in the case of a page fault to such memory may be very different. – datenwolf Jul 08 '12 at 21:31
  • @EmployedRussian: One key element is the TLB, which is adjusted for the current process at each context switch. Now if a debugger tries to inspect memory of some, say PCI memory mapping, those page mapping entries may have been removed by the scheduler at the context switch into the debugger process, which effectively means, that the debugger cannot access this memory. – datenwolf Jul 08 '12 at 21:34
1

Is the address returned from glMapBufferARB different from ordinary memory address?

It likely is special -- the OpenGL user-space library and a kernel driver probably conspire to arrange a special mapping, which only they understand.

Why GDB can't access it?

GDB uses ptrace(2) to read inferior (being debugged) process memory. It is very likely that the kernel device driver that actually talks to your graphics card doesn't support ptrace, and GDB's attempt to read that memory fails. That is possibly a bug in the device driver, but if you are using a closed-source driver (Nvidia?), there is likely nothing you could do about it.

Employed Russian
  • 199,314
  • 34
  • 295
  • 362
  • What do you mean by "not support ptrace"? ptrace belongs to glibc, and NVidia uses glibc. – Martin Wang Jul 09 '12 at 03:02
  • 1
    @MartinWang "ptrace belongs in glibc" -- is wrong. `ptrace` is a *system* call (which is what `(2)` after it stands for), implemented by various UNIX kernels. – Employed Russian Jul 09 '12 at 06:04