queued-up cout/cerr lines freeze CL

[petah]

Hi Eran,

CL seems to lock up long after a program has terminated if there are many queued-up log entries to stdout and/or stderr. The UI is completely frozen: you can't stop the debugger with shift-F5 or any other command. The choice is to either kill the CL process or wait for CL to catch up until it has processed all the pending entries and becomes responsive again, which can take quite a while.

I reproduced the problem with the attached sample; it's an extreme case with 1 million entries to exhibit the problem. It seems to be related to how CL queues up & then outputs messages to the "debugging:" window. You can confirm the program is already done by looking at "my.log" while CL catches up.

The same program runs instantaneously if you comment-out the "cout << " line or if you run the binary from outside CL with:

Code: Select all

./CL_logtest 2>&1 > my.log

Note that GDB terminal / full debugger loggging are disabled, so is Gtk redirect cerr / cout to log file. This is with CL trunk and wx trunk, under Debian Wheezy x64.

I had a similar problem once and from the CPU% it seems that Refresh()/Update() are called too often. Maybe you could cancel queued events on program termination since that window goes away anyway (and file logs are already written), or query wxKeyEvents every 200ms or so, or process queued-up logs in bulk when more than one line is pending.

Let me know if I can help further, thx & cheers,

-- p

[eranif]

Please try git head

Eran

[petah]

it seems faster but still gets stuck for a while, in the sample code I uploaded previously the log hangs at entry ~#237. It may be related to Linux's default pipe buffer size, I need to dig into my docs to find how I can modify it to confirm a correlation.

thx!

-- p

[petah]

Hi again Eran,

I just tried your very very lastest version: CL trunk as of now (pointing towards the camera ) and it is extremely fast. It cleans up over 20 million pending log entries in just 2 passes it seems, in about 1 second, so thx a lot for the fix.

A question that's been nagging me though: I can't tell whether CL uses an external xterm or its built-in terminal, it looks & behaves the same whether the checkbox in Editor Settings -> Terminal is on or off (I don't see a spawned xfce4-terminal). Is there a log entry or trick to determine which is running or if the xterm spawning failed, f.ex. due to wrong/missing environment variables? I noticed that $CodeliteDir keeps its old value from the preferences when compiling a new CL version, so I adjust it manually post-build. I was wondering if other env variables might be outdated or plain missing.

Thx again!

-- p

[eranif]

it looks & behaves the same whether the checkbox in Editor Settings -> Terminal is on or off (I don't see a spawned xfce4-terminal)

Strange, I tested it today and it seems to change the terminal from native to custom (I did that to compare behaviors of the terminals with your sample code)

Can you post a screenshot of both terminals?

Eran

[petah]

I think I only have the internal terminal with the "Debugging:" title. I've never seen another terminal AFAIK, i.e. with a wxFrame outside CL's, but I've been building CL from source for over a year now, while carrying forward my ~/.codelite prefs and possibly outdate env vars.

I'm guessing something is preventing xterm from being spawned. I tried to debug it a while back by intercepting the launch scripts with "echo" Bash scripts but got nowhere. Btw in Xfce4's task manager I only every saw pids whose path pointed to CL's main binary, never pids tied to launcher scripts.

I was wondering if launcher script failures are logged somewhere or if there's a list of env vars with corresponding values I could double-check.

thx again & cheers,

-- p

[eranif]

Ah, yes. While debugging you can only have the built-in terminal not an external terminal
You can send me a patch

Eran

[petah]

Well hot damn, I learned something today!

I run in debug 99% of the time and on rare release builds don't pay attention to logs or terminal output. Would I have to pipe GDB commands through an external terminal to have it work in debug mode or are there even worse traps along the way? Somebody will be waiting for LLDB

cheers,

-- p