Settings don't get saved (svn 4454)

User forums > Help

<< < (10/16) > >>

johne53:
Sorry Mandrav, I don't even get to the stage of being able to produce a backtrace as something seems to be causing gdb to crash. Here's what I see in the terminal window if I type what you said and then try to debug my simple 'Hello World' app.

--- Code: ---johne53@AMD2000:~> gdb codeblocks
GNU gdb 6.5
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i586-suse-linux"...Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) run
Starting program: /usr/local/bin/codeblocks
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread -1234463024 (LWP 4579)]
[New Thread -1239315568 (LWP 4590)]
[New Thread -1247708272 (LWP 4591)]
[New Thread -1256100976 (LWP 4592)]
[New Thread -1264493680 (LWP 4593)]
[New Thread -1273934960 (LWP 4594)]
[New Thread -1285194864 (LWP 4595)]
[New Thread -1294054512 (LWP 4606)]
[Thread -1294054512 (zombie) exited]
[New Thread -1294054512 (LWP 4616)]
[Thread -1294054512 (zombie) exited]
[New Thread -1305478256 (LWP 4617)]

(codeblocks:4579): Gtk-CRITICAL **: gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed
-------------- Build: Debug in HelloWorld ---------------
[Thread -1305478256 (zombie) exited]
Target is up to date.
Nothing to be done.

Segmentation fault
--- End code ---

and then the terminal window throws me back to my normal command prompt (with Code::Blocks still running). Could this be because I'm running C::B within gdb and then using it to debug a second program simultaneously?

stahta01:

--- Quote from: johne53 on September 26, 2007, 07:40:36 am ---I can't help feeling that this is an "out-of-step" problem. Does C::B have any other dependencies - or require a minimum level of certain other libraries - apart from wxGTK? So far I've just been concentrating on wxGTK but presumably there are other dependencies too? The annoying thing is that it all worked fine when I first installed C::B. These problems started to appear gradually, as & when I updated it - which again makes me think that I should have been updattng something else to keep in step.

--- End quote ---

wxGTK depends on GTK (Gimp Tool Kit) which is also called GTK+

You might want to post what GTK+ version you use, in case it is an GTK+ issue, but it sounds to me to NOT be an GUI issue so I would not expect it to be GTK+, but wxGTK.

Tim S

johne53:
Thanks Tim and everyone who's helping with this. I realise that it's not an everyday problem and I do want to get to the bottom of it as I was very impressed with Code::Blocks before these weird things started happening.

I have both GTK and GTK2 installed. GTK is version 1.2.10-926. GTK2 is version 2.10.6-13. I also have GTK2-devel installed (which is also 2.10.6-13) but not GTK-devel. I don't have any of the other GTK options, such as GTK1-compat-devel or any of the 'doc' libraries.

If there's a list somewhere where I could see what dependencies are needed, it would be quite simple for me to report my current versions.

stahta01:

--- Quote from: johne53 on September 26, 2007, 05:38:02 pm ---Thanks Tim and everyone who's helping with this. I realise that it's not an everyday problem and I do want to get to the bottom of it as I was very impressed with Code::Blocks before these weird things started happening.

I have both GTK and GTK2 installed. GTK is version 1.2.10-926. GTK2 is version 2.10.6-13. I also have GTK2-devel installed (which is also 2.10.6-13) but not GTK-devel. I don't have any of the other GTK options, such as GTK1-compat-devel or any of the 'doc' libraries.

If there's a list somewhere where I could see what dependencies are needed, it would be quite simple for me to report my current versions.

--- End quote ---

Code::Blocks and wxGTK only cares about the GTK version 2 or above. So, GTK2 in your case.

Tim S

johne53:
Mandrav - I've got to the stage where I can produce a backtrace from the "failure to save settings" problem. Here's my gdb output prior to the crash:-

--- Quote ---johne53@AMD2000:/usr/local/bin> gdb codeblocks
GNU gdb 6.5
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i586-suse-linux"...Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) run
Starting program: /usr/local/bin/codeblocks
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread -1234319664 (LWP 5010)]
[New Thread -1239172208 (LWP 5021)]
[New Thread -1247564912 (LWP 5022)]
[New Thread -1255957616 (LWP 5023)]
[New Thread -1264350320 (LWP 5024)]
[New Thread -1273791600 (LWP 5025)]
[New Thread -1286108272 (LWP 5026)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1234319664 (LWP 5010)]
0xb691417c in _int_malloc () from /lib/libc.so.6
--- End quote ---

The segmentation fault happens if I try to exit C::B after changing some settings in Settings->Compiler and debugger. Note the line Failed to read a valid object file image from memory. I can't help feeling that's significant. It happens every time I launch C::B within gdb.

and here's the backtrace:-

