InstallWinMsgCallback GPF with CVI 8.5

[gtoph]

I'll leave this kinda broad for the moment, but just wanted to throw this out there and see if anyone else has seen this.  The program was running fine with CVI 8.1.1, but since I upgraded to 8.5 InstallWinMsgCallback is causeing a GPF in my threads.  It doesn't seem to do it on my laptop, which is only a single cpu/core, but on the target machine which is a core 2 I get the GPF (using the remote debugging feature I caught it).  Has anything changed in 8.5 with respect to windows messaging?

Thanks

edit: Acutally I've now gotten a few different messages with this function:  Dynamic memory corruption and  realloc pointer memory not allocated by malloc


Message Edited by gtoph on 11-29-2007 12:58 PM

[LuisG]

Off the top of my head, I don't know what's happening. But since that function is defined in the Programmer's Toolbox, which is open-source, you can probably debug it a bit further, and see if you can narrow down the problem. You can look in this thread for instructions on how to debug toolslib code.

Luis

[gtoph]

Awsome tip, thanks Luis.  I wansn't aware that could be done.   It caused the GPF in MsgHandlerWndProc on one of the returns at the end of the function:

if (callDefProc)
    {
        // Call the CVI default WndProc
        pdfltWndProc = (void*) phandler->defaultCVIWndProc;
        return (*pdfltWndProc) (hwnd, message, wParam, lParam);    <-- GPF here
    }

I haven't actually stepped through or anything yet as to detmine why, but thought I would post an update.

[LuisG]

Hmmm... so that means it's happening back in CVI RTE. Debugging toolbox further will probably not help you. The key would be for us to be able to reproduce the problem here. It must be being caused by some unexpected combination of the parameters to that function, and the state of the application.

If you're not able to zip up the crash, it might help to post what the values of 'message' and 'lParam' and 'wParam" are when the crash happens.

Luis

[gtoph]

I'll try an reproduce that one again.  From what I remember the parms were both 0,but I don't remember the message value.

I do have what looks to be a new message handling releated one though... in DiscardPanel->LinkedPanelCallback->ChainedMsgCBPanelCallback
                   hpanel = 2  (my main panel)
                   event = 16 (discard)
                   callback = NULL
                   eventData's = 0

I got a "dereference of uninitilized pointer" error on line 14659:
if (phandler->winMsgEnabled)         ---- phandler is uninitilized

the other variable in the function handlerPosInList = 0

looking in FindMsgCBHandlerFromHPanel where phandler should be set, there is no default setting of phandler if any of the conditions fail.

In my case g_msgCBHandlers is initilized, so it must be the handlerPosInList that wasn't set from the ListFindItem call.

[gtoph]

Ok, managed to get the GPF in installWinMsgCallback on the next run.   Actually, I beleive the code posted in message 3 above was actually a crash in processSystemEvents.  Here's the details of this one:

InstallWinMsgCallBack->InstallWinMsgCallBackNoChecks->AddLinkToMsgCBHandler->ListNumItems

GPF on:  return (*list)->numItems;
    list = 0x6874bd29

unfortuanly I CVI died on me when I tried to explore it further

[gtoph]

Doesn't look like the last edit took, but here's what I tried to add:


Got another dereference of uninited pointer around the same area:
installWinMsgCallbackNoChecks->CreateMsgCBHandlerForPanel ---
        ChainPanelCallback ((*ppnewHandler)->hpanel, ChainedMsgCBPanelCallback, 0, "WT_TYPE");

I've gotten this one the last couple of times I've run the program, but I can get the dereferenced pointer and GPF errors at various places.  Seems to be some change related to threading that's new in 8.5.  LIke I say, I never saw any of this stuff in 8.1.1 and I don't see it on my single core laptop development system either.... only the dual core target.

High level, the main thread creates a handful of "sub threads"....  each of these then creates a new top level panel and installs various messages (all higher than WM_USER) using the InstallWinMsgCallback.... they then sit and wait (calling processystemevents and sleep(0) until the main thread sends a message to have them do something. 

I belive all of the various errors have occured in the "InstallWinMsgCallback" and in the "ProcessSystemEvents" calls.

Hope this all helps.

[LuisG]

Yeah, I think that helps.

I still can't reproduce your problem, even using a multithreaded program running on a dual core, where each thread is installing callbacks on its own panels. However, based on your description of the problems you're having, and on their erratic nature, I think we're looking at a race condition caused by multiple threads accessing the internal data structures of the toolbox.

The Programmer's Toolbox is not a library in the traditional sense of the word, and as such, much of its API is not multi-thread safe. In looking again at the code for the the windows message callbacks, it looks like it is definitely not thread-safe. Essentially, if multiple threads attempt to access g_msgCBHandlers simultaneously, these types of errors can occur.

It's understandable that you see this problem with a dual core machine, since a dual core machine allows threads to really run in parallel. In theory it can happen in a single core computer also, but depending on when the thread switch happens, it might be very hard to reproduce. The only thing about this doesn't make sense is that this problem should also have happened with version 8.1, and earlier. So that's still a bit of a mistery.

In any case, I'm attaching an unofficial patch of the 8.5 version of toolbox.c. Basically, it replaces g_msgCBHandlers with a thread-safe variable, thus ensuring that multiple threads don't access it simultaneously. Since we never reproduced the original problem here, we're going to need you to try it yourself, and see if it fixes the problem. If it does, it's safe to continue using it. You just have to create a toolbox.obj file (using Options>>Create Object File) and then replace the one that is installed by CVI. Before you do so, however, it's a good idea to make a copy of the original toolbox.c and toolbox.obj.

Let us know how it turns out.

Luis

[gtoph]

I had the same thoughts about the race condition.... In my main thread I create 5 new ones, one right after another.  They then each install there own set (maybe 5 - 10 each) of message handler callbacks.  Since on the dual core there is most likely at least two running at the same time I figured they were tromping on a global variable in the libraries.

Based of this theory, I've actually changed my code a bit to start one thread, wait for it to fully initilize, then start the next and so on.  Takes a little more time, but it's still not really noticible to the end user.  I'll go back to the older meathod I had, using your new file and see what happens.

Thanks.

[gtoph]

Luis,

Finally had some time to try your code change.  I made an executables that had only the old and new versions of the toolbox code as changes and ran them on the target.  The old one still hung/crashed, the new one seemed to work fine.  I'll leave the new file in there for a longer test and see if anyone complains about it it crashing/hanging.   Looks like that fixed the issue though.  Is this a fix that would end up in the next release of CVI, or should I hang on to your custom file?

Thanks for your help.