Event->EventString roadblock

[m1duckett]

The following code causes a hard Girder lock with any read access to Event->EventString:

PLUGIN_API int WINAPI gir_event(PFTreeNode Node, CRITICAL_SECTION *cs, PEventElement Event, char * status,  int statuslen)
{
    MessageBox(NULL, "Test", "Message", MB_OK);
    bool success = false;
    PCommand Command;
    MessageBox(NULL, "Test2", "Message", MB_OK);
    GirderLogMessageEx(DEVICE_NAME, "Hello World!", GLM_GOOD_ICON);
    
    EnterCriticalSection(cs);
    Command = (PCommand)Node->Data;
    MessageBox(NULL, "Test3", "Message", MB_OK);
    
    PCHAR s = ParseString(Command->Action.sValue1);
    PCHAR e = NULL;
    MessageBox(NULL, "Test4", "Message", MB_OK);

    if &#40;Event->EventString != NULL&#41; // <------------------ HARD LOCK &#58;&#40;
    &#123;
        e = ParseString&#40;Event->EventString&#41;;  // <--------- HARD LOCK &#58;&#40; &#58;&#40; &#58;&#40;
    &#125;

    MessageBox&#40;NULL, "Test5", "Message", MB_OK&#41;;
    
    StringCbPrintf&#40;msg, 
        sizeof&#40;msg&#41;, 
        "Device Number&#58;  Command&#58; %s EventString&#58; %s",
        s,
        e&#41;;
    MessageBox&#40;NULL, "Test6", "Message", MB_OK&#41;;
    
    SafeFree&#40;s&#41;;  
    SafeFree&#40;e&#41;;
    
    MessageBox&#40;NULL, "Test7", "Message", MB_OK&#41;;
    
    GirderLogMessageEx&#40;DEVICE_NAME, msg, GLM_GOOD_ICON&#41;;
    
    if &#40; Command->ActionSubType == DEVICE_NUMBER &#41;
    &#123;
        
        // success = pClient->doAction&#40;CGirderCommand&#40;Command, Event->Payload, Event->PayloadSize&#41;&#41;;
    &#125;
    LeaveCriticalSection&#40;cs&#41;;
    MessageBox&#40;NULL, msg, "Message", MB_OK&#41;;
    
    StringCbPrintf&#40; status, statuslen, "SonyCLient command&#91;%s&#93;", &#40;success&#41;? "ok"&#58;"failed"&#41;;
    
    return retContinue;
&#125;

I tested "EventString"s using predefined and Girder Events that were typed in by hand.

It also does not work without the "ParseString" method call.

It hard locks with and without the "if" statement

It seems any access to Event->EventString causes a hard freeze (i.e. killed only with Task Manager) in Girder.

Thoughts?

[birty]

did you test whether eventstring was null?

[JohnHind]

Mike,

Are you by any chance testing this by triggering the Action using the Test Action button? If you do this there is no event. I'm not sure how the API treats this, but I'd guess that the Event pointer itself would be null which will give the symptoms you describe. I think you will need the test if (Event != NULL) to catch this. I think if Event is a valid pointer you can rely on Event->EventString being valid.

- John

[m1duckett]

Yes, I was using the "Test" event, button. That makes sense.

Shouldn't the Event be filled in even with the "Test" action? It could be a special event (i.e. the Test Event). I believe that even the test action would have meaningful data in the data structure.

Why is the NULL pointer not causing a null pointer exception then? Could it be that the pointer has an invalid address instead of NULL? If that is the case then it will be hard to test for an invalid pointer.

[Ron]

The test button doesn't create an event because it is treated special. I'll see if I can change this behaviour but at the moment that is not a high priority.

[Rob H]

Why is the NULL pointer not causing a null pointer exception then? Could it be that the pointer has an invalid address instead of NULL? If that is the case then it will be hard to test for an invalid pointer.

I'm guessing that it is generating a null pointer exception but that it isn't being displayed because you've still got hold of the critical section.

[m1duckett]

The test button doesn't create an event because it is treated special. I'll see if I can change this behaviour but at the moment that is not a high priority.

Ok. Would it be possible to document the API to indicate when it's possible to recieve NULL parameters?

[Ron]

Sure