Bug 347845 - Updating readable/writable flags of changed memory bytes
Summary: Updating readable/writable flags of changed memory bytes
Status: NEW
Alias: None
Product: CDT
Classification: Tools
Component: cdt-debug-dsf-gdb (show other bugs)
Version: 8.0   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact: Jonah Graham CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-31 14:50 EDT by Tomas Martinec CLA
Modified: 2020-09-04 15:19 EDT (History)
2 users (show)

See Also:


Attachments
Source for reproducing the behaviour (356 bytes, text/x-csrc)
2011-05-31 14:51 EDT, Tomas Martinec CLA
no flags Details
Proposed fix (4.68 KB, patch)
2011-05-31 14:52 EDT, Tomas Martinec CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tomas Martinec CLA 2011-05-31 14:50:11 EDT
Build Identifier: I20110519-1138

Hello,

probably I have found a problem with the current way of reading and displaying memory content. It happens when a block of memory is unreadable and after some time it changes to readability (for example because of page mapping/unmapping). The memory view then displays (red) question marks instead of proper contents of memory.

Reproducible: Always

Steps to Reproduce:
1. Create a C project; (Hello world ANSI C project)
2. Use the attached source code (requires work on the linux plaform; my kernel is 2.6.32.15)
3. Put breakpoints on the first and the last lines of the main function and start debugging
4. When the first breakpoint is hit, open memory view and add a hex monitor for the address 0x100000 - you should see just gray question marks, which is correct
5. Resume the program
6. When the second breakpoint is hit, see the memory view; you will see a few red question marks and the rest of gray question marks (it depend on the default content of mapped memory; zero bytes are gray, because their value has not changed for CDT); anyway there should not be any question mark at all
Comment 1 Tomas Martinec CLA 2011-05-31 14:51:25 EDT
Created attachment 197029 [details]
Source for reproducing the behaviour
Comment 2 Tomas Martinec CLA 2011-05-31 14:52:08 EDT
Created attachment 197031 [details]
Proposed fix