Distributing dll, using boost.

[zerophase]

I'm writing an application using the Unity game engine. There's some com port code in there, and the C# com port code was significantly slowing the application down. So, I switched to a C++ plugin for the com port code, and was able to get a port and read much faster. The only issue is it uses boost asio, and won't run on other computers.

The project structure is:
/repo
|
-- UnityProject
|
-- SerialCode

When I build the C++ project it gets copied into the Unity 3D projects dll folder.

Under linker settings I have Additional Library Directories set as C:\Users\User\Documents\boost_1_60_0\stage\lib

I'm guessing I just need to include the asio dll with the project when I distribute it, but I don't see an asio dll or serial_port dll in the \stage\lib folder.

Anyone know how I would correctly distribute an app using a dll calling boost code?

[helios]

With the program running in the background, run Process Explorer. Select the process and click the button to display the lower pane that lists loaded executable images (note that there are two lower panes, and one displays open handles). Simply copy into the same directory as the main executable all the Boost DLLs that are loaded.

[zerophase]

Hmm, I don't see any boost specific dlls listed. I just see SerialBufferControl.dll. Which is included in the data folder alongside the .exe. Might boost show up if I just ran a C++ project using the same boost code?

[helios]

Then you're not dynamically loading any Boost code and you don't need to do anything special to distribute your code program.

[zerophase]

Then I'm trying to figure out why the program would crash on my friends computer while getting serial ports. (his machine is a bit messed up, so it might just be his system) When I run it in a virtual machine with the bluetooth ports being passed through it just freezes at the loading screen, when the serial ports are gotten. I'm able to get those ports with realterm, and read from them. I'm just going to let the virtual machine run for an hour to see if it's a speed issue, on less powerful hardware. Might I be linking the dll to a local folder directory?

[Computergeek01]

If the game crashed on your friends computer then it will have generated a crash report. Check: "Control Panel" -> "Administrative Tools" -> "Event Viewer" -> "Windows Logs" -> "Application" and look for a time stamp matching the latest crash. Generate one if you have to, but don't forget to hit Refresh in Event Viewer if you do this. Please then copy and paste the content of the Event Viewer entry in your next post.

OP wrote:

I'm able to get those ports with realterm, and read from them.

I assume you mean from the VM right? It's a bit hard to follow your troubleshooting steps here. Paragraphs are nice, so are bulleted lists :P

What share mode are the ports being opened up with? Is it possible that something in the other environment has handles to those ports open and your app is sitting and waiting for exclusive access?

[zerophase]

The ports are being passed through to VMWare. I had to pair the device to the host, and then pair it to the guest to get the ports through to the device.

I have some Windows specific code that finds the outgoing com port. I'll run that, and see if the port gets found.

I'll post that crash log once my friend is able to get to his computer.

**Update: Alright, I installed Visual Studio on the Virtual Machine, with msvc 14.0, and the executable is now crashing.

Here's the stack trace I get from that.

0x00007FFB986A1F08 (KERNELBASE) RaiseException
0x00007FFB81124572 (VCRUNTIME140) CxxThrowException
  ERROR: SymGetSymFromAddr64, GetLastError: 'Attempt to access invalid address.' (Address: 00007FFB81141D3B)
0x00007FFB81141D3B (SerialBufferControl) 
0x00007FFB81144CB8 (SerialBufferControl) Serial::Initialize
0x0000000003FF8DE6 (Mono JIT Code) (wrapper managed-to-native) Assets.Scripts.ForceCellManipulation.ForceCellHandler:InitializeSerial ()
0x0000000003FF8BFA (Mono JIT Code) Assets.Scripts.ForceCellManipulation.ForceCellHandler:Initialize ()
0x0000000003FF895C (Mono JIT Code) LoadForceCell:Start ()
0x0000000003FE8BBB (Mono JIT Code) (wrapper runtime-invoke) object:runtime_invoke_void__this__ (object,intptr,intptr,intptr)
0x00007FFB636441BF (mono) mono_set_defaults
0x00007FFB63598435 (mono) mono_runtime_invoke
0x00007FF717E27D15 (Test) [c:\buildslave\unity\build\runtime\scripting\backend\scriptinginvocation.cpp:191] ScriptingInvocation::Invoke 
0x00007FF717D80713 (Test) [c:\buildslave\unity\build\runtime\mono\monobehaviour.cpp:777] MonoBehaviour::InvokeMethodOrCoroutineChecked 
0x00007FF717D80ABA (Test) [c:\buildslave\unity\build\runtime\mono\monobehaviour.cpp:859] MonoBehaviour::InvokeMethodOrCoroutineChecked 
0x00007FF717D81395 (Test) [c:\buildslave\unity\build\runtime\mono\monobehaviour.cpp:486] MonoBehaviour::Start 
0x00007FF717C46279 (Test) [c:\buildslave\unity\build\runtime\gamecode\calldelayed.cpp:180] DelayedCallManager::Update 
0x00007FF717DE23DA (Test) [c:\buildslave\unity\build\runtime\misc\player.cpp:1589] PlayerLoop 
0x00007FF717EACBB5 (Test) [c:\buildslave\unity\build\platformdependent\winplayer\winmain.cpp:546] MainMessageLoop 
0x00007FF717EAF644 (Test) [c:\buildslave\unity\build\platformdependent\winplayer\winmain.cpp:963] PlayerWinMain 
0x00007FF718304138 (Test) [f:\dd\vctools\crt_bld\self_64_amd64\crt\src\crt0.c:275] __tmainCRTStartup 
0x00007FFB9B198102 (KERNEL32) BaseThreadInitThunk

I'm guessing that when Unity builds the dll, into the executable it's obfuscating what's going on with boost.

[Computergeek01]

- Code runs with no visible problems on one machine but crashes on another. Or in other words, code exhibits undefined behavior; check.
- Code fails at a point where resources are being allocated, in this case port initialization; check.
- Code throws an "Attempt to access invalid address." exception and crashes; check.

This has all of the hallmarks of a buffer overflow problem. Remember that CPP is not managed code, you have to allocate\deallocate some the buffers manually. Even if you think that you are allocating them all correctly then, as a diagnostic step, try arbitrarily doubling the size of all of your buffers and see if the problem goes away. If it does, then we know that you were not allocating enough memory for one or more of them. If it still fails then we are back to the drawing board.

Actually, you have an address right there. You can try stepping into the code with the debugger and look at which buffer it's trying to write to.

[helios]

I'm guessing that when Unity builds the dll, into the executable it's obfuscating what's going on with boost.

To me it looks rather that you tried to pass to .NET an incorrect pointer or a pointer to a buffer that was too small. Actually, it could also be an issue in your marshaling code?