VERY UNSTABLE linux version but rock solid windows version???

[knue]

Hi,

I have tried the CB-nightly-build-windows version yesterday and I was VERY impressed. Everything was rock solid, code completion was great, ...

Today I tried the Linux version. And actually I am a Linux user. I fetched sources from SVN. Here a list of bugs I could discover within 5 minutes:

- Just klick wildly on the tabs of the "Mangement"-pane. This switches my cursor to a strange thing and freezes even X completly. The only thing I can do is to switch to a real terminal (with CTRL+ALT+F1) and "killall codeblocks". I guess this is a bug in wx or the docking library but still VERY annoying.

- I still have a a Settings->Plugins' settings menu entry (but no submenus).

- Settings->Evironment crashes CB

- Settings->Editor freezes CB sometimes

- Codecompletion does not work. It seems that it works on a new project. But when you open other projects there won't be any codecompletion.

I hope I can get some help here or help in fixing these things by myself...

[takeshimiya]

Hi,

I have tried the CB-nightly-build-windows version yesterday and I was VERY impressed. Everything was rock solid, code completion was great, ...

Today I tried the Linux version. And actually I am a Linux user. I fetched sources from SVN. Here a list of bugs I could discover within 5 minutes:

- Just klick wildly on the tabs of the "Mangement"-pane. This switches my cursor to a strange thing and freezes even X completly. The only thing I can do is to switch to a real terminal (with CTRL+ALT+F1) and "killall codeblocks". I guess this is a bug in wx or the docking library but still VERY annoying.

- I still have a a Settings->Plugins' settings menu entry (but no submenus).

- Settings->Evironment crashes CB

- Settings->Editor freezes CB sometimes

- Codecompletion does not work. It seems that it works on a new project. But when you open other projects there won't be any codecompletion.

I hope I can get some help here or help in fixing these things by myself...

All those are known bugs on linux, I've experienced them all in SVN HEAD (including the one that hangs Xorg), except this:

- I still have a a Settings->Plugins' settings menu entry (but no submenus).

Do you mean that all plugins still loaded ok?
That's weird because SVN HEAD doesn't contain such menu (Settings->Plugins' settings).

Are you sure you didn't mixed RC2 with HEAD (or an older revision)?

EDIT
About this:

This switches my cursor to a strange thing and freezes even X completly. The only thing I can do is to switch to a real terminal (with CTRL+ALT+F1) and "killall codeblocks"

To me C::B/Xorg hangs very often in a drag-and-drop mouse state (dragging text, dragging panels, dragging anything).

[Der Meister]

Just a little note: I'm using Code::Blocks revision 2234 on Linux (compiled with gcc 3.4.5 and wxGTK 2.6.2 - unicode) with the following active plugins:
- Codestats
- Compiler
- DragScroll
- Debugger

And I have to say: I can't reproduce *any* of the bugs you mentioned (of course, without code-completion I can't reproduce the last one, but the others don't appear, too). And Code::Blocks is rock stable, too.

[knue]

- Hmm, I just did a "svn update". I will try a complete new checkout later. Perhaps this problem is solved then. I had older versions of CB installed on my system, too. Perhaps there is sth odd there.

- I use KDE and I have never had some drag 'n drop bugs befor. I guess this is a GTK problem then. BTW: It would be great to see a wxQT port

Which GTK and wx versions do you use?
What can I do to vanish CB completely from my hard disk? So I can be sure that I do not have strange rests on my computer. I will then try a reinstall.

[yop]

And I have to say: I can't reproduce *any* of the bugs you mentioned (of course, without code-completion I can't reproduce the last one, but the others don't appear, too). And Code::Blocks is rock stable, too.

Same here but without DragScroll. With CodeCompletion on, I can get the Settings->Editor freeze

[CmKaHo]

I can confirm Settings->Editor (rev. 2222). According to my observation - freeze occurs when I have open project based on wxWidgets template. When there are only projects based on console template Settings->Editor works (very slowly, but works). When in this working situation I open wxWidgets based project Settings->Editor freezes. The only way to get it work angain is to close wx based project. Save workspace, close C::B and reopen it. My config: Slackware 10.2@current, wxGTK2.6.2, C::B compiled from SVN on clean intall of slack.

[CmKaHo]

I forgot - all wxWidget based project are wxSmith enabled - they are little demo projects with a few dialogs.

Perhaps it helps.

[Michael]

With CodeCompletion on, I can get the Settings->Editor freeze

I do not have such problem with code completion, but with codestats plugin :?. If not C::B is pretty stable in Linux .

Best wishes,
Michael

[knue]

Wow, I tried a "svn update" and the new version seems very stable to me
This is the first time I see the code completion working properly in the linux version.
Almost all bugs are gone, except the annoying X freezing bug.
Perhaps this will go away when I upgrade to xorg 7 or wxGTK 2.6.3 or a new gtk version.

Thank you very much for the good work

[Michael]

Wow, I tried a "svn update" and the new version seems very stable to me
This is the first time I see the code completion working properly in the linux version.

 

Almost all bugs are gone, except the annoying X freezing bug.
Perhaps this will go away when I upgrade to xorg 7 or wxGTK 2.6.3 or a new gtk version.

X freezing bug? Could you explain a bit about this problem?

Best wishes,
Michael

[thomas]

X freezing bug? Could you explain a bit about this problem?

No bug. Badly set up display driver

[Michael]

X freezing bug? Could you explain a bit about this problem?

No bug. Badly set up display driver

Ok. Thanks for the info . I was quite at the point to ask him to post a bug on BerliOS (depending on his answer/bug though .

Anyway, I am quite surprised. My computer is old, its hardware components are old, but ubuntu 5.10 and Code::Blocks works without big problems .

Best wishes,
Michael

[knue]

X freezing bug? Could you explain a bit about this problem?

No bug. Badly set up display driver

Ok. Thanks for the info . I was quite at the point to ask him to post a bug on BerliOS (depending on his answer/bug though .

Anyway, I am quite surprised. My computer is old, its hardware components are old, but ubuntu 5.10 and Code::Blocks works without big problems .

Best wishes,
Michael

I don't think this has sth to do with a display driver. I have allready explained the problem in my first post:

- Just klick wildly on the tabs of the "Mangement"-pane. This switches my cursor to a strange thing and freezes even X completly. The only thing I can do is to switch to a real terminal (with CTRL+ALT+F1) and "killall codeblocks". I guess this is a bug in wx or the docking library but still VERY annoying.

I use:
2.6.14-gentoo-r3
x11-base/xorg-x11-6.8.2-r6
x11-libs/gtk+-2.8.13
x11-libs/wxGTK-2.6.2-r1

for non-gentoo useres: ignore the -rx at the end.

[takeshimiya]

I have that bug long ago (yes, I know how to setup Xorg, and yes, this doesn't happen in any other program, only with C::B).

I'm using:
C::B SVN (and the amd64 package too)
Ubuntu Breezy 64
wxWidgets 2.6

[thomas]

I use Fedora Core 5 and Ubuntu breezy badger on AMD64, no tampering, no crap, no hacking. Running nVidia drivers with TwinView on the Ubuntu machine, and default drivers on the notebook under Fedora Core.

Everything is perfectly stable and works nicely. Sunshine, lollipops, and rainbows everywhere...

[takeshimiya]

I'm thinking that the crash might be related to a combination of the video driver and something else then (coming from C::B, name it: C::B itself, wxWidgets, wxAUI, ...).

I'm using latest propietary Xorg ATI drivers, and certainly I use intensively other programs using GTK or wxWidgets (like VLC or Firefox), and never experienced any issue of this with another program.

Did I say that this most times happens when doing drag and drop on the panels?
The "strange cursor" that knue reffers about, it's the cursor in a DnD state.

BTW, dragging text also hangs C::B sometimes, altrough this is a Scintilla fault's because it happens in SciTE there too.
Dragging toolbars also hang C::B.

Of course, all of this happens sometimes, not always.

[knue]

Sunshine, lollipops, and rainbows everywhere...

I'd like to them, too

@drivers: I use nvidia driver. And because Takeshi Miya has the same problems with ATI I just don't think this is an driver issue.

@Takeshi Miya: Can you post your _exact_ version of gtk, xorg and wxGTK?

Perhaps this is a very nasty threading problem, which only happens with CPUs of a special speed. And there occurs a deadlock or sth like this.

[Ceniza]

I had that problem too (the one freezing the screen with the drag'n'drop cursor), but right now (revision 2260) I just cannot reproduce it again. I had that problem in an old computer too but haven't tried again (it's a computer in the University I have access to, but haven't used it for about two weeks).

The main change since then (excluding the newest Code::Blocks revision) has been switching to the ATI proprietary driver, and keeping the system up to date everyday.

If it's of any use, the OS is Kubuntu Dapper Flight 4 with the latest version available of everything in the ubuntu repositories, using the ATI proprietary driver also available there.

Kernel: 2.6.15-19-686 with SMP
wxGTK: 2.6.2-1
GTK: 2.8.16 and 1.2.10-18
X.Org: 7.0.0-0

In case the hardware also matters:
Processor: Pentium 4 3.0E (HT enabled)
Video: ATI Radeon 9800 Pro

Don't know if that help you find a pattern.

BTW, the old computer is a Pentium III 800MHz with a nVidia (don't know which one).

[takeshimiya]

Here are:

Distro: Ubuntu 64 Breezy Badger with all the updates applied. No hacking.
Kernel: 2.6.12-9-amd64-generic
GTK: 2.8.6-0ubuntu2
wxGTK: 2.6.1.1.1ubuntu2
Xorg: 6.8.2-77
Xorg-driver-fglrx: 8.20.8-1

CPU: Athlon 64 3000+
Video: ATI Radeon XPRESS 200

[CmKaHo]

At the first: Thanks ~ Settings->Editor problem is not a problem anymore.

After a while I can get problem mentioned by knue. It is really after a wildy clicking, but it is there. My X.Org is 6.9 and i have a standard vesa driver .

The problem is exactly as described by knue.

Except this problem, I have C::B (SVN2260) on 2 different machines Intel P4 3GHz(not SMP kernel)/1GB RAM + AMD Athlon XP /512MB RAM (slack 10.2@current, 2.4.31 kernel, wxGTK 2.6.2 ~ compiled) and running very well.

[Michael]

At the first: Thanks ~ Settings->Editor problem is not a problem anymore.

Did you have codestats plugin activated?

I tested rev2274 on Ubuntu 5.10 with codestats plugin and Settings->Editor crashes C::B.

Best wishes,
Michael

[tiwag]

the crash of CB under linux when using Settings->Environment is coming from

src/environmentsettingsdlg.cpp:180

comment this line out and it works

tested with svn rev 2274 under Ubuntu 5.10

[Der Meister]

As mandrav removed this option in revision 2268 this line has to be removed or it will crash.

But I wonder why I still have this option in the dialog (although it is disabled by the line src/environmentsettingsdlg.cpp:180)...  :shock:

[sethjackson]

As mandrav removed this option in revision 2268 this line has to be removed or it will crash.

But I wonder why I still have this option in the dialog (although it is disabled by the line src/environmentsettingsdlg.cpp:180)...  :shock:

Umm run update.bat or the update script..... I think this should fix it.....  :?

[Der Meister]

Well, I'm using the unix build system. And *actually* after one clean rebuild (and I did more than one since this change) this should be applied (yes, I also made a "make clean-zipfiles")...

[sethjackson]

Well OK. I don't have a *nix right now. On windows though you have to run update.bat or the *.xrc resources won't be updated. I learned this the hard way.

[Michael]

In Linux you should use ./update if you build C::B using CodeBlocks-unix.cbp.

Best wishes,
Michael

[Der Meister]

Yes, that's right. But I don't use Code::Blocks to build Code::Blocks.  :lol: I use plain configure and make. Works really well but I have no idea why this ressource was not updated... Normally make clean-zipfiles && make && make install does the trick... Or at least did it before :/

Edit: Just did a "make clean-zipfiles && make && make install" again and it worked - no idea what went wrong the last time... And now I get the crash, too, of course

[Michael]

I have used make & friends the first time I have built C::B and it worked fine. Anyway, it has taken more than 90 minutes. Using C::B, I can save some minutes and therefore go home earlier .

May be there is an option that should be used to update the ressources or may be a bug. Anyway, I am not an expert with make & friends.

Looking at the update file could also be useful or may be give some hint.

Best wishes,
Michael 

[tiwag]

it is not a make issue, i don't have it in my dialog anymore and i've built using autotools too.

[CmKaHo]

At the first: Thanks ~ Settings->Editor problem is not a problem anymore.

Did you have codestats plugin activated?

I tested rev2274 on Ubuntu 5.10 with codestats plugin and Settings->Editor crashes C::B.

Best wishes,
Michael

I am not sure. I never used codestat, but, as I can remember, I didn't disable anything. I am not running linux now, but I will test it tomorrow.

[CmKaHo]

At the first: Thanks ~ Settings->Editor problem is not a problem anymore.

Did you have codestats plugin activated?

I'm trying it now - it works fine.

I assume, that codestats i Code Statistic plugin (I have version 0.5).  Statistic is correct (I had to configure it, because configuration was empty). After showing statistic, Settings->Editor is working fine.

Regards,
Karel

[Michael]

I'm trying it now - it works fine.

I assume, that codestats i Code Statistic plugin (I have version 0.5).  Statistic is correct (I had to configure it, because configuration was empty). After showing statistic, Settings->Editor is working fine.

Thanks for testing . At the beginning, I did not have problems too (both worked . Later after I got the first crash, codestats always crashes C::B . May be it is a local problem, but I am not sure.

Best wishes,
Michael

[Der Meister]

It should be a local problem because the Code Statistics plugin works without any problem here.

[Michael]

It should be a local problem because the Code Statistics plugin works without any problem here.

Thanks for the info . I will give a look at it. I got the suggestion from Yannis that the codestats plugin could be responsible for the Settings-->Editor crash.

Anyway, for example I never get a Settings-->Environment crash, even if users report it (and one of my colleague too).

Best wishes,
Michael

[Der Meister]

the crash of CB under linux when using Settings->Environment is coming from

src/environmentsettingsdlg.cpp:180

comment this line out and it works

tested with svn rev 2274 under Ubuntu 5.10

As this is not yet commited I'll post this as patch to berlios.

[tiwag]

It should be a local problem because the Code Statistics plugin works without any problem here.

i have also crashes when i enable the codestat plugin
it crashes when i use PLugins->Code Statistics and when calling Settings->Editor
i've rebuild all plugins from the ContribPlugins-unix.workspace
it is not an ./update issue, also the devel version crashes
CB svn 2288, ubuntu 5.10