call library function node: malloc to recieve a struct

[MikeS81]

Hi lmd2,
where do you get the error, at the second dll call within the case structure? Is it the RtlMoveMemory function? If yes try to lock it before read from it.

Hope it helps.
Mike

[rolfk]

---

@lmd2 wrote:
No good, the function still returns the same error: Invalid Buffer
I am attaching the diagram, don't see how the buffer could be better initialized

---

Sometimes APIs require passed in buffers to be initiliazed specifically. This means that some data members may need to be set to different values than 0. What you do right now, passing a cluster of all 0 values, is still equivalent to simply passing in an array of 0 values.

Rolf Kalbermatter

Message Edited by rolfk on 07-03-2008 06:58 AM

[lmd2]

Well in the C code, malloc seems to point/reference the STRUCT definition (from the header file) which is un-initialized; but I will confirm with the client if the malloc requires an initialized STRUCT. (but due to the holiday weekend here in the states I probably won't get a reply until Monday)
Thanks for sticking with this,
lmd2

Message Edited by lmd2 on 07-03-2008 03:47 AM

[rolfk]

---

@lmd2 wrote:
Well in the C code, malloc seems to point/reference the STRUCT definition (from the header file) which is un-initialized; but I will confirm with the client if the malloc requires an initialized STRUCT. (but due to the holiday weekend here in the states I probably won't get a reply until Monday)
Thanks for sticking with this,
lmd2

Message Edited by lmd2 on 07-03-2008 03:47 AM

---

malloc() is indeed NOT guaranteed to initialize the memory at all. Fro that you would need calloc. But you have not shown much of your code oder than how you allocate your buffer. Not event the function call. After all there might be some assignments to structure elements between the malloc and the function call or what about other function parameters that might be considered invalid and cause this error code?

Rolf Kalbermatter

[lmd2]

this function is part of a device driver, and can not run alone, here is a small sample app that uses this function, and others (initialize, configure, ...) also the header file where the STRUCT is defined, and a page out of the user manual defining this function.
I didn't expect you to get into it this deeply, thanx

[lmd2]

here is the same sample app in LabVIEW (not an elegant architecture, but the client wants a literal translation from C to LabVIEW)The sample crashes at this function, and returns INVALID BUFFER
if you actually wish to run it I can post the distribution for the DLL as well

[rolfk]

---

@lmd2 wrote:
here is the same sample app in LabVIEW (not an elegant architecture, but the client wants a literal translation from C to LabVIEW)The sample crashes at this function, and returns INVALID BUFFER
if you actually wish to run it I can post the distribution for the DLL as well

---

The buffer itself seems not to be initialized prior to calling. So I would concentrate on other possible problems and that would be that invalid parameters for the Init and Start function might cause the Get Packet function to return this error.

For instance the wMode and Mode options flags seems not very logical to me assuming they would be probably bit flags and not just numbers. Also their combination by ORing them seems wrong as they would overlap in the bit range of the integer.

Rolf Kalbermatter

[lmd2]

The initialize function is working on a dozen other sample apps: yes they are bit flags but if you go to the properties of the mode options menu ring you see that the options aren't integer but 4096 and 8192 respectively.
But you may very well be correct but in a config specific to this sample, I was thinking perhaps in the MTi configuration function which has setup parameters for device memory buffer, size in bytes for allocated buffers, etc - but I am using the exact same inputs as the C code - does this raise any flags for you?
thanx

[lmd2]

from the client:

"Larry,

This is a driver level failure that is being passed up to the library.  The driver portion of the aceGetCh10DataPkt does a check on the buffer it is trying to copy into with the following code:

    _try
    {
        ProbeForWrite(pCh10Pkt, sizeof(MTI_CH10_DATA_PKT) + (pdc -> MtiDataPoolBufferSize[Channel] -
            MTI_POOL_OVERHEAD_SIZE), sizeof(CHAR));
    }
    __except(EXCEPTION_EXECUTE_HANDLER)
    {
        return MTI_ERR_INVALID_BUFFER;
    }

The only way to fail this code block is for the size of the buffer being too small or NULL. There is no other way to get this error code. Maybe it's a bytes -> words problem? The aceMTIConfigure function used kb for all buffer sizes.

-Eric"

and my response:

National Instruments also felt that it was something to do with the config of the buffers, but I don't know if it is a byte / word issue.
in aceMTiConfiguration I am setting the device buffer to 524288 (512kB).
In the C sample, the malloc is done prior to calling aceMTIConfigure. In LabVIEW the memory space for aceGetCh10DataPkt is allocated on the fly when the function is called, I think this maybe the issue
let me run this past NI and see what they can come up with,
thanx for the insights

[lmd2]

I tried to create the instance of the bit stream prior to calling the MTiConfiguration function, and then using that bitstream to feed the input terminal of the GetCh10DataPkt function -

same error

guess the problem is that at the driver level, the hardware isn't aware that LabVIEW has allocated this space. Anyone know a work-around for this?