Bug #19187 2013-11-08 10:44

yamakuzure

[SVN 9435] Crash without debug mode (iCCP, Gtk)

The current SVN revision 9435 crashes when I start C::B without options and wants to send a debug log. (Which has only modules information in it.)

SVN revision 9425 worked fine.

When starting with

codeblocks -d -v

it works and no longer crashes after

- A message on the console:

(codeblocks:10887): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width 18 and height -16

- A popup with the text

"iCCP: known incorrect sRGB profile"

-> Details shows the same message 9 times.

After clicking "OK" on the popup I can work with C::B normally.

Category
Application::Crash
Group
Platform:Linux
Status
Open
Close date
 
Assigned to
jenslody
yamakuzure 2013-11-08 13:07

I wanted to attach the generated "codeblocks.xml", but this system doesn't seem to allow it. (Or I am too blind to see the button.)

After a couple of starts, project/workspace loading and closing, Codeblocks starts normally again.

So the Warnings mentioned above do not seem to be related to the crash I experienced, because those remain if started with -d and -v option.

jenslody 2013-11-08 21:46

How did you compile C::B ?

I see the ICCP-messages only with C::B compiled with wx2.9+, and only if I start it from inside C::B

yamakuzure 2014-01-15 08:43

I am useing wxGTK-2.8.12.1 on gtk+-2.24.22.

The ICCP message eventually went away. Current version is SVN 9549 and the crash is now perfectly reproducable. Use Desktop-Icon: Crash. Start from console: No problem.

When I route the output to log files, the last lines of the log when crashing are:

========

ReopenEditor plugin activated

CppCheck plugin activated

Loading toolbar...

ClassBrowser::UpdateClassBrowserView(): No active project available.

Initializing plugins...

KeyBinder failed UpdateById on[922][Cu_t]

KeyBinder failed UpdateById on[921][_Copy]

KeyBinder failed UpdateById on[923][_Paste]

ClassBrowser::OnThreadEvent(): Updating class browser...

ClassBrowser::OnThreadEvent(): Class browser updated.

========

While the lines around that when I start C::B from a console are:

========

KeyBinder failed UpdateById on[922][Cu_t]

KeyBinder failed UpdateById on[921][_Copy]

KeyBinder failed UpdateById on[923][_Paste]

ClassBrowser::OnThreadEvent(): Updating class browser...

ClassBrowser::OnThreadEvent(): Class browser updated.

Loading workspace "/home/sed/pryde/PrydeWorX/pwxLib/pwxLib.workspace"

Loading project file...

Parsing project file...

========

So the last line in the log from the crashed instance is actually the last line possible before interactivity starts.

I do not know whether this helps, but I am using KDE-4.11.5 at the moment on a Gentoo linux 64bit system with kernel 3.12.7.

The desktop icon starter does not do anything funny but calling the codeblocks executable with enabled launch feedback. No dbus registration or any other options.

yamakuzure 2014-01-20 09:36

I *think* I have solved it. The permissions on the desktop file were 744 (-rwxr--r--) with the group set to my private group. After I changed it to 755 (-rwxr-xr-x) the start via desktop icon no longer produced a crash. Tested about a dozen times.

So while this is more a topic for an FAQ, the question remains why C::B crashes if the group (or other) permission(s) of a desktop file starter haven't have the executable bit set. I have other desktop files with the executable bit set only for the user, and none of them has a problem.

ID_65312 2014-03-02 10:17
The Problem is still there in my C::B 13.12 (stable version).

Every time I start codeblocks, it show me a "Debug report" dialog box (A debug report has been generated in the directory /tmp/codeblocks_dbgrpt-blabla).

I tried download C::B 13.12 from official site (instead of apt-get from wheezy-backport), and also tried download the sorce of C::B 13.12 then compile it myself, delete ~/.codeblocks, and reinstall, the problem is still there.

But if I start the codeblocks in terminal with -d option, everything seems OK.

Interestingly, if now close codeblocks, start again with command "codeblocks", with some probability, the program may work again, the last message is
	SmartIndentLua plugin activated
	Loading toolbar...
	Initializing plugins...
	KeyBinder failed UpdateById on[1433][_Export Source...]
	KeyBinder failed UpdateById on[1436][StrukTeX]
	KeyBinder failed UpdateById on[1437][PNG]
	KeyBinder failed UpdateById on[1435][PS]
	KeyBinder failed UpdateById on[3288][_Export]
	KeyBinder failed UpdateById on[923][Cu_t]
	KeyBinder failed UpdateById on[922][_Copy]
	KeyBinder failed UpdateById on[924][_Paste]
or fail, and show
	...
	FileManager plugin activated
	MouseSap plugin activated
	wxSmith - Aui plugin activated
	Added compiler "GNU GCC Compiler"
	Segmentation fault
or fail to start and generate a "debug report" as before
	...
	FileManager plugin activated
	MouseSap plugin activated
	wxSmith - Aui plugin activated
	Added compiler "GNU GCC Compiler"
	ClassBrowser::UpdateClassBrowserView(): No active project available.
	ClassBrowser::OnThreadEvent(): Updating class browser...
	ClassBrowser::OnThreadEvent(): Class browser updated.
	Aborted

I'm using Debian 7. One more interesting thing is that C::B can run without problem in my another computer which is also running Debian7....


There warnings and error(s) when run in terminal:
...
SmartIndentLua: loaded

(codeblocks:6206): GLib-GObject-WARNING **: instance of invalid non-instantiatable type `(null)'

(codeblocks:6206): GLib-GObject-CRITICAL **: g_signal_emit_valist: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed

(codeblocks:6206): GLib-GObject-WARNING **: instance with invalid (NULL) class pointer

(codeblocks:6206): GLib-GObject-CRITICAL **: g_signal_emit_valist: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed

(codeblocks:6206): GLib-GObject-WARNING **: instance of invalid non-instantiatable type `<invalid>'

(codeblocks:6206): GLib-GObject-CRITICAL **: g_signal_emit_valist: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed
Library finder plugin activated
...