myoptika wrote:
I heard about this on the news.
If you saw it on the news, it's highly likely that you saw not only my house, but also my car. The building being searched is pretty much opposite our house. Originally the police area only included a few houses including ours and the 'car park' shared between us and the line opposite, which meant that the news were pretty much on our front door, and our house and the carpark were the backdrop to the reporting in the morning. Since then the entire street has been closed. It's much nicer now we don't have photographers trying to take pictures whenever we get remotely close to a window.
richardgaywood wrote:
Mr Dave wrote:
In all seriousness, I'm fairly bored now, due to being stuck in the house (If I leave, there's a good chance I won't be allowed to return for a while, according the the police.)
It's like a really boring type of exciting!
It was exciting when it first happened. By now I'm a little tired of the Army and Police sitting on my front door.
Quote:
Quote:
Exciting, no? Geek points if you can actually tell anything about the state of the memory in question.
Hmm. What on earth are you doing that involves RAM dumps in hex? Rather hardcore in this day and age. I know four 0xFD is something to do with boundaries of malloc()ed areas, and I can see a few of those in there, and they seem to have contents in. The repeated 0xFE 0xEE is interesting, but I don't know what to make of it.
Debugging a collision system, mainly. That's the output of one of the memory windows I had open early in a test.
It was a whole lot easier than trying to set up watches on many objects, and I'm used to debugging optimised code, so it doesn't make me flinch (comparitively, this is a walk in the park). And it also familiarises myself with the memory structures so that if they appear in a debug spew, or when I have to deal with the optimised version, it's much easier.
But anyway - What that memory sheet would tell me if I came to it cold : CRT debugging enabled and heap memory, 3 objects, one which is likely 16 bytes, one that is definately 16 bytes (and is the 61st block allocated), and one that is 36 bytes (63rd block allocated). A whole lot of unallocated memory at the end (0xfeee = freed memory. 0xdd = dead memory that has not yet been freed, 0xab = padding after the memory allocation) All the non null values are pointers (as the between object pointers point to pretty much the same area of memory, it's a good guess) The heap (or at least that section of it) is healthy, if not organised that well.