How to find out why the compiler hangs ?

[Thaddy]

In that case it depends on platform: dwarf does not work properly on all platforms, some platforms require stabs.... That is documented.
If you leave out such information in your original report I can not test for that.
A clean build seems to resolve it in your case. (since -B helps) As it should in the general case where you change a base class as I described.

[Nitorami]

Alright, I'll give dwarf a try. Have no other option anyway, except disabling debug info entirely, or changing to Lazarus.

@Thaddy:

We may have a slight misunderstanding. I did not leave out any information, I just stumbled into this problem, tried to find the root cause, asked for some help with it,  and finally described what I found. Summarising:

- The compiler freezes when compiling my code.
- This was after I had changed a base class but that is essentially without importance. It has nothing to do with the act of changing the code, or the compiler using a wrong object file or such, or bad code. It happens on a clean fresh build.
- The issue is triggered by the specific code, but the code is correct. The units alone compile fine. There are no error messages when compiling the whole program, but just before generating the exe, the compiler feezes. Except when disabling debug info generation or using dwarf format for debug information.

-> The compiler has a bug which makes it freeze when compiling this specific piece of code with debug information in default format (presumably stabs). I would file this as bug report but I cannot throw the entire program at the developers, and I did not succeed in chopping it down to a small piece of code which still reproduces the issue.

[jamie]

Have you tried "-Xg"  Create External Debug file ?

[Noodly]

I cannot possibly submit the entire program for diagnosis.

Well that's obviously not true.

You might be worried about IP theft or you happen to be writing the ICBM guidance code for Kim Jong Un and he has a tank on your lawn keeping an eye on you, but you should trust the people who develop and support FPC/Lazarus and find a way of submitting the code to one of the recognised experts on the forum who I'm sure will step forward to try and help resolve this.

[molly]

The verbose option seemed like a good idea but as the compiler hangs, the messages are lost

Oops, yes of course my bad 

Nothing of interest to see what does show up ?

using -g would indicate to use the debug format as is common for the target. No reason to doubt that ?

It seems the strangest of things you've ran into, and haven't experienced that myself (but i'm using fp-ide less and less these days).

Are you able to reproduce with 3.0.4 (or perhaps even trunk) ?

[Nitorami]

Quote from: Nitorami on January 09, 2018, 10:01:23 pm

    The verbose option seemed like a good idea but as the compiler hangs, the messages are lost

Oops, yes of course my bad 

Maybe not quite; as this turns out to be related to the complier rather than the IDE, I can compile from the commandline and pipe the compiler messages into a text file, such as "fpc -B -g myprogram.pas > bugger.txt"; once the compiler hangs, I can interrupt it with Ctrl-C, and the OS will write the messages to the text file. However there is nothing unusual to find, and I would  not expect anything - the compile is ok, it's only building the exe file with debug information which fails.

using -g would indicate to use the debug format as is common for the target. No reason to doubt that ?

Not quite sure what you say. I understand that -g generates debug info in standard format for win32 (I think stabs, whatever this is - it hangs), while -gw forces dwarf format (whatever...it works ok).

Are you able to reproduce with 3.0.4 (or perhaps even trunk) ?

Yes, same with 3.0.4. Not tried trunk.

Have you tried "-Xg"  Create External Debug file ?

Yes, same. Hangs before writing the .dbg file. But works with dwarf.

You might be worried about IP theft or you happen to be writing the ICBM guidance code for Kim Jong Un and he has a tank on your lawn keeping an eye on you,

Well my life does not depend on writing software, and it is less a matter of trust but rather the fpc devs usually asking for a small and comprehensive piece of code to reproduce the issue. But the case may be different, I'll ask on the mailing list.

[soerensen3]

I was having a similar problem myself until yesterday and now the problem magically disappeared. Maybe it had to do with switching the debugging info to automatic but I'm not sure maybe it also was some heavy use of generics which in the end I did not really need. Those compiler/debugger errors can be so frustrating, for me it is mostly guessing. For me first the compiler crashed on both Linux and Windows and later I somehow resolved that but then the debugger was failing.

[Nitorami]

I spend the entire morning stripping down the code. Attached a bare skeleton, which still hangs on compilation. If anyone wants to try, simply use

Code: Pascal  [Select][+][-]

1. fpc -Mobjfpc -B -g fta_analyzer.pas

with FPC3.0.2 or 3.0.4, win32.

Mode Delphi will hang as well. The problem is not in the compilation, but the generation of debug information in default format (-g). It seems this has to do with how my Classes are nested. It works in dwarf format (-gw), though.

[Leledumbo]

The issue seems to be platform specific as well, using fpc 3.0.4 on x86_64-linux with the same exact compiler options doesn't hang the compiler. And yes, even on trunk if I target i386-win32 it hangs.

[PascalDragon]

I spend the entire morning stripping down the code. Attached a bare skeleton, which still hangs on compilation.

Thank you for redrucing the test case. With this I was able to reproduce your issue and fix it in revision 37969 (trunk only) [and even if it wouldn't be fixed, I added an internal error in r37968 so that the compiler won't loop ad infinitum anymore for this problem )

As a work around for 3.0.x you'll have to either use DWARF (don't know whether the 32-bit Windows GDB likes DWARF) or switch to the 64-bit compiler as that only uses DWARF.

[molly]

@nitorami:
Thank you for having taken the time to produce a reduced example. Worked like a charm (or perhaps better worded: made the compiler hang).

@PascalDragon
That seems a nasty one. Thank you for addressing it.