Error processing uncompleted template specialization types

[zillemarco]

The C++ parse throws a System.AccessViolationException when parsing files.
The error is sent from Parser.cs@66: var result = Parser.ClangParser.ParseHeader(options);.

It doesn't always happen, for small files it's ok but as soon as I try to parse a (not too much) complex file, which includes a lot of other files, this error is thrown.

One thing that comes to my mind: could it be that since I'm using a 32bit compilation and the file includes a lot of other headers I run out of memory? For a single file, task manager shows me almost 200MB of memory used.

[ddobrev]

@zillemarco two items come to mind:

1. Upload your project or an equivalent so that we can take a look;
2. If you use more than one header, try the option for a unity build.

[zillemarco]

@ddobrev I've tried with unity build but I have problems with clang which gives me errors saying that some my classes, enum and structs are redefined, even though I use #pragma once on every file.

About uploading the project, well, it's quite big and unfortunately is owned by the company I work for, so I can't upload it unfortunately. Do you have some hints on what I could try to debug? Otherwise I'll try to reproduce the same error on another project and upload it.

In the meantime I'm trying to compile a 64bit CppSharp to see if it works.

[ddobrev]

@zillemarco don't waste your time, the NuGet already is 64-bit. Or do you mean you cannot use it because of the bug you fixed yesterday?
About the unity build and #pragma once: these redefinitions are strange. Unless it's too much work, could you temporarily change them to header guards instead and try again?

[zillemarco]

@ddobrev yeah, I can't use the NuGet because of the bug and yes, I was just looking that on Windows it is defaulted to build at 32bit :D

About the #pragma once I can't change them to header guard in the project since it would be a pain but I guess I can set up something similar without problems.

[ddobrev]

@zillemarco I'd rather not release a new NuGet yet because I prefer to collect a larger number of fixes. However, I can upload you a 64-bit archive, it's easy to me. Would you like to?

[zillemarco]

@ddobrev yes, I supposed a new NuGet wasn't doable :)

If you could give me a 64bit archive it would be awesome, thank you :D

[ddobrev]

There you go:

CppSharp.zip

This is for your fix yesterday. :)

[zillemarco]

Thanks :D I'll let you know if this works

[zillemarco]

@ddobrev that's it. With the 64bit build it doesn't crash. I have other problems with errors clang gives me, but it doesn't crash and there is no sign of AccessViolationException.

I'll hold on to that precious 64bit archive of yours untile the next NuGet :P

[ddobrev]

@zillemarco I am happy it's worked.
It makes some sense because we do use a substantial amount of memory, we can't get to optimising it. Perhaps the 32-bit C++# cannot address enough.
Have you had any other trouble so far? I hope you don't need to manually fix the generated code.

[zillemarco]

@ddobrev actually, I just fixed the errors clang was giving me and I tried again to parse that single file. I don't get any exception, the program crashes always after it reaches about 325MB (I see that from Visual Studio diagnostics running in debug). I am certain that it is still parsing since both the Postprocess and the Preprocess method of my ILibrary aren't yet called when it crashes, but I don't know the exact point because the program just closes itself, no errors, no messages.

And I was so happy :(

BTW: this happens even with unity build turned on.

[ddobrev]

@zillemarco I don't quite understand - are you saying it crashes with the 64-bit version as well?

[zillemarco]

@ddobrev Yes exactly. Could it be that I don't get any error from Visual Studio since I'm missing the .pdb?

[zillemarco]

@ddobrev the documentation doesn't explain this but, looking at the scripts to download the dependencies, to create a 64bit build of CppSharp do I just need to modify DownloadDeps.bat to pass amd64? It that's so I can compile the 64bit version myself and try to address this problem.

[ddobrev]

@zillemarco what's the point when you get the same problem with 64-bit? You might as well try the 32-bit build you already have.