Compiler hangs in Debug mode

[anon77170705]

@mriffey

I am using 11.0.13244, if that helps.

I have no this version on my computer.

@mriffey

the MSBuild process seems to be jumping about between clalpe.dll!COMPILE 0x3878, and clalpe.dll!COMPILE 0x387F and the previously discussed CALLBACK offset.

This code corresponds to a module with functions to handle strings. This module is from TS Modula-2 times…

@mriffey

I dont see a way to tell which OBJ is being processed.

In the Process Explorer:

• Select the “Handles” item in the main-menu ->View->Lower Pane View submenu
• Find a file with the OBJ extension in the lower pane (press the Type column header for faster search)

[ChristianB]

Hello all, I’ve been reading through this thread as I’m experiencing the same problem with some .dlls and .exe when compiling in debug mode. We are using Clarion 10.0.12799. My tests have revealed that, as for now, the only way of making this work is by using msbuild 4.7.x and p.t in a win7(!) vm. Win10 (22H2) and 11 both have msbuild 4.8.x (or newer) and compiling fails with the symptom of “compiler hang” building the debug tables. I agree it’s probably not a real hang as cpu-usage is very low. So to summarize: msbuild 4.8.x and newer has this problem. Extremely frustrating as compiling in debug mode is crucial to have available. If anyone has anything new to report…shout out!

[anon77170705]

If someone still has this problem in C10/C11 and wants to help to find its roots, please contact me.

[KevinErskine]

I still am unable to get a DLL app to compile with debug on v11

[Bruce]

Thanks to work done by Alexy, With Mark Sarson providing examples, an issue in the linker has been identified. The root of the problem are procedure names being exported, with really long auto-generated (“mangled”) names.

Typically most parameter types are known by the mangler, and generated names are short. However if you are passing Objects as parameters, and passing a LOT of them, then you can exceed the linker limits, and that’s not good.

One source of this issue is CSPWCOM.INC. This file is used in Office Inside and File Explorer.

A new build of Office Inside (4.73) (CapeSoft Office Inside) has been uploaded with specific, unique, external names for these methods now set. This bypasses the mangler, and hence the length is no longer a limit.

OfficeInside 3 (and earlier) and File Explorer 5 (and earlier) also make use of this file. Since those are all obsolete now, no updates have been made to those (and none are expected to be made.) However if you are using one of these old products, and you are getting this issue, then please contact me and I should be able to supply you with an updated file. (And reasons not to be using old obsolete versions of things.)

Thanks again to Alexy for tracking down this is, and for Mark following through with examples to him.

[anon77170705]

@Bruce

The root of the problem are procedure names being exported, with really long auto-generated (“mangled”) names.

+building debug info records for such too long names incorrectly by compilers.

[KevinErskine]

That makes sense to me and the DLL i have the issue with uses Office 4.71 - i will see about updating

[anon77170705]

RZ gave permission to share fixed compilers and linker to users who can test them with projects causing the problem and who can provide the feedback. So, everybody who had the hang problem can ask me via PM.