[JFreyberger]

Hello,

I did some more tests and I found that this error only occurs if you click “Transfer files now” at the bottom of the screenshot I’ve added before. That’s where you configure this Custom Build Step. But the Build step works correct when it is automatically invoked during the build process. I think it should be easy for you to reproduce this when you also invoke it directly while configuring it.

Best regards,

Johannes

[JFreyberger]

Hallo,

thanks for this quick answer. But I still don’t know whether syncing a directory between a windows machine and a Raspberry PI with an actual Linux should work right out of the box or whether something has to be installed on the Raspberry to make this work. Is this Quicksync based on a certain Linux packet etc.?

Thanks and best regards,

Johannes

[JFreyberger]

Hi again,

I never solved this problem but found another solution. Now I once again would like to use this function but still see the same problem. I’ve added a picture with my settings. Do I have to install something on my Raspberry PI to make this working?

Thanks and best regards,

Johannes

Attachments:

You must be logged in to view attached files.

[JFreyberger]

Thanks for your suggestions. The settings according to step 11 didn’t really help so much, the time is now just spent somewhere else – see screenshot. (Do I have to enable the lightweight analyse for each file separately)

And I’ve also added some screenshots around the start of a debugging session. I think the main cluprit really is the boost beast which I’m using for my webserver. Even setting a breaking there takes several seconds. Other small test projects also using boost asio but without boost beast perform really fine.

Attachments:

You must be logged in to view attached files.

[JFreyberger]

Hi,