--- Quote ---(gdb) bt
#0 0xb695b17c in _int_malloc () from /lib/libc.so.6
#1 0xb695d0c5 in malloc () from /lib/libc.so.6
#2 0xb6b05477 in operator new () from /usr/lib/libstdc++.so.6
#3 0xb41ca463 in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_copy (this=0xbf6f7340, __x=0xb85a4b0, __p=0x332439d8)
at /usr/include/c++/4.1.2/ext/new_allocator.h:88
#4 0xb41ca4a4 in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_copy (this=0xbf6f7340, __x=0xb859658, __p=0x332439c0)
at /usr/include/c++/4.1.2/bits/stl_tree.h:1232
#5 0xb41ca4a4 in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_copy (this=0xbf6f7340, __x=0xb859190, __p=0x332439a8)
at /usr/include/c++/4.1.2/bits/stl_tree.h:1232
#6 0xb41ca4a4 in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_copy (this=0xbf6f7340, __x=0xb858c98, __p=0x33243990)
at /usr/include/c++/4.1.2/bits/stl_tree.h:1232
#7 0xb41ca4a4 in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_copy (this=0xbf6f7340, __x=0xb8583e0, __p=0x33243978)
at /usr/include/c++/4.1.2/bits/stl_tree.h:1232
#8 0xb41ca4a4 in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_copy (this=0xbf6f7340, __x=0xb857108, __p=0x33243960)
at /usr/include/c++/4.1.2/bits/stl_tree.h:1232
#9 0xb41ca4a4 in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_copy (this=0xbf6f7340, __x=0xb855f50, __p=0x33243948)
---Type <return> to continue, or q <return> to quit---
at /usr/include/c++/4.1.2/bits/stl_tree.h:1232
#10 0xb41ca4a4 in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_copy (this=0xbf6f7340, __x=0xb853088, __p=0x33243930)
at /usr/include/c++/4.1.2/bits/stl_tree.h:1232
#11 0xb41ca4a4 in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_copy (this=0xbf6f7340, __x=0xb8501f0, __p=0x33243918)
at /usr/include/c++/4.1.2/bits/stl_tree.h:1232
#12 0xb41ca4a4 in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_copy (this=0xbf6f7340, __x=0xb84af10, __p=0x33243900)
at /usr/include/c++/4.1.2/bits/stl_tree.h:1232
#13 0xb41ca4a4 in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_copy (this=0xbf6f7340, __x=0xb83de90, __p=0x332438e8)
at /usr/include/c++/4.1.2/bits/stl_tree.h:1232
#14 0xb41ca4a4 in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_copy (this=0xbf6f7340, __x=0xb831380, __p=0xbf6f7344)
at /usr/include/c++/4.1.2/bits/stl_tree.h:1232
#15 0xb41ebeab in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::operator= (this=0xbf6f7340, __x=@0xb2a28710)
at /usr/include/c++/4.1.2/bits/stl_tree.h:800
#16 0xb4208362 in TokensTree::RemoveToken (this=0x88d78d0, oldToken=0xb2a2868c)
at /usr/include/c++/4.1.2/bits/stl_set.h:220
#17 0xb4208acf in TokensTree::RemoveToken (this=0x88d78d0, idx=1)
at parser/token.cpp:570
---Type <return> to continue, or q <return> to quit---
#18 0xb4208382 in TokensTree::RemoveToken (this=0x88d78d0, oldToken=0xb2a2868c)
at parser/token.cpp:618
#19 0xb4208acf in TokensTree::RemoveToken (this=0x88d78d0, idx=1)
at parser/token.cpp:570
#20 0xb4208382 in TokensTree::RemoveToken (this=0x88d78d0, oldToken=0xb2a2868c)
at parser/token.cpp:618
#21 0xb4208acf in TokensTree::RemoveToken (this=0x88d78d0, idx=1)
at parser/token.cpp:570
#22 0xb4208382 in TokensTree::RemoveToken (this=0x88d78d0, oldToken=0xb2a2868c)
at parser/token.cpp:618
#23 0xb4208acf in TokensTree::RemoveToken (this=0x88d78d0, idx=1)
at parser/token.cpp:570
#24 0xb4208382 in TokensTree::RemoveToken (this=0x88d78d0, oldToken=0xb2a2868c)
at parser/token.cpp:618
#25 0xb4208acf in TokensTree::RemoveToken (this=0x88d78d0, idx=1)
at parser/token.cpp:570
#26 0xb4208382 in TokensTree::RemoveToken (this=0x88d78d0, oldToken=0xb2a2868c)
at parser/token.cpp:618
#27 0xb4208acf in TokensTree::RemoveToken (this=0x88d78d0, idx=1)
at parser/token.cpp:570
#28 0xb4208382 in TokensTree::RemoveToken (this=0x88d78d0, oldToken=0xb2a2868c)
at parser/token.cpp:618
#29 0xb4208acf in TokensTree::RemoveToken (this=0x88d78d0, idx=1
--- End quote ---
)

The rest of the bactrace seems to repeat those TokensTree::RemoveToken lines. I can let you have them all if you like - but I got up to over 1,300 of them before finally giving up!

Hope that helps.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version