User forums > General (but related to Code::Blocks)

top on linux shows codeblocks not terminating after program shutdown

(1/3) > >>

frithjofh:
Hello everybody,

I'm using the svn build 6911 on a SuSE 11.1 x86_64 linux sistem with double processor.

I experience the strange behavior that after closing the program without any errors or misbehavior the process does not get terminated. After each execution and shutdown of  codeblocks one process is added. Using the top command I ended up having four running processes labeled codeblocks, each using around 50% CPU time and around 10% of memory. They can be killed without problem.

My configuration of c::b is set to allow for various instances of c::b running at a time and not allowing an already existing instance to be used. Compiler is set to use 3 threads.

The above mentioned behavior does not effect the functioning of the program itself, it only uses up resources.

Regards and greetings from Asturias

frithjofh

oBFusCATed:
Attach with gdb and print the backtrace...

If it isn't meaningful recompile C::B with debug info and repeat.

frithjofh:
OK, here is what I could do ...

First I started c::b, then I started gdb in a terminal and attached the running c::b through it's PID.

Then I loaded the symbol-file and continued execution.

I then terminated c::b from within c::b and killed the remaining phantom process from another terminal.

Copied the output into the attached file.

I never did this before, so please be forgiving ... I just did a very brief brute force brain input on a gdb online manual ...

The used wxWidgets installation is "out of the box", that is I did not compile it myself. What information do I get from that output? Do the last lines point to some error in wxPropGrid?

oBFusCATed:

--- Quote from: nausea on January 09, 2011, 02:57:42 pm ---I then terminated c::b from within c::b and killed the remaining phantom process from another terminal.

--- End quote ---
This is wrong, when you close C::B, goto the terminal with gdb and hit CTRL+C.
This breaks the process at its current position, then execute the bt command (look in the manual for the full version, which prints all threads).

Jenna:
I can see it also sometimes, but I use experimental packages of debian and I guess it's related.

It never happened to me with KDE, only on gnome.
It seems to be a deadlock in thread-handling, because the processes remain in status "futex_wait_queue_me" (seen with gnomes process-monitor).

At the moment it does not happen (as far as I see).
wxWidgets 2.8.10
libgtk2.0 2.23.3
libglib2.0 2.27.5

As far as I remember it does only happen if codecompletion- and compiler-plugin are enabled. If one of them is disabled it does not happen.

If build with wxWidgets debug-version, it tells me, that 4 threads are not terminated by C::B itself, and that wxWidgets has to kill them.
The four threads are the FileManager background threads (fileLoaderThread, uncLoaderThread, urlLoaderThread, delayedDeleteThread) and this is most likely not related to the deadlock.

Navigation

[0] Message Index

[#] Next page