Help with threads

[juryu]

Hello guys,

If I have a dialog-based application, and somewhere in it I start a new thread with CreateThread(), is it possible that some of the messages received by my dialog will be treated by this thread?? My guess is NO, because the function we give to CreateThread() isn't even a class member of the dialog.

But it sure would explain some of the weird stuff that has been going on. My program has a weird bug where it looks to me like someone else is changing the value of a global variable in the middle of the execution of a function. This could only be another thread, but the thread I do have does not touch that global variable!

I have a Timer that touches it, but a timer should not be executed in a different thread... Right? It should wait for the function to end and then start the timer execution. Unless the timer message is being handled by the other thread, which is why I asked the first question, but I really don't think so.

Another curious thing is that this only seems to happen in windows 98. The bug never shows itself in windows XP. Could it be one runs the timer in a separate thread and the other doesn't ???

Sorry for the rant, and any comments on this would be helpful to me.

Thank you!

[John E]

Firstly, you've posted this into the wrong forum. There's a forum specially dedicated to multithreading where you'd probably get a much quicker answer.

Secondly, there are 2 type of thread - User Interface threads and worker threads. User Interface threads can process messages. Worker threads can't. That's not much to go on but it might be a start. If you think that your thread is unintentionally processing messages, look at what type of thread you created.

[Andreas Masur]

[Moved thread]

[Andreas Masur]

Well...in addition...this somehow sounds like you are corrupting your memory (e.g. writing over the boundaries of an array etc.)...

[juryu]

Yes, memory corruption is the first thing I thought, specially because the variable that is mysteriously changing value is a member in a struct and it comes right after a char buffer[200]... Smells like buffer overflow! But I added a lot of checking and it still happens, and only windows 98? Should have the same behaviour in XP if that was the problem.

I didn't know about User Interface threads and worker threads. I think mine is worker, because I create it like this:

CreateThread (NULL, 0, ThreadProcSimula, NULL, CREATE_SUSPENDED, &ThreadIdcc);

But I am not 100% sure... I just found out now that there exists a function called AfxBeginThread, would I be better off using that, or is it the same thing? I know AfxBeginThread calls CreateThread internally, but maybe in different ways to make the thread user interface or worker?

(By the way, I definetely want this thread to be Worker.)

[cvogt61457]

Can you post your project for everyone to look at?

[juryu]

cvogt61457, I see your point but I don't really think that would do much good, because it is a very big project I wouldn't expect anyone to have the patience to go through it all, and I'm not looking for someone to do my work for me, just some tips ;)
Thanx anyway!

[kirants]

Well, to make sure that it is your thread that is corrupting, did you try not creating the thread and see what's happening.

It sure sounds like memory corruption, but it could be because of anything.

Make sure , if you are accessing global objects are protected from simultaneous access. For e.g. AfxGetApp() and such things are global objects. If you are trying to use some of these from multiple threads there is a possibility of 2 threads overwriting things and corrputing..

[juryu]

Uh, the problem has been solved now, sort of. A friend of mine suggested that I try to compile it in Windows 98 just to see what happened and yeah, the problem was gone. Something about compiling in XP and using that executable in 98 then, I still have no clue what. But honestly, I don't really care much ;)

[Andreas Masur]

I somehow doubt that compiling on Windows 98 will remove the problem. I would rather say you have moved the problem somewhere else...in other words the compiled executable is different than the other and thus, the problem might not occur at the same time or place...

[cvogt61457]

Are you seeing the problem in the release version, debug
version, or both?

You said that the variable that is mysteriously changed is in a
data structure.

If the problem is seen in the debug version, then put guard
variables around the corrupted variable. Monitor these in the
debugger with a conditional breakpoint.

If the problem exists on one compiled version, then it will still
exist in others. Just because you don't see it as the same
problem doesn't mean that it isn't still there. I may show
under different circumstances. It's still a bug in your
programming.

[cvogt61457]

I'm not looking for someone to do my work for me, just some tips


* Can you provide a cut down version that has the same
problem?
* Have you tried removing sections of code that are not related
and can still reproduce the problem?
* Is the variable changing in a predicted way? Or is it to a
nonsense value?
* Is the problem easy to reproduce? Easy to see?

[juryu]

Thank you for you help, guys!

Well, NO, it is not easy to reproduce at all. It's one of those things that happens "sometimes". If I take the exact same actions again, there is no guarantee the bug will show itself again.

Also, as far as I can see, "nonsense value" describes better what it was doing. I tried the guard variables thing and the problem was still there.

I never compile Debug, only Release. I think they are so different that it is kind of a waste of time to try to fix one and then move to the other (this I mean generally, not just in this case).

It's even weirder than a variable being corrupted. There is a moment when I ask all the structures to be saved to a file, this is a good time to see which have been corrupted. But sometimes I look at the file and then without doing anything else, ask it so save again and sometimes the corrupted ones had returned to their original value!!

I kinda think it makes sense to have been fixed now. Because compiling and using in XP, never never never anything weird happened. And althout it was a "sometimes" kind of bug, sometimes was really very often, you kept using the program for like 5 minutes and the bug would show itself. And now it doesn't anymore. Clearly the executables generated are different, so why would it be hard to believe that this difference was what created the problem?

Another thing... A friend of mine tried to compile it in XP, but while running Visual C in "compatibility mode" for Win98. Says it worked, took the exe to 98 and there was no bug.

My Visual C, for some reason, does not run in compatibility mode. I'm going to start downloading Service Packs now.

[Andreas Masur]

Originally posted by juryu
Another thing... A friend of mine tried to compile it in XP, but while running Visual C in "compatibility mode" for Win98. Says it worked, took the exe to 98 and there was no bug.

What is a compatibility mode for Win98?

[juryu]

It's something you can do to executable files in Windows XP. You right-click on them and go to "Properties", there's a "Compatibility" tab and then you tell it to run like it was in Windows 98.

[Andreas Masur]

Well...okay...than this is a setting of the operating system and not the compiler...

I cannot say anything about this setting though...however, I still doubt that it would influence anything of what the compiler produced...

[LeeND]

Since you say you set (and watched) guard variables around the "mysteriously changing" one in question, you're pretty much stuck watching for changes to the exact variable address in question.

Are you lucky enough that the value should not be changing all that frequently, and thus you can just run it under the debugger with a breakpoint set for whenever the value changes??

As to the "compatibility mode" issue -- it is a red herring. At best the problem is just moving somewhere else in the application where it isn't hitting you (or isn't hitting you in so visible a way).