I’ve attached a screenshot of the parsing times. Actually I’m already using precompiled headers – that was one of the reasons to switch to VisualGDB. But I’m also the one who patched cc1plus.exx to work with big precompiled headers (see: https://sysprogs.com/w/forums/topic/cc1plus-exe-crash-when-using-large-precompiled-header-file/ ). So probably it’s a performance problem due to my large pch file (my pch.h-CXX.gch has a size of 338 MBytes). Unfortunately I also observer long times (30 secs and more) when starting a debug session and when the breakpoints are set (>10 secs) which are probably also related to the size of the pch file and the project at all. And I’m not really sure how I could solve this, as the vast majority of the pch size comes from the use of boost and especially boost::beast and it’s extensive usage of templates. But on the other hand I think boost beast is really worth using it and it’s a stable and modern code base.

Best, Johannes

Attachments:

You must be logged in to view attached files.

[JFreyberger]

Hi,

things really seem to have stabilized a lot since I rebootet my machine. So meanwhile Clang IntelliSense runs stable and shows valid results. One remaining thing is still the “thinking break” of 5-8 seconds when I invoke Goto Definition/Declaration. In the Clang IntelliSense Log this looks like the lines below (I have changed the filename just for this post, please see the 6 second break before “Starting operation: Exporting parse results”)

[+3:53:22.526] GoTo request: GotoDecl
[+3:53:22.526] Preparing for GoTo parsing
[+3:53:22.526] Starting GoTo parsing
[+3:53:22.526] Starting operation: Parse – Goto
[+3:53:22.527] Starting operation: Reparsing C:\xyz\xyz.cpp
[+3:53:22.530] C:\xyz\xyz.cpp has not changed since last build. Doing a quick recheck…
[+3:53:22.675] Checking if any PSFs for C:\xyz\xyz.cpp are outdated…
[+3:53:22.778] No changed PSFs found. Doing a CodeComplete run with minimal reparsing.
[+3:53:22.884] Checking if any PSFs for C:\xyz\xyz.cpp are outdated…
[+3:53:22.975] No changed PSFs found. Doing a CodeComplete run with minimal reparsing.
[+3:53:28.676] Starting operation: Exporting parse results
[+3:53:28.676] Checking C:\xyz\xyz.cpp for missing headers…
[+3:53:28.676] No missing headers for C:\xyz\xyz.cpp.

[JFreyberger]

Hi,

now I’ve activated the Clang log and I see lots of entries like this:

[+8:04:16.864] Starting operation: Reparsing C:\User_jof\CPP_LINUX\R3layPI\AudioManager.cpp
[+8:04:17.236] Starting operation: Parse – HighlightBraces
[+8:04:17.237] Operation completed: Parse – HighlightBraces [0 msec]
[+8:04:17.454] Starting operation: Reporting 153 + 0 extra sources to Clang engine…
[+8:04:17.455] Operation completed: Reporting 153 + 0 extra sources to Clang engine… [0 msec]
[+8:04:17.456] Failed to write to an IPC Port: Die Pipe wird gerade geschlossen.
[+8:04:17.456] while trying to parse C:\User_jof\CPP_LINUX\R3layPI\AudioManager.cpp
[+8:04:17.456] Stack trace:
[+8:04:17.456] Server stack trace:
[+8:04:17.456] at System.Runtime.Remoting.Channels.Ipc.IpcPort.Write(Byte[] data, Int32 offset, Int32 size)
[+8:04:17.456] at System.Runtime.Remoting.Channels.Ipc.PipeStream.Write(Byte[] buffer, Int32 offset, Int32 count)
[+8:04:17.456] at System.Runtime.Remoting.Channels.ChunkedMemoryStream.WriteTo(Stream stream)
[+8:04:17.456] at System.Runtime.Remoting.Channels.StreamHelper.CopyStream(Stream source, Stream target)
[+8:04:17.456] at System.Runtime.Remoting.Channels.Ipc.IpcClientHandler.SendRequest(IMessage msg, ITransportHeaders headers, Stream contentStream)
[+8:04:17.456] at System.Runtime.Remoting.Channels.Ipc.IpcClientTransportSink.ProcessMessage(IMessage msg, ITransportHeaders requestHeaders, Stream requestStream, ITransportHeaders& responseHeaders, Stream& responseStream)
[+8:04:17.456] at System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage(IMessage msg)
[+8:04:17.456] Exception rethrown at [0]:
[+8:04:17.456] at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
[+8:04:17.456] at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
[+8:04:17.456] at np.l3(z3 a)
[+8:04:17.456] at k02.t1(ps1 b, ay2 a)
[+8:04:17.456] at k02.h4.b(ps1 a)

[JFreyberger]

Hi,

thanks for your quick response. Although the times shown in your special popup for parsing the headers etc. by Clang IntelliSense seem quite good it sometimes takes several seconds to invoke Goto Definition/Declaration and also Declaration and Defintion seem to be mixed up. Sometimes it doesn’t work at all. Unfortunately the regular VC++ IntelliSense also doesn’t work as expected and as I’m used to it from my normal VC++ projects. There seems to be a problem around the pch file which cannnot be created correct. Could it be that VisualGDB breaks the regular VC++ IntelliSense for Linux projects?

[JFreyberger]

And another little thing: my compiler says

pch.h:1:9: warning: The precompiled header file should use an include guard, not #pragma once.

The page you pointed me to recommends the use of #pragma once.

• This reply was modified 2 years, 6 months ago by JFreyberger.

[JFreyberger]

OK, I tried to follow these steps … unfortunately this ended in a Clang IntelliSense Engine crash (see attached bitmap)

Attachments:

You must be logged in to view attached files.

[JFreyberger]

You are right – here’s what I changed. I found three positions where I changed 0x08000000 (=128 MByte) to 0x20000000 (=512 MByte). As we’re using little endian it’s the last byte which has to be changed:

position    old value                =>  new value
00DBF080    81 7D 08 00 00 00 08 76  =>  81 7D 08 00 00 00 20 76
00DBF0A0    C7 44 24 04 00 00 00 08  =>  C7 44 24 04 00 00 00 20
00DBF148    0C 00 00 00 08 76 0A B8  =>  0C 00 00 00 20 76 0A B8

• This reply was modified 2 years, 6 months ago by support. Reason: formatting

[JFreyberger]

… yeah … patching cc1plus.exe wasn’t as hard as I thought it to be and it seems to work 😉

[JFreyberger]

Hi,

thanks again. I also already thought about patching the binary but unfortunately I’m not experienced in decompiling and finding the right byte positions to be patched and I don’t know the appropriate tools. But I hope that sooner or later a fixed cc1plus.exe will be part of the toolchin as this seems to be fixed already for some time now in later versions of GCC. And if a 64 Bit toolchain becomes available this should also be no problem anymore – hopefully 😉

Best regards,

Johannes

[JFreyberger]

Hi,

thanks for your answer.

I already tried to reduce the size but as soon as you include <boost/asio.hpp> the pch file grows above 128 MBytes. At the moment I don’t think my problem is related to 32-bit as now I don’t see the “out of memory problem” anymore, which I had at the beginning when memory allocation of cc1plus.exe grew beyond 2 GB and which could be solved following this link https://www.intel.com/content/www/us/en/support/programmable/articles/000086946.html . Now I can watch in Task-Manager that cc1plus.exe memory can go above the 2 GB limit and also creating the pch file now seems works correct and it has a final size of 220 MBytes.

The problem now is when compiling other files and using this pch file as there seems to be a limit of 128 MByte for loading pch files in cc1plus.exe. That seems to be related to a fixed definition of  “static const size_t pch_VA_max_size = 128 * 1024 * 1024” in host-mingw32.c. My current idea would be to compile my own version of cc1plus.exe with an increased define or a dynamic allocation according to the actual size of the pch file and replace it in the current toolchain but so far I didn’t find good starting points how to do this. Also there’s some discussion in the internet about this hard coded limit and normally this should already be solved now for a while.

Can you please tell me, which version of host-mingw32.c you are using for the toolchain and what the current size limit for a pch file is according to this file?

Thanks and best regards,

Johannes

• This reply was modified 2 years, 6 months ago by JFreyberger.

[Author]

Posts