I've been struggling with a Cereal serialization issue for hours.
If my struct is serialized on Windows and deserialized on Android it fails with:
cereal::Exception: Failed to read 1 bytes from input stream! Read 0" failed
if the binary file is serialized on Android and deserialized on Windows it works.
And also works on Windows/Windows and Android/Android.
In all cases the binary file is exactly one byte.
I have exactly the same code running on Windows and Android Linux, and just one bool inside my serialized struct. (cereal version is the same on both builds)
This is what I do to serialize:
ofstream os_out("data.bin", std::ios_base::binary | ios::binary);
{
cereal::BinaryOutputArchive archive_out(os_out);
archive_out(a);
}
os_out << std::flush;
os_out.close();
And to deserialize:
std::ifstream os_in("data.bin", std::ios_base::binary);
{
cereal::BinaryInputArchive archive_in(os_in);
archive_in(a);
}
os_in.close();
Cannot figure out what is wrong...
Related
I have a cross-platform build. On a *nix platform using GCC, I use the __attribute__((warn_unused_result)) to notify the consumer of my API if a return value is not checked. I assumed that _Check_return does the same thing on MSVC, but it doesn't appear to be working the way I expect.
The following code does not produce a warning as I expect. Warnings are set to /Wall.
_Check_return_ _Must_inspect_result_ int foo()
{
return 100;
}
int main()
{
foo();
return 0;
}
Code compiles without warnings. What am I doing wrong (or what should I be using to generate warnings for unchecked return codes)?
SAL annotations like _Check_return_ and _Must_inspect_result_ are only checked during code analysis builds (either by starting a code analysis build in the IDE or by building with the /analyze flag on the command line).
See "Understanding SAL" on MSDN for more information.
When I run the following JUnit test, the memory of the java process is increasing constantly. After several hours, it uses more than 2go. However, when I look with jvisualvm, the heap and permgen size are stable, I don't see any leak. The test is run with -Xmx32m
public class TestCat {
public static class A { }
#Test
public void testCategory() {
for(;;) {
GroovyCategorySupport.use(A.class, new Closure<Object>(null) {
public Object call() { return null; }
});
}
}
}
I have tested it with Groovy 2.4.7, Windows and a JRE1.7_80, MacOS and JRE1.7_60.
I can't reproduce this bug with MacOS and JRE 1.8.0_91
I suppose it's related to a bug in the JRE1.7, and I am looking for a way to mitigate this issue:
my test is maybe wrong ? How is it possible to leak "system" memory without leaking heap space or permgen space ?
Is it a "known" bug or incompatibility between Groovy and a JRE 1.7 ?
How to use groovy category with a 1.7 jre and without suffering this memory leak ?
EDIT
I can reproduce this bug by calling VMPluginFactory.getPlugin().invalidateCallSites(), which translates with this "pure java" unit test :
public class TestSwitchPoint {
#Test
public void testSP() {
SwitchPoint switchPoint = new SwitchPoint();
for(;;) {
SwitchPoint old = switchPoint;
switchPoint = new SwitchPoint();
SwitchPoint.invalidateAll(new SwitchPoint[]{old});
}
}
}
In fact, only new SwitchPoint() is enough.
Yes, there is a bug in JRE. Native memory leak happens inside JVM at the following place:
(VM)
- os::malloc(unsigned long, unsigned short, unsigned char*)
- CHeapObj<(unsigned short)1792>::operator new(unsigned long, unsigned char*)
- JNIHandleBlock::allocate_block(Thread*)
- JNIHandleBlock::allocate_handle(oopDesc*)
- JNIHandles::make_weak_global(Handle)
- instanceKlass::add_member_name(int, Handle)
- MethodHandles::init_method_MemberName(Handle, methodOopDesc*, bool, KlassHandle)
- MethodHandles::init_method_MemberName(Handle, CallInfo&, Thread*)
- MethodHandles::resolve_MemberName(Handle, KlassHandle, Thread*)
- MHN_resolve_Mem
(JAVA)
- java.lang.invoke.MethodHandleNatives.resolve(MemberName, Class)
- java.lang.invoke.MemberName$Factory.resolve(byte, MemberName, Class)
- java.lang.invoke.MemberName$Factory.resolveOrNull(byte, MemberName, Class)
- java.lang.invoke.DirectMethodHandle.maybeRebind(Object)
- java.lang.invoke.DirectMethodHandle.bindReceiver(Object)
- java.lang.invoke.CallSite.makeDynamicInvoker()
- java.lang.invoke.MutableCallSite.dynamicInvoker()
- java.lang.invoke.SwitchPoint.<init>()
- Test.main(java.lang.String[])
It is a known issue with MemberNameTable: JDK-8152271. Unfortunately, it has been fixed only in JDK 9. By a lucky chance your problem is not seen on JDK 8 because of MethodHandles refactoring done in JDK-8050166. Although MemberNameTable probem remains, SwitchPoint() no longer creates new MemberNames. The latter fix was also backported to JDK 7u91.
Groovy runtime uses MethodHandles if it detects Java 7+. You may workaround this by patching VMPluginFactory to use Java 6 plugin. Here is the patch. If included in classpath before Groovy libraries, it will force Groovy runtime to use Java 6 - compatible VMPlugin.
So, you have the following options to workaround the memory leak:
use JRE 8 (recommended)
use JRE 7u91+
include VMPluginFactory patch in classpath
I recently upgraded my operating system from Windows XP to Windows 7 SP1 64 bit. We are using Visual Studio 2008 Professional Edition and Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production.
When I try to execute this code I am getting the below exceptions
try
{
CDatabase *pDatabase = CDatabaseConnection::getDatabaseConnectionProcessLog();
ORSProcessLog rsProcessLog(pDatabase);
CString strFilter = _T("SELECT PROCESS_ID, MESSAGE FROM OP_PROCESS_LOG");
rsProcessLog.SetRowsetSize(1);
if( !rsProcessLog.Open(CRecordset::dynaset, strFilter, CRecordset::appendOnly) )
return;
if( !rsProcessLog.CanAppend() )
return;
rsProcessLog.AddNew();
rsProcessLog.m_PROCESS_ID = gcsProcessID;
rsProcessLog.m_MESSAGE = csMessageA;
rsProcessLog.Update();
rsProcessLog.Close();
}
catch ( CDBException* pEx )
{
bException = true;
pEx->GetErrorMessage(szCause, 255);
}
catch( CException* pEx )
{
bException = true;
pEx->GetErrorMessage(szCause, 255);
}
where rsProcessLog is the CRecordset object using a successfully connected database pointer pDatabase
In 32- bit Debug version I get a message box at rsProcessLog.Close(); with the below text
Debug Error
Program: ......\Test.exe
HEAP CORRUPTION DETECTED: after Normal block (#506) at 0x0087F628. CRT detected that the application wrote to memory after end of heap buffer.
Memory allocated at f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dbcore.cpp(2626)
(Please Retry to debug the application)
In 32- bit Release version I get a message box at rsProcessLog.Close(); with the below text
Windows has triggered a breakpoint in Test.exe
This may be due to a corruption of the heap, which indicates a bug in Test.exe or any of the DLLS it has loaded.
This may also be due to the user pressing F12 while Test.exe has focus.
The output window may have more diagnostic information.
The above code was a working code in Windows XP with the rest of the env remaining the same and it continues to run in Windows XP but not in Windows 7. Any help will be greatly appreciated.
After some analysis of MFC CRecordest class I noticed that the problem appears after call to ::SqlSetPos where m_rgRowStatus array allocated on the heap become damaged (one byte more is written on the heap).
First and clean approach to problem is to force CRecordset class to use update/delete SQL statements instead of ::SqlSetPos function. To achive this you need to open your database using OpenEx method with CDatabase::userCursorLib option.
CDatabase db;
db.OpenEx(ConnectionString, CDatabase:useCursorLib);
This will change some CRecordset functionalities. See more at: http://msdn.microsoft.com/en-us/library/c689y99f.aspx
Second approach (dirty) is to reallocate m_rgRowStatus field, to use more memory on the heap, so call to ::SqlSetPos will not write to unallocated memory.
One way to do that is to override CRecordset::PreBindFields function:
void CMyDerivedRecordset::PreBindFields()
{
if ( ! (m_dwOptions & useMultiRowFetch) )
{
delete [] m_rgRowStatus;
m_rgRowStatus = new WORD[2];
}
CRecordset::PreBindFields();
}
You can do that in all of your CRecordset derived classes, or you can make one new CRecordset derived class which will become base class for all of your existing CRecordsetderived classes.
Visual C++ 6.0 is not supported on Windows 8, but we have a couple of legacy apps that still needs to be compiled with Visual C++ 6.0. :-(
It is possible to install Visual C++ 6.0 on Windows 8 by unchecking Data Access -> Change Options -> ADO, RDS and OLE DB Providers. See this SU-question and this thread. You also need to install SP6 afterwards.
Visual C++ 6.0 works perfectly on one computer, but two others cannot use the debugger. The same hardware, same version of Windows, same person doing the installation, same project. There must be some difference...
On the computers with the problem you can set a break point and the debugger will break into the IDE, but when you try do step, step into or run the code will crash with Unhandled exception in EXENAME.EXE (OLE32.DLL): 0xC0000005: Access Violation.
Walter Oney reports the exact same problem on MSDN forums, but they have no solution as VC++ 6.0 is unsupported.
As we have Visual C++ 6.0 working on one Win8 computer there is apparently way to do it. Any ideas on what the difference could be?
Turning off OLE RPC debugging (Tools / Options / Debug) works for me (Windows 8 Pro 64 bit, Visual C++ 6.0 with SP6). This solution was suggested (later) within the above-mentioned MSDN forum thread.
I was eventually able to get VS 6 working on Win 8 and Win 10. The basic steps were these:
Create a dummy file named msjava.dll in \Windows. (E.g., "echo >msjava.dll") Without this step, the VS 6 installer can't get very far.
Install VS 6 and SP 6.
Rename MSDEV.EXE to something else, such as MSDEVQ.EXE.
Create a compatibility database for MSDEVQ that excludes the fault-tolerant heap shim. Without this step, debugging a program that makes heavy use of HeapAlloc, etc., is excruciatingly slow.
For debugging, ensure that a breakpoint is tripped before any calls to OLE32 can occur. I include the following header early in the main program or (for an MFC app) the InitInstance function:
X64DebugHack.h:
#ifdef _DEBUG
// In order to be able to debug this application on x64, we need to single
// step across at least one statement before ole32.dll gets loaded. So
// always leave this breakpoint in place.
requiredbreakpoint:
int junkola = 42;
// Check to see that there was a breakpoint...
PUCHAR pjunk;
_asm lea eax, requiredbreakpoint
_asm mov pjunk, eax
if (*pjunk != 0xCC)
AfxMessageBox("Required breakpoint was not set prior to loading OLE32.DLL -- single stepping will not be possible during this debugging session.", MB_OK | MB_ICONHAND, 0);
LoadLibrary("OLE32");
#endif
Write an extension DLL that provides a "Stop Debugging" button. The extension has to search and destroy debug handles, which have a different handle type in Win64 than in Win32. The mechanics of writing the extension are beyond the scope of this forum, but the code that does the actual work is here:
CCommands::HelpAssistantKill:
typedef LONG NTSTATUS;
#define NT_SUCCESS(Status) (((NTSTATUS)(Status)) >= 0)
#define STATUS_INFO_LENGTH_MISMATCH ((NTSTATUS)0xC0000004L)
enum SYSTEM_INFORMATION_CLASS {
SystemHandleInformation = 16,
};
typedef NTSTATUS(NTAPI *PNTQUERYSYSTEMINFORMATION)(SYSTEM_INFORMATION_CLASS, PVOID, ULONG, PULONG);
typedef struct _SYSTEM_HANDLE_INFORMATION {
ULONG ProcessId;
UCHAR ObjectTypeNumber;
UCHAR Flags;
USHORT Handle;
PVOID Object;
ACCESS_MASK GrantedAccess;
} SYSTEM_HANDLE_INFORMATION, *PSYSTEM_HANDLE_INFORMATION;
typedef struct _SYSTEM_HANDLE_INFORMATION_DATA {
ULONG HandleCount;
SYSTEM_HANDLE_INFORMATION HandleInformation[1];
} SYSTEM_HANDLE_INFORMATION_DATA, *PSYSTEM_HANDLE_INFORMATION_DATA;
#define HANDLE_TYPE_DEBUG_OBJECT 11 // correct value for Win8 x64
STDMETHODIMP CCommands::HelpAssistantKill()
{ // CCommands::HelpAssistantKill
AFX_MANAGE_STATE(AfxGetStaticModuleState());
BOOL didit = FALSE;
HMODULE hDll = NULL;
PSYSTEM_HANDLE_INFORMATION_DATA phi = NULL;
do { // do once
HRESULT hr;
// Locate NtQuerySystemInformation within NTDLL.DLL
hDll = LoadLibrary("NTDLL");
if (!hDll)
break;
PNTQUERYSYSTEMINFORMATION NtQuerySystemInformation = (PNTQUERYSYSTEMINFORMATION) GetProcAddress(hDll, "NtQuerySystemInformation");
if (!NtQuerySystemInformation)
break;
// Do an initial query to get the number of handles presently open in the system.
// This is a large number. The returned length value is meaningless for this query.
SYSTEM_HANDLE_INFORMATION_DATA hid;
DWORD junk;
NTSTATUS status = (*NtQuerySystemInformation)(SystemHandleInformation, &hid, sizeof(hid), &junk);
if (!NT_SUCCESS(status) && status != STATUS_INFO_LENGTH_MISMATCH)
break;
ULONG length = sizeof(SYSTEM_HANDLE_INFORMATION_DATA) + (hid.HandleCount - 1) * sizeof(SYSTEM_HANDLE_INFORMATION);
phi = (PSYSTEM_HANDLE_INFORMATION_DATA) new UCHAR[length];
if (!phi)
break;
// Get a list of all handles open in the system
status = (*NtQuerySystemInformation)(SystemHandleInformation, phi, length, &junk);
if (!NT_SUCCESS(status))
break;
// Find and close any debug objects that are open in this instance of Visual Studio.
DWORD pid = GetCurrentProcessId();
ULONG ihandle;
for (ihandle = 0; ihandle < hid.HandleCount; ++ihandle)
{ // for each open handle
PSYSTEM_HANDLE_INFORMATION p = phi->HandleInformation + ihandle;
if (p->ProcessId != pid || p->ObjectTypeNumber != HANDLE_TYPE_DEBUG_OBJECT)
continue;
if (CloseHandle((HANDLE) p->Handle))
didit = TRUE;
} // for each open handle
// Instruct DevStudio to stop
BSTR bsStopDebugging = SysAllocString(L"DebugStopDebugging");
if (!bsStopDebugging)
break;
hr = m_pApplication->ExecuteCommand(bsStopDebugging);
SysFreeString(bsStopDebugging);
if (hr != 0)
break;
} // do once
while (FALSE);
if (phi)
delete[] phi;
if (hDll)
FreeLibrary(hDll);
if (!didit)
{ // didn't do anything
MessageBox(NULL, "Unable to find and close any debug object handles", "HelpAssistant", MB_OK | MB_ICONINFORMATION);
} // didn't do anything
return S_OK;
} // CCommands::HelpAssistantKill
This felt like a pretty heroic effort, but I had about a million lines of code built on VS 6 that I had to keep working. Now that I've built myself a workable macro processor for VS 2015, I may undertake a conversion of this application.
One wrinkle -- I had the very same same issue with the Visual C++ 6.0 debugger on Windows 8.1 . But I could not find the RPC debug option under the Tools/Options/ Debug option described in the answer above. Instead I had to go into the registry editor and delete the RPC Debug key that is mentioned in the same MSDN thread referenced above (maybe it was there because I had already installed later versions of Microsoft Visual Studio before I had installed 6.0) . The debugger works great now, and thanks to previous posters!
The issue is due to incompatible “ADO, RDS and OLE DB Providers” comes along with the Visual C++ 6.0.
Please follow the below mentioned steps to disable ADO, RDS and OLE DB Providers and install the Visual C++ 6.0 –
1) Start the installation as usual.
2) Click on Custom installation when installer will ask for type of installation.
3) Click on Data Access from available items and then click on ‘Change Option’.
4) In new window de-select “ADO, RDS and OLE DB Providers” and click OK (ignore the warning).
5) Click on continue to proceed with the installation.
6) Installer will not freeze during ‘Updating components’ and will install successfully.
7) Now install the service pack ‘Vs6sp6’ and it will also install successfully.
Non of above answers work for me.
Solution from this site fix my problem.
Re-register ole32.dll file and check if it helps.
Click Start, type cmd in the Start search.
Right click on cmd and click on Run as administrator.
In the Command prompt, type the following commands and hit ENTER
after each command.
takeown /f ole32.dll
regsvr32 ole32.dll
Close the Command prompt after running the above two commands.
Try to run the application and check is the issue persists.
I'm working with a third party COM server with its own custom interface that sets and gets structs as some of its properties. As it happens I'm using C++ for the client. I've posted some representative code from the IDL file below with names changed and GUIDs removed.
Is the packing of the structure defined or is it just good fortune that my client code happens to use the same packing settings that the COM server was built with? Would it be likely to go wrong in projects where the default C++ compiler packing settings had been changed? Is there a pragma pack setting that I could use to make sure the client compiler packing settings are correct?
I can't see any packing pragmas or statements in either the IDL or the header file generated from MIDL. What would happen if the client was in C# or VB instead? Is the packing behaviour more clearly specified if called via the IDispatch mechanism?
struct MyStruct
{
int a, b;
};
[
object,
uuid( /* removed */ ),
dual,
nonextensible,
pointer_default(unique)
]
interface IVideoOutputSettings : IDispatch{
[propget, id(1), HRESULT MyProperty([out, retval] struct MyStruct* pVal);
[propput, id(1), HRESULT MyProperty([in] struct MyStruct newVal);
/* other methods */
};
The default packing is along 8-byte boundaries, according to the MIDL command line switch reference here:
/Zp switch # MSDN (MIDL Language Reference)
Other parts of your code are more likely to break first if the pack value is changed, as the IDL file is usually pre-compiled ahead of time, and it is rare that someone will deliberately alter the command line switches given to MIDL (but not so rare that someone could fiddle with the C-scope #pragma pack and forget to restore the default state).
If you have a good reason to alter the setting, you can explicitly set the packing with a pragma pack statement.
pragma Attribute # MSDN (MIDL Language Reference)
It is pretty good fortune that no party has changed any setting that would interfere with the default packing. Can it go wrong? Yes, if someone goes out of their way to change the defaults.
When using an IDL file, the details are typically compiled into a typelib (.tlb), and it is assumed that the platform are the same for both servers and clients when using the same typelib. This is suggested in the footnotes for the /Zp switch, as certain values will fail against certain non-x86 or 16-bit targets. There can also be 32bit <-> 64bit conversion cases that could cause expectations to break. Unfortunately I don't know if there are even more cases out there, but the defaults do work with minimal fuss.
C# and VB do not have any intrinsic behavior to handle information in a .tlb; instead, a tool like tlbimp is typically used to convert COM definitions into definitions usable from .NET. I can't verify whether all expectations succeed between C#/VB.NET and COM clients and servers; However, I can verify that using a specific pragma setting other than 8 will work if you reference a .tlb that was created from an IDL compiled under that setting. While I wouldn't recommend going against the default pragma pack, here are the steps to perform if you'd like a working example to use as a reference. I created a C++ ATL project and a C# project to check.
Here are the C++ side instructions.
I created an ATL project called SampleATLProject with the default settings in Visual Studio 2010, no fields changed. This should create a dll project for you.
Compiled the project to assure that the proper C-side interface files are being created (SampleATLProject_i.c and SampleATLProject_i.h).
I added an ATL Simple Object called SomeFoo to the project. Again, no defaults were altered. This creates a class called CSomeFoo that is added to your project.
Compile SampleATLProject.
I right-clicked the SampleATLProject.idl file, then under the MIDL settings, set the Struct Member Alignment to 4 bytes (/Zp4).
Compile SampleATLProject.
I altered the IDL to add a struct definition called 'BarStruct'. This entailed adding a C-style struct definition with the MIDL uuid attribute, and an entry in library section referencing the struct definition. See snippet below.
Compile SampleATLProject.
From the Class View, I right-clicked on ISomeFoo and added a method called FooIt, that takes a struct BarStruct as an [in] parameter called theBar.
Compile SampleATLProject.
In SomeFoo.cpp, I added some code to print out the size of the struct and throw up a Message Box containing the details.
Here is my IDL for the ATL project.
import "oaidl.idl";
import "ocidl.idl";
[uuid(D2240D8B-EB97-4ACD-AC96-21F2EAFFE100)]
struct BarStruct
{
byte a;
int b;
byte c;
byte d;
};
[
object,
uuid(E6C3E82D-4376-41CD-A0DF-CB9371C0C467),
dual,
nonextensible,
pointer_default(unique)
]
interface ISomeFoo : IDispatch{
[id(1)] HRESULT FooIt([in] struct BarStruct theBar);
};
[
uuid(F15B6312-7C46-4DDC-8D04-9DEA358BD94B),
version(1.0),
]
library SampleATLProjectLib
{
struct BarStruct;
importlib("stdole2.tlb");
[
uuid(930BC9D6-28DF-4851-9703-AFCD1F23CCEF)
]
coclass SomeFoo
{
[default] interface ISomeFoo;
};
};
Inside the CSomeFoo class, here is the implementation for FooIt().
STDMETHODIMP CSomeFoo::FooIt(struct BarStruct theBar)
{
WCHAR buf[1024];
swprintf(buf, L"Size: %d, Values: %d %d %d %d", sizeof(struct BarStruct),
theBar.a, theBar.b, theBar.c, theBar.d);
::MessageBoxW(0, buf, L"FooIt", MB_OK);
return S_OK;
}
Next, on the C# side:
Go to the debug or desired output directory for SampleATLProject and run tlbimp.exe on the .tlb file generated as part of the C++ project output. The following worked for me:
tlbimp SampleATLProject.tlb /out:Foo.dll /namespace:SampleATL.FooStuff
Next, I created a C# console application, and added a reference to Foo.dll to the project.
In the References folder, go to the Properties for Foo and turn off Embed Interop Types by setting it to false.
I added a using statement to reference the namespace SampleATL.FooStuff as given to tlbimp, added the [STAThread] attribute to Main() (the COM apartment models have to match for in-proc consumption), and added some code to call the COM component.
Tlbimp.exe (Type Library Importer) # MSDN
Here is the source code for that console app.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using SampleATL.FooStuff;
namespace SampleATLProjectConsumer
{
class Program
{
[STAThread]
static void Main(string[] args)
{
BarStruct s;
s.a = 1;
s.b = 127;
s.c = 255;
s.d = 128;
ISomeFoo handler = new SomeFooClass();
handler.FooIt(s);
}
}
}
Finally, it runs and I get a modal popup with the following string displayed:
Size: 12, Values: 1 127 255 128
To be sure that a pragma pack change can be made (as 4/8 byte packing are the most common alignments used), I followed these steps to change it to 1:
I returned to the C++ project, went to the properties for SampleATLProject.idl and changed the Struct Member Alignment to 1 (/Zp1).
Recompile SampleATLProject
Run tlbimp again with the updated .tlb file.
A warning icon will appear on the .NET File Reference to Foo, but may disappear if you click on the reference. If it doesn't, you can remove and re-add the reference to the C# console project to be sure it is using the new updated version.
I ran it from here and got this output:
Size: 12, Values: 1 1551957760 129 3
That's weird. But, if we forcefully edit the C-level pragma in SampleATLProject_i.h, we get the correct output.
#pragma pack(push, 1)
/* [uuid] */ struct DECLSPEC_UUID("D2240D8B-EB97-4ACD-AC96-21F2EAFFE100") BarStruct
{
byte a;
int b;
byte c;
byte d;
} ;
#pragma pack(pop)
SampleATLProject is recompiled here, no changes to the .tlb or .NET project, and we get the following:
Size: 7, Values: 1 127 255 128
Regarding IDispatch, it depends on whether your client is late-bound. Late-bound clients have to parse the type information side of IDispatch and discern the proper definitions for non-trivial types. The documentation for ITypeInfo and TYPEATTR suggests that it is possible, given that the cbAlignment field provides the information necessary. I suspect most will never alter or go against the defaults, as this would be tedious to debug if things went wrong or if the pack expectations had to change between versions. Also, structures are not typically supported by many scripting clients that can consume IDispatch. One can frequently expect that only the types governed by the IDL oleautomation keyword are supported.
IDispatch interface # MSDN
IDispatch::GetTypeInfo # MSDN
ITypeInfo interface # MSDN
TYPEATTR structure # MSDN
oleautomation keyword # MSDN
Yes, structs are a problem in COM. If you use IUnknown based interfaces then you'll have to roll the dice with proper compiler settings. Few reasons to change the default.
If you use COM Automation then you have to declare the struct with a typedef in the .IDL. So that the client code can use IRecordInfo to access the structure properly, guided by the type library info. All you have to do is ensure that your compiler's /Zp setting matches midl.exe's /Zp setting. Not hard to do.
You sail around the problem entirely by realizing that any structure can be described by an interface with properties. Now it doesn't matter.