User forums > Help

Settings don't get saved (svn 4454)

<< < (9/16) > >>

mandrav:
@johne53: why don't you try running C::B from within gdb and post a backtrace here when it crashes?

johne53:
Hi Mandrav - it's not crashing as such. It's just not working the way it used to. For example, when I press F8 to debug a project, it no longer stops if I set break points. Or to be more specific - sometime it runs the program without stopping at the break points; other times it runs the program normally (and stops at the break points); other times it doesn't even run the program. The important thing is that I'm not changing anything while this is going on. One minute it will work - the next it won't (but mostly, it won't).

It's the same with saving my Compiler & Debugger settings. If I change a setting, the change (usually) doesn't get saved. But occasionally it does. There's no logic to it at all.

To be honest, C::B isn't really useable in its current state. The frustrating thing is that I don't know how it got into this state and nothing - not even re-installing - seems to fix it....  :(

mandrav:

--- Quote ---Hi Mandrav - it's not crashing as such. It's just not working the way it used to. For example, when I press F8 to debug a project, it no longer stops if I set break points. Or to be more specific - sometime it runs the program without stopping at the break points; other times it runs the program normally (and stops at the break points); other times it doesn't even run the program. The important thing is that I'm not changing anything while this is going on. One minute it will work - the next it won't (but mostly, it won't).

--- End quote ---

So why don't you post the debugger's log here?
And while you 're at it, enable the debugger's debug log in debugger settings and post that too.

The only relevant thing I have noticed is that, when loading a project, if the active target is the debug target (and depending what I was previously doing with C::B), some times it might not pick this up and try to debug the release target (which of course will behave like you describe). In that case I switched to the release target and then back to the debug one and it worked fine from then on.
I admit I haven't been able to reproduce this in a constant manner and so it's a bit difficult to track. But this will be fixed eventually.
Still, if this is really the problem you have, then just momentarily switch to another target and then back to debug and the problem will go away.


--- Quote ---It's the same with saving my Compiler & Debugger settings. If I change a setting, the change (usually) doesn't get saved. But occasionally it does. There's no logic to it at all.

--- End quote ---

As said before, the only reason your settings are not saved is if C::B crashes on exit. You can only verify this by running C::B from a console or, even better, from inside gdb so you can post the backtrace I asked.


--- Quote ---To be honest, C::B isn't really useable in its current state.
--- End quote ---

Please refrain from using such bold statements.
I can see that this might have been your experience but, as you probably saw from the replies in this topic, this is not what any of us experiences. So either help us to help you by providing the info we ask for, or patiently wait until C::B works for you as you expect it to.
Really, nothing more to say.

johne53:
Maybe I should have said that in it's current state, it isn't useable by me. I wasn't speaking generally, or for anyone else.

Something interesting happened after I toggled to Release and then back to Debug. I'd started C::B from a terminal and got this output


--- Quote ---johne53@AMD2000:~> codeblocks
-------------- Build: Debug in Ardour ---------------
Target is up to date.
Nothing to be done.
--- End quote ---

which I assume is normal. However, at the same time, the "Layout changed" dialog appeared, telling me that the Code::Blocks default layout had changed and asking if I wanted to save it. At first I hit 'No'. I then saw that it had launched a new terminal window, instead of the app's GUI. I selected Debug->Stop debugger and tried again. The "Layout changed" dialog appeared again but this time I selected 'Cancel'. This time, I saw a new dialog saying "Error - unable to stop the debug process". When I hit "OK", my app loaded normally (in the debugger) and my break point got reached. I then stopped the debugger and closed C::B. In the terminal window I then saw a message "segmentation fault". This seems to be the same with any project but unfortunately, I'm not getting the codeblocks.rpt file that you mentioned. I've searched my main partition and my home partition but it's not there.

I've also found (although I'm not yet sure how consistent this will be) that the problem of my IDE settings not getting saved seems to happen only with one particular workspace loaded. Again, I see "segmentation fault" in the terminal window but I'm not getting that codeblocks.rpt file. Is there something I need to do to enable it?

mandrav:
codeblocks.rpt is generated only in windows.

Run "gdb codeblocks".
Inside gdb, type "run".
Do what you want in C::B.
If it crashes on exit, go back to the terminal with gdb running.
Type "bt".
Copy and paste the backtrace here.

Navigation

[0] Message Index

[#] Next page

[*] Previous page