Author Topic: Settings don't get saved (svn 4454)  (Read 47675 times)

Offline johne53

  • Regular
  • ***
  • Posts: 253
Re: Settings don't get saved (svn 4454)
« Reply #45 on: September 26, 2007, 02:51:11 pm »
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

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?

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7582
    • My Best Post
Re: Settings don't get saved (svn 4454)
« Reply #46 on: September 26, 2007, 05:03:29 pm »
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.

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
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline johne53

  • Regular
  • ***
  • Posts: 253
Re: Settings don't get saved (svn 4454)
« Reply #47 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.

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7582
    • My Best Post
Re: Settings don't get saved (svn 4454)
« Reply #48 on: September 26, 2007, 06:14:45 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.

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

Tim S
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline johne53

  • Regular
  • ***
  • Posts: 253
Re: Settings don't get saved (svn 4454)
« Reply #49 on: September 27, 2007, 06:12:51 pm »
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

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
)

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.

Offline johne53

  • Regular
  • ***
  • Posts: 253
Re: Settings don't get saved (svn 4454)
« Reply #50 on: September 27, 2007, 08:40:26 pm »
Mandrav - if there isn't anything obvious in the above backtrace, don't waste too much time on it. Since posting the above info I've come to the conclusion that there's some kind of capacity problem here (at least as far as the 'failure to save' problem is concerned).

I have a particular workspace containing 20 projects, each with a Debug and Release target. 19 of the projects build Shared Object files and the last one is a GUI application. With all 20 projects present in the workspace I get the saving crash (i.e. segmentation fault) every time C::B closes (assuming I've changed a setting). If I remove some of the projects, the problem goes away. It doesn't seem to matter which projects I remove. There are 3 particular projects which I can remove and the problem reliably goes away. If I only remove 1 of them (or any combination of 2) the problem doesn't go away. But if I put those 3 projects into a smaller workspace, they don't cause any problems. Conversely, if I put them back into the original workspace, I can remove other projects and the problem still goes away.

I'm very busy over the next few days but if I get a chance next week, I'll see if I can either:-

a) find out if there's anything common to (or unusual about) those 3 projects - or
b) find out if I can home in on something more repeatable.

Thanks for your help, so far. I'm still keen to find out if that message (Failed to read a valid object file image from memory) is a bad indication. Assuming it's not normal, is there any way to find out which image couldn't be read?

Offline johne53

  • Regular
  • ***
  • Posts: 253
Re: Settings don't get saved (svn 4454)
« Reply #51 on: September 29, 2007, 04:55:41 pm »
Woohoo...! I've tracked down at least one of the situations that's been causing this strange crashing problem. I think there might be other situations too - but maybe it's best to deal with one problem at a time. Consider this C::B project (my actual project is much bigger but I can still reproduce the problem, even from this cut-down version).

To see the crash, the following steps are necessary:-

1) Add this project to a workspace (unfortunately, it doesn't crash with every workspace - but it does with the majority of them)
2) Launch a terminal window and type gdb codeblocks - followed by run
3) After C::B starts, open the workspace to which you added the project below
4) Change one or more of the global settings (for example, one of the Compiler & Debugger settings)
5) Exit Code::Blocks. At this point you get a segmentation fault and your new change(s) are lost.

Quote
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<CodeBlocks_project_file>
   <FileVersion major="1" minor="6" />
   <Project>
      <Option title="Ardour" />
      <Option pch_mode="2" />
      <Option compiler="gcc" />
      <Build>
         <Target title="Debug">
            <Option output="$(#output)/ardour2/ardour-2.0.5" prefix_auto="1" extension_auto="1" />
            <Option object_output="obj/Debug/" />
            <Option type="0" />
            <Option compiler="gcc" />
            <Option host_application="ardour-2" />
            <Compiler>
               <Add option="-DDEBUG" />
            </Compiler>
            <Linker>
               <Add directory="$(#output)/ardour2/" />
               <Add directory="$(#base)/ardour2/libs/pbd/" />
            </Linker>
         </Target>
         <Target title="Release">
            <Option output="bin/Release/ardour-2.0.5" prefix_auto="1" extension_auto="1" />
            <Option object_output="obj/Release/" />
            <Option type="1" />
            <Option compiler="gcc" />
            <Compiler>
               <Add option="-O3" />
            </Compiler>
            <Linker>
               <Add directory="$(#output)/ardour2/" />
               <Add directory="$(#base)/ardour2/libs/pbd/" />
            </Linker>
         </Target>
      </Build>
      <Compiler>
         <Add option="-Wall" />
      </Compiler>
      <Linker>
         <Add library="jack" />
      </Linker>
      <Unit filename="waveview.cc" />
      <Unit filename="waveview.h" />
      <Unit filename="waveview_p.h" />
      <Extensions>
         <code_completion />
         <debugger />
      </Extensions>
   </Project>
</CodeBlocks_project_file>

Pay particular attention to the red lines. If they'd been written like this:-

<Option output="$(#output)/ardour2/ardour-2.0.5" prefix_auto="0" extension_auto="0" />
<Option output="bin/Release/ardour-2.0.5" prefix_auto="0" extension_auto="0" />

(in other words, auto prefix and extension disabled, instead of enabled) the crash doesn't occur. Similarly, if the output target filename doesn't include fullstops, the crash doesn't occur either. I hope this will go some way towards identifying the problem.

Offline johne53

  • Regular
  • ***
  • Posts: 253
Re: Settings don't get saved (svn 4454)
« Reply #52 on: September 30, 2007, 12:26:21 pm »
Another thing that seems to be causing problems for Code::Blocks is the use of quotation marks within a #define. For example, many of my projects require that the compiler (g++) is sent a compile option taking a form similar to this:-

-DLOCALEDIR=\"/usr/local/share/locale\"

After asking on this forum I was told to implement this within C::B as a preprocessor directive (#define build option) of the form:-

LOCALEDIR=\\"/usr/local/share/locale\\"

Within the relevant project (.cbp file) this translates to an XML string entry of the form:-

<Add option='-DLOCALEDIR=\\&quot;/usr/local/share/locale\\&quot;' />

which is listed among the relevant target's Compiler options. As far as I can tell, C::B seems to tolerate a small number of these - but once I include a dozen or more I start seeing the same segmentation faults each time I try to shut down C::B.

I guess it could be the case (in fact, I hope it is the case) that I've been wrongly advised and I should be using some other syntax. However, the syntax shown above does cause the correct option to get sent to the compiler, so it seems to have some validity. In any case, I can't see why a particular text string - even if it was illegal - should cause the host program to crash.

Offline johne53

  • Regular
  • ***
  • Posts: 253
Re: Settings don't get saved (svn 4454)
« Reply #53 on: October 04, 2007, 06:38:55 am »
Has anyone managed to reproduce these problems?

Or can someone comment on why these particular settings (with seemingly correct syntax) should be causing C::B to segfault?

Offline johne53

  • Regular
  • ***
  • Posts: 253
Re: Settings don't get saved (svn 4454)
« Reply #54 on: October 14, 2007, 03:34:01 pm »
I didn't managed to fix these problems so I decided to try out Linux and C::B on a completely different PC. I've chosen a different distro (64Studio, which is a Debian based Linux) and installed it on my laptop. Using SubVersion I checked out SVN 4454 of CodreBlocks (the one where I originally discovered the problems) and soon I'll be trying to build it.

I have a vague memory of needing to install a library/package called contrib but I can't quite remember where I got it from. Can anyone remind me if it comes as part of a standard SVN checkout or is there somewhere else that I need to get it from?
« Last Edit: October 14, 2007, 03:37:48 pm by johne53 »

Offline johne53

  • Regular
  • ***
  • Posts: 253
Re: Settings don't get saved (svn 4454)
« Reply #55 on: October 15, 2007, 08:12:02 pm »
Looking back through my notes, it seems that wxGTK was the other lib that I needed to install. In fact, wxGTK, wxGTK-dev and  wxGTK-dbg are already installed on my system (version 2.6.3.2.1.5). I'm trying to use the following command set to build C::B (after first opening a terminal window and navigating to my C::B root folder)...

Quote from: Biplab
./bootstrap
./configure
make
su
make install

Immediately after the ./bootstrap command I get this error:-

Quote
You should add the contents of '/usr/share/aclocal/libtool.m4' to 'aclocal.m4'
./bootstrap: line64: aclocal: command not found

Does anyone know what this means? aclocal.m4 and libtool.m4 seem to be reasonably identical on both machines, AFAICT

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Settings don't get saved (svn 4454)
« Reply #56 on: October 15, 2007, 08:28:03 pm »
the bootstrap-script starts with this lines:
Code
# Check for proper versions of autotools
# We require:
#  - autoconf 2.50+
#  - automake 1.7+, 1.9+ for make dist
#  - libtool 1.4+
you can type
Code
aclocal --version
autoconf --version
automake --version
libtool --version

and see which versions are installed, or which program is missing.

codeblocks is developped against wxWidgets 2.8.4, but I don't know where you can find it for for Suse.

Offline johne53

  • Regular
  • ***
  • Posts: 253
Re: Settings don't get saved (svn 4454)
« Reply #57 on: October 15, 2007, 08:55:09 pm »
Thanks Jens, I'll try those things tomorrow. Incidentally, my laptop is running a distro called 64Studio (it's my desktop machine that runs Suse). 64Studio is supposedly a customised version of Debian Etch, if that helps.

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Settings don't get saved (svn 4454)
« Reply #58 on: October 15, 2007, 09:01:54 pm »
wxWidgets 2.8.4 for debian etch can be downloaded here:
Code
http://apt.tt-solutions.com/debian/ etch main
key-import to apt's trusted keys:
Code
wget -q http://www.tt-solutions.com/vz/key.asc -O-  | sudo apt-key add -
« Last Edit: October 15, 2007, 09:09:06 pm by jens »

Offline johne53

  • Regular
  • ***
  • Posts: 253
Re: Settings don't get saved (svn 4454)
« Reply #59 on: October 16, 2007, 07:41:03 am »
Thanks Jens. It turned out that only libtool was installed, not the others. Synaptic told me that the latest version of automake was 1.10. I couldn't figure out if that was earlier or later than 1.9, so I loaded 1.9. I now have the following installed:-

autoconf = version 2.61
aclocal = version 1.9.6
automake = version 1.9.6
libtool = version 1.5.22-4

and it seems to be building.... let's hope it solves my problems...!


[Edit...] No, it doesn't seem to be going very well. The make starts to falter when it needs wxWidgets (presumably because I've only installed v2.6). I didn't really understand your instruction ( wget -q http://www.tt-solutions.com/vz/key.asc -O-  | sudo apt-key add - ) but I assumed that by typing that line, it would set up that URL to be the download path for wxWidgets. I typed it in (and got the response 'OK') but Synaptic still tells me that 2.6.3 is the latest version.

I then logged in as root and tried typing 'apt-get install wxWidgets' which produces "Couldn't find package wxWidgets". 'apt-get install wxGTK' produces "Couldn't find package wxGTK". Any idea what I'm doing wrong?
« Last Edit: October 16, 2007, 08:17:57 am by johne53 »