CodeLite IDE

Hello!

On starting Codelite revision 4684, the following error appears in a message box, on the first one or two runs of the day. Subsequently it disappears:

"Codelite error: Impossible to get child process input (error 4: Interrupted system call)"

This has never occurred before and appears to have no effect on the correct functioning of the software.

Any ideas as to the likely problem?

Many thanks

Mark

Hi Mark,
are you using the official builds (provided by me / David)? or are you using the ones from the Ubuntu repositories ?

marvin_littlewood wrote:This has never occurred before and appears to have no effect on the correct functioning of the software.

I never seen this as well... maybe there is some more info in the 'Trace' windows?

Eran

Hi Eran

I am using the build downloaded from your website. I uninstalled via synaptic and then used the Debian installer to carry out the installation of the .deb file. Frustratingly, the problem is intermittent - today it did not occur. I do this every time a new version of codelite is announced by the program itself.

FWIW the message box appeared while the splash screen was up. After clicking on OK, the program loaded my last C++ project, in accordance with the appropriate setting and appeared to function fine.

I confess I did not look in the trace windows of CodeLite but will do so next time the problem occurs and report back.

Many thanks

Mark

Hi Eran

Update: The content of the Codelite Trace window appears to be the same with or without the error.

Many thanks

Mark

Hi Eran

I have tried:

1) a re-install from the dowloaded .deb file
2) a re-install from the repositories, newly added to your website
3) hiding my .codelite tree to force a clean start

None of these make any difference. Intermittently the dialog box appears. I have checked out the latest version and intend building it to see if I can get some decent debugging info.

Do you have any tips on the best procedure to follow?

Kind regards

Mark

Build codelite in debug mode and see if it output any wxWidget alert box
By default the wxWidgets alert boxes are hidden in release build
Eran

Hi Eran

I have a debug build up and running but apart from the message box, nothing else appeared. There were no wxWidgets alert boxes. I searched for all uses of wxMessageBox and looked at the context of those that had "error" in the title. It was not obvious which could produce the message:

"Impossible to get child process input (error 4: Interrupted system call)"

FWIW I found a description of how this error arises:

Interrupted system call
The symbolic name for this error is EINTR, errno=4.
======================================
The user issued an interrupt signal (usually Control-c) while the system was in the middle of executing a system call. When network service is slow, interrupting cd(1) to a remote-mounted directory can produce this message.

Proceed with your work, this message is purely informational.

An asynchronous signal (such as interrupt or quit), which a program was set up to catch, occurred during an internal system call. If execution is resumed after processing the signal, it will appear as if the interrupted programming function returned this error condition, so the program might exit with an incorrect error message.

The Ctr-C option is not applicable and the slow network option is unlikely.

Is there an error handler where I could put a break point to see what is going on?

Kind regards

Mark

marvin_littlewood wrote:There were no wxWidgets alert boxes

This dialog box comes from wxWidgets itslef and not from within codelite.

I did a quick search on wxWidgets sources, and it happens here:
wxGTK-2.8.10/src/unix/utilsunx.cpp:435

an error in call to select() syscall triggers this

HTH
Eran

Hi Eran

After a backtrace, it looks like the call to:
is eventually made during some boilerplate code in codelite's "app.cpp":
So I guess the problem is likely to be something for the wxWidgets people to resolve and not really a CodeLite problem. Quite what to tell them about an intermittent pipe signal is difficult to know because obtaining a repeatable scenario in which the failure occurs is not possible.

One argument that could be supported, if this signal is indeed for "information" only, is that wxWidgets should not report receipt of the signal via a message box but rather via a log file entry or equivalent and the system call restarted. The following link describes the scenario:

http://www.win.tue.nl/~aeb/linux/lk/lk-4.html

Many thanks for your help.

Mark

I disabled wxWidgets logging during startup (only until codelite registers its own wxLog target, i.e. the 'Trace' window)

Eran