Re: AfxBeginThread argument is altered

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Joseph M. Newcomer (newcomer_at_flounder.com)
Date: 02/13/05


Date: Sat, 12 Feb 2005 21:01:14 -0500

Pretty screamingly obvious what has happened here. You passed in a pointer to a
stack-allocated variable. By the time the thread executes, the stack has gone away and
whatever was on it is gone. You must never pass in a pointer to a stack local unless you
can absolutely guarantee that the stack will remain intact until the thread terminates.
This is usually very tricky, and always involves halting the intiating thread, thus
defeating the purpose of having a separate thread. Simply allocate the arguments on the
heap and make sure the thread frees them before it terminates.

void * args = new void *[2];

args[0] = ...;
args[1] = ...

by the way, putting a void * cast is pretty pointless, because anything is implicitly cast
to void *.

After you have taken the values from the args list, you can do a delete [] on it. Read my
essay on worker threads on my MVP Tips site.
                                        joe

On Fri, 11 Feb 2005 08:52:48 -0600, "Joseph V" <jvannucc.nospam@cullme.memphis.edu> wrote:

>First time I've posted, thx in advance, this group has helped me smash many
>bugs already!
>
>My problem is that I'm spawning a worker thread to run a genetic algorithm
>as
>to not deadlock my main dialog for the usually lengthy time is takes to run
>a GA.
>About 80% of the time it runs fine, and under a debug build it runs
>flawlessly every time.
>
>But if I run under my release build it will occasionally (maybe 20% of the
>time) not get the
> proper arguments (a void pointer to an array of two casted void pointers to
>my window
>handler and my dialog box). An example output of my Afx boxes on fail are:
>0012FC38 0012FC18
>before the thread and: 77D487FF 0012F5F4 inside the thread. On success they
>are
>the same.
>
>Needless to say my messages aren't processed by the win32 message handler
>and the data update
>functions are never being called by the GA (to update the GUI).
>
>Please help! Code follows,
>
>Best Regards,
>Joseph V
>
>
>
>void* args[2];
>args[0] = static_cast<void*>(&m_hWnd); //<-window handler
>args[1] = static_cast<void*>(this); //dialog gui
>ostringstream mystring;
>mystring << args[0] << " " << args[1] << endl;
>AfxMessageBox(mystring.str().c_str());
>m_thread = AfxBeginThread(runGA, args);
>------------------------------------------------
>int runGA(void* arg) {
>void** args = static_cast<void**>(arg);
>HWND* hwnd = static_cast<HWND*>(args[0]); //<-window
>handler
>CMYDlg* window = static_cast<CMYDlg*>(args[1]); //dialog gui
>ostringstream debugme;
>debugme << (void*) hwnd << " " << (void*) window << endl;
>AfxMessageBox(debugme.str().c_str());
>

Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm



Relevant Pages

  • Re: I feel stupid... "Invalid combination of opcode and operand", was, now is FORTH question
    ... TOS in ebx - top of stack - first stack element ... PSP in ebp - parameter stack pointer - pointer to stack, ... execute next at the end of their definition. ... High level Forth definitions merely organize the ...
    (comp.lang.asm.x86)
  • Re: win32 call dword ptr [eax] help needed
    ... I am kind of unsure as to how one would tell if this is in the heap or the stack. ... Anyone got any good documents on overwriting the SEH in a multithreaded application? ... >vtable directly, you are overwriting a pointer to an object, may be ... >talking about reliability we should ponder all options, ...
    (Vuln-Dev)
  • Re: MSL16 & FPGA Forth Processors
    ... make sense to have as a goal to use a "forth" cpu. ... C will run on a 6808 that has only one stack ... pointer and one data pointer. ... you won't have any register left over to use as a data-stack ...
    (comp.lang.forth)
  • [0xbadc0ded #04] smtp.proxy <= 1.1.3
    ... A remotely exploitable format string vulnerability exists in smtp.proxy ... Since the 'line' buffer is ... Since smtp.proxy is started from a superserver, like inetd, the stack ... To determine the address of a function pointer we could either try to ...
    (Bugtraq)
  • [Full-Disclosure] [0xbadc0ded #04] smtp.proxy <= 1.1.3
    ... A remotely exploitable format string vulnerability exists in smtp.proxy ... Since the 'line' buffer is ... Since smtp.proxy is started from a superserver, like inetd, the stack ... To determine the address of a function pointer we could either try to ...
    (Full-Disclosure)