Code!
Ok so this thread is predominantly because I have a problem that may-or-may-not be more complicated than a blog, but it's really open to any discussion about computer science-y things.
I've been working in C for a little while, and I'm currently playing around with SDL (media library, primarily target at game development). I'm kind of teaching myself how to do a few things as I go, using the Quake 3 source code and Stachexchange as a general points of reference. I've just written a memory manager of sorts, and spent the last 3 days debugging it. I discovered that I'm totally fucking stupid, but I almost have it working. I think I'm still having a few issues with it but I'm not really sure why. (Sorry in advance for the images, I need to find a way to turn off C++ syntax highlighting for my pure-C) Basically, I have a struct "new" with a field uint32_t pixels. New represents an image to be drawn to the screen, and pixels is its raw image data. At the moment I am trying to fill pixels with a colour uint32_t col, in this case 0xFF00FFFF. https://imagizer.imageshack.us/v2/35...0/834/wftk.png Width and height are both equal to 40, so the loop runs for i < 1600. Whenever I try to run this I get a segmentation fault when i = 3. All of the memory in this example is preallocated into a "block" when the program starts, and I check to make sure that the section allocated for pixels isn't NULL. At this point it's probably worth mentioning that the block is allocated as a void pointer, then cast to a uint32_t*, which might have something to do with the problem somewhere up the line. I tested to make sure that nothing had gone wrong in the block, and that there was enough space actually there for 1600 uint32_t's. https://imagizer.imageshack.us/v2/11...0/819/gy0d.png If it can be iterated through and read every value in pixels then I should be able to write to them using that same method, right? https://imagizer.imageshack.us/v2/97...0/834/3z9q.png This freaked me out at first, but from the look of the dissasembly it appears that the second printf() gets shuffled down to after the allocation. Is it possible that could be significant? Basically I'm thinking this has to be a memory alignment error from casting out of a void pointer. Am I correct? Given that pixels comes from the start of a block I don't really understand how this happened, but is it possible that, because the data was allocated to a void pointer it started life out of alignment for a uint_32? Can anyone give me a blanket-idea of what could have happened here? Alternatively, you could all ignore me. I could probably post this somewhere better but I'm too lazy to make a new account anywhere. *Implicit casting is still casting. |
:
What type of variable is "pixels"? (Was the struct defined by you or came with SDL or sth?). Can it FIT such numbers as "0xFF00FFFF" ( 4278255615 in decimal, much more than this 70m you got in the output) there? Also, shouldn't the second printf() be put after allocation anyway? what's the point of showing the unchanged value? |
The struct is defined by me. Pixels is an unsigned 32bit integer, big enough to hold up to 0xFFFFFFFF.
I just tacked the assignment back on without really thinking. The second printf() should have been down below that. The arrow in the dissasembly is stopped where the program segfaulted, at the assignment. You can clearly see that it's sandwiched between 2 calls to printf. I'm pretty sure this is a byte alignment issue, but that's not something I've ever had to deal with before. e: And yeah I realsied the output number of ~70,000,000 was way too small. That's why I'm thinking it might be alignment? |
Oh, uint32 is short from "unsigned 32bit integer". I'm a dummy, I haven't noticed.
So, the output window is from the exact code there? (With assignment not sandwiched) So... the shown value of pixels[i] should always be the same, right? But it breaks at the third attempt, so the second allocation must have overriten the bytes for pixels[3] amirite? I'm not an expert of neither C nor Assembly, but isn't the "arrow line" missing something: MOV *here*(&eax),&eax ? Unless it really wants to allocate the same value to itself (kind of?) , which is kind of pointless |
Yeah I don't know what the brackets mean. I just kind of look at the opcodes and fake the rest.
It was an alignment issue. I was stepping through my void pointers stupidly. Now I'm casting them to an unsigned, 8-bit integer pointer and adding i * the size of the item I'm allocating space for in bytes. I forgot the multiplication bit before, so it was possibly ending up halfway through a 32 bit integer as far as the CPU is concerned. Maybe. |
:
|
Yes. For some reason posting threads/blogs about coding issues is some kind of magical way to make me come up with a solution all by my self.
|
Does that work with social issues too?
|
No :(
|
Well, good luck on that then. Show us the result later. And if you encounter bugs, just return to this, maybe we can help. Or not, but you know, better safe than sorry.
|
:
|
Have you tried turning it off and on again?
|
Does that work with tigers?
|
what are the cheats? hold L1 and R1 i've got that already, then?
|
To hopefully sidetrack this thread back on to a topic, I thought I'd mention a few of the programming challenges I've been given in job interviews lately.
|
:
http://en.wikipedia.org/wiki/Rubber_duck_debugging |
Have you tried invoking the spirit of Varrok? Much meditation and prayer are required to become all of code, and not some, but all. Just so.
That's the only advice I have, and I only posted here because I'm bored right now. |
:
|
:
Might have a crack at some of these later if I'm bored enough. Exercises like this are the kind of thing I've missed out on a lot being self-taught. Thanks :D |