I just updated my FPC cvs today.
My last update was 3 or 4 days ago.
I haven't updated Lazarus in a week or so.

The latest FPC update breaks building Lazarus from inside the IDE. For those familiar, if you try to install a package, Lazarus will optionally rebuild itself. Now it will either freeze or crash when you try to do this.

I tried to get a crash, but lately only got the freeze. Here's the last console out from Lazarus when it stops responding:

TPascalParserTool.BuildTree B OnlyIntf=False project1.lpr TMainIDE.DoNewEditorFile end unit1.pas
TMainIDE.DoNewProject end
[TExternalToolList.Run] /usr/bin/make ide OPT="-Cn" Xlib: sequence lost (0x10200 > 0x5c9a) in reply type 0x10! Xlib: sequence lost (0x10000 > 0x5c9a) in reply type 0x10!

I know this isn't a Lazarus list, but like I said, I haven't changed Lazarus code that worked on the CVS from a few days ago, so I assume it's an FPC issue.

Building from the console with make works fine. There was some recent discussion about this regarding Win32 building, but this is in Linux that I'm experiencing it.

Thanks,
Tony

The culprit is probably TProcess. I split out TProcess in Win32/unix parts, and did some major rewriting under Linux. However, all test programs ran fine, so I assumed it was OK to commit. I didn't test lazarus, however.

Can you do the following:

1. Start lazarus under strace:

strace -f -o laz.log lazarus

2. Let the IDE rebuild itself. If it freezes, kill it.

3. Send me the output of strace. Preferably only the part that appears around the Fork() call used to call 'make'. (the log may be HUGE)

Michael.

I spotted some things, that maybe related and may help someone to fix the bug:
If you change something in one of the interfaces of the low level LCL units like graphics.pp, the current fpc 1.9.5 then gives an internal error lcl/graphics.pp(378,1) Fatal: Internal error 200306067 or hangs up (consuming mem till dead), preferable in intfgraphics.pas or gtkwidgetset.pas.
Rebuilding the LCL clean compiles normally, so apparently fpc does not like some of its ppu files.
I was not able to reproduce this in a smaller example.

Mattias

I will send you the log in private: it is 140K zipped.

Vincent.

OK. I found the problem:

3688 execve("/usr/bin/make cleanall", ["/usr/bin/make", "cleanall"], [/* 36 vars */] <unfinished ...> 3680 <... gettimeofday resumed> {1092386057, 829845}, NULL) = 0 3688 <... execve resumed> ) = -1 ENOENT (No such file or directory)

It is, as I assumed, an error in TProcess. I will look for a fix.

Vincent, the problem is that the ExecVE call gets the complete TProcess.CommandLine property as the first argument, when it should only get the binary name. The error is probably in the MakeCommand() line in process.inc.

Michael.

Vincent, the problem is that the ExecVE call gets the complete TProcess.CommandLine property as the first argument, when it should only get the binary name. The error is probably in the MakeCommand() line in process.inc.

I don't know if you already know this or if you can use it, but there are other commands on linux like ExecVE wich can handle the complete commandline. (ExecXX)

Joost.

Actually, Linux (the kernel) only has ExecVE.

GNU libc has some more variants, but FPC does't use libc directly. FPC rolls its own set based on kernel.execve with native strings, see fpexec* in baseunix/unix

However these only became usable with 1.9.4+, and FCL has to work with 1.0.x too which is probably the reason for TProcess to use execve (avoid the shortstring versions of 1.0.x)

I know this: execl and friends :-)

Meanwhile, it has been fixed and committed. Lazarus recompiles itself again. Now still the Win32 version. Vincent Snijders is testing this, he still needs to apply a patch regarding pipes.

Michael.

Even without the patch Lazarus recompiles itself on win32 too. I think the error is not triggered with the new version anymore, because of a different way and sequence of opening the pipes.

Michael do you still want me to write the patch or shall we leave it as is, remembering that is such an error pops up again, we have to look at duplicating the pipe handles.

Vincent.

I did some redesigning, probably this has fixed the original problem.

Michael do you still want me to write the patch or shall we leave it as is, remembering that is such an error pops up again, we have to look at duplicating the pipe handles.

No problem, fine with me.

Michael.