datatype misalignment and threads

[ulrika]

I am writing a Pocket PC application containing two different threads. The threads communicates through two CObLists. Each thread creates objects (using the new operator) and adds them to one of the lists. <br>The other thread then removes the objects from the list, reads and deletes them. The lists are protected by semaphors. <br>The problem is that I get an error message of type 8x0000002 (datatype misalignemnt) when deleting the objects taken from one of the lists. This error does not ocuur every time list objects are deleted but rather quite randomly about one time out of ten.<br><br>Does anyone recognize this problem?<br><br>Regards,<br>Ulrika<br><br><br>

[Malmer]

I really don't know WHY, but I know we had similiar problems with the fileparsing in Argentum. Our propblem was that is read/wrote outside the buffers but when I looked at the code it shouldn't had done that. The reason why it happened randomly for us was that sometimes when we compiled it overflowed into areas that wasn't "dangerous", while sometimes it went into areas that crashed the application. We rewrote the fileparsing a couple of times before we got it working. Now we haven't had any problems...<br><br>As for your things I really don't know what it is that could be causing it. Sorry.<br><br>Nice to see some female programmers aswell. Where you from? Sweden, Germany, Norway, Denmark or maybe Finland?<br><br>// Fredrik

[Digby]

Sounds like a thread synchronization problem.  From the your description of how you're trying to serialize access to the lists, I would use a critical section instead of a semaphore.<br><br>

[Dan East]

It can be tough debugging a multithreaded app. Try isolating portions of your code and run them under one thread, allowing all the routines it to be iterated thoroughly. The idea is to see if your code is failing for some other reason besides syncronization problems.<br>Also, MFC uses per-thread mappings to map HANDLEs to CObjects (windows, ImageLists, etc). You can't just pass CObjects between threads freely. You have to drop down to the underlying HANDLE and pass those.<br><br>Dan East

[ulrika]

problem solved!<br><br>In quite a strange way, though. The objects that weren't deleted properly were instances of a class that contained two integer, one character and two strings as private variables. The strings were malloced separately when set and freed in the destructor (if they were set). When changing the strings into arrays of characters of a fixed length instead (that is, changing the char *my_text declaration into char my_text[MAX_LOADBUFFER] instead), the problem disappeared. <br><br>Using dynamically allocated strings instead of arrays would mean that all objects put on the list would, in some sense, have different sizes, even though the actual class instances would all have the same size (since they all containg two pointers that, in their turn, points at data fields of different sizes). Changing into arrays causes all list objects to have exactly the same size.<br><br>The problem is solved then, but I am still very curious to know why the first code did not work. Any suggestions?<br><br>Thanks a lot to all of you who answered my last post!!<br><br>/Ulrika<br><br>

[Dan East]

I think we'd have to see the actual code to determine what might have been going wrong. The most likely thing is that when you were accessing or freeing the string arrays one of them was not a valid pointer. That would either be caused from not initializing the pointers to NULL in your constructor, or somewhere in your code you were writing past the end of an array, which depending on how the memory was allocated, caused one of the string pointers to be set to a non-valid pointer. The latter is hard to debug (with Windows CE), and will cause "random" results which can vary between builds. You can set a breakpoint for when the pointer's value is changed, if you know which pointer of which class instance is being set to a bad value.<br><br>Either of those errors could be solved by using a fixed array, but if the latter scenerio was the real problem, then it will rear its ugly head again eventually.<br><br>Dan East

[Dan East]

When you were dynamically allocating the character arrays to fit a particular string, you were including an extra char for the NULL terminator, right?<br><br>Dan East

[Anthrax]

As long as you brainiacs are on this data misalignment topic, can you offer any insight on my problem running the Zerstorer mod on the Jornada 720?  (See thread here: )<br><br>The exception is apparently either Out of Memory or Datatype Misalignment, depending on what error reference you look at.  <br><br>I have the mod's pak, configs, etc. and pocketquake.exe on a 32MB CF card with 1.7MB free.<br>I also have pocketquake.exe in \Quake on the root.<br>I wrote a shortcut to point to "quake/pocketquake.exe -game zer" and also one containing the mod's recommended " -winmem 12 -game zer"<br>I know this mod employs cutscenes and is a memory hog, but I have 24MB allocated to program memory on the device.  Any ideas?<br><br>[By the way, the mod uses a gfx.wad file, only 114KB, but could that be part of the problem?]

[randall]

- Whoosh -<br><br>"New!" be gone.

[Anthrax]

w00t!  I am fully matrixed.

[Peter Balogh]

The exception you've mentioned means that the processor (most PocketPC processors, like ARM) does not handle unaligned data, eg. all data must be aligned to 4 byte boundary. If you're using any unaligned data (like packing a struct or class with #pragma pack(1) or typecasting a byte pointer to dword at a non-aligned space) you should you the keyword UNALIGNED. You can find more about it in the eVC++ help. It slows down the code to third of the speed if you use UNALIGNED, but still, it might come useful in some situations.<br>Generally you should use aligned data.<br><br>BR,<br>Peter