Author Topic: The 20 July 2006 build is out.  (Read 25340 times)

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2750
Re: The 20 July 2006 build is out.
« Reply #15 on: July 21, 2006, 04:35:43 pm »
I too get the error.

When I remove default.workspace from application\data, the problem goes away. I restart codeblocks, answer Yes to the request to save the workspace and the problem goes away.

The solution seems thus to delete this file.
Hi,

I'm getting the "quit error" as well, since the 18th release; it has not been fixed for my system with this one (20th). I have no keybinding active - at this time.

Jo

Ummm, there seems to be more then a keybinder problem here.

KeyBinder has no relationship to either *.workspace or *.conf. It neither reads nor writes to them.

KeyBinder only reads/writes to cbKeybinder*.ini. Deleting *.workspace or *.conf would have no effect what-so-ever on KeyBinder.

For the future, if these problems re-appear, please disable keybinder in the "Plugins->Manage Plugins" Menu item, then see if the crash disappears/remains.

In the case where there are no keybindings, keybinder never sees the quit key.  The quit menu item is completely handled by the wxidgets menu system. This particular crash discription appears to be something different.

<snip>
EDIT: I believe the problem can be partly reproduced in the July, 18 NL by:

delete default.workspace -> start codeblocks -> yes to save workspace -> Open a project -> quit -> (You will get a beep and nothing happens) -> quit again.

I am unable to reproduce the above with the SVN equivalent of the 20th July nightly build.

Keep talking people, the light will eventually come on...

thanks
pecan


« Last Edit: July 21, 2006, 04:57:56 pm by Pecan »

marfig

  • Guest
Re: The 20 July 2006 build is out.
« Reply #16 on: July 21, 2006, 05:51:06 pm »
I don't believe this has anything to do with the keybinder. I was getting a crash when using Quit from the file menu too.

Also, I cannot reproduce this on the July, 20 NL. Only on the 18th. Or with the 20th version IF I'm using a default.workspace created with a 18th NL.
« Last Edit: July 21, 2006, 05:52:42 pm by marfig »

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
Re: The 20 July 2006 build is out.
« Reply #17 on: July 21, 2006, 05:55:45 pm »
can you post in here the content of that default workspace ???

marfig

  • Guest
Re: The 20 July 2006 build is out.
« Reply #18 on: July 21, 2006, 05:58:55 pm »
Ok... give me a few. going to downgrade and reproduce the error.

marfig

  • Guest
Re: The 20 July 2006 build is out.
« Reply #19 on: July 21, 2006, 06:32:33 pm »
Let's see...

I start fresh by deleting default.workspace and downgrading to July, 17th NL.

I start codeblocks and answer Yes to the request to save the workspace. I quit without problems. The file is now:
Code
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<CodeBlocks_workspace_file>
<Workspace title="" />
</CodeBlocks_workspace_file>

I restart codeblocks, open a project and quit. I answer Yes to the request to save the workspace and quit without problems. The file is now:
Code
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<CodeBlocks_workspace_file>
<Workspace title="Default workspace">
<Project filename="..\..\..\..\c++\middleages\middle.cbp" active="1" />
</Workspace>
</CodeBlocks_workspace_file>

I upgrade to the 18th. Everything goes well. It doesn't crash on quit. I make no changes to the workspace.

I upgrade to the 20th (I never used the 19th. Was away). Everything goes well. I open another project and try to quit from the file menu. And It crashes.

At this point of the crasj, my default.workspace is:
Code
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<CodeBlocks_workspace_file>
<Workspace title="Default workspace">
<Project filename="..\..\..\..\c++\middleages\middle.cbp" />
<Project filename="..\..\..\..\MT\mt.cbp" active="1" />
</Workspace>
</CodeBlocks_workspace_file>

Any subsequent restart of codeblocks and quit, crashes.

marfig

  • Guest
Re: The 20 July 2006 build is out.
« Reply #20 on: July 21, 2006, 07:09:42 pm »
As an update to the previous post, if then I proceed to delete default.workspace all will be well. A new one is created when I restart codeblocks and I apparently can quit normally after opening one of my projects.

But if again I open another project, the problem resurfaces.

Apparently this is something to do with having more than one <Project filename= ... > under <Workspace title="Default workspace">

All quits were done under the file menu.

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
Re: The 20 July 2006 build is out.
« Reply #21 on: July 21, 2006, 07:36:36 pm »
good news and bad news :

Good : I can reproduce

Bad : will look into it earliest tomorrow ;-)

I never came across since I always startup with a blank workspace.

[EDIT] : though I don't have the crash all the time

The fact that 2 or more projects might be in there could be a requirement for having the crash. If you can please experiment a bit more (and with older versions) and post your feedback. Many thanks.
« Last Edit: July 21, 2006, 07:45:55 pm by killerbot »

marfig

  • Guest
Re: The 20 July 2006 build is out.
« Reply #22 on: July 21, 2006, 09:37:46 pm »
Ok... some experimenting follows :)
I started fresh from all NLs (default.workspace was deleted before firing up for the first time)

NL 17, July.
Doesn't crash. However, it misbehaves.

Fire up -> open project -> quit -> fire up -> open second project -> quit -> (There is a beep and doesn't quit) -> Quit again.

It then leaves the program, but if you go and check your default.workspace, it wasn't updated with the second project as it should. Consequently, any subsequent runs of codeblocks don't crash.

NL 18, July
Doesn't crash. Exactly the same as the 17th. With this little eccentricity: It doesn't beep this time  :lol:

NL 19, July
Doesn't crash. This one is more insidious. It gives no warning. Closes normally after opening 2nd project. An attentive user will wonder why it didn't ask him to save the workspace. But that's about it. default.workspace was not updated.

NL 20, July
You already know what happens here.
It's the one I like most... because this time it crashes. Between not knowing and knowing... I choose the red pill ;)

Have fun with this one.

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
Re: The 20 July 2006 build is out.
« Reply #23 on: July 25, 2006, 08:59:03 pm »
Unfortunately I was no longer able to reconstruct the crash. But while taking a good look at the code I found several issues and hopefully fixed them. Could you try again with the build of the 25th ??

marfig

  • Guest
Re: The 20 July 2006 build is out.
« Reply #24 on: July 26, 2006, 02:00:30 am »
Unfortunately no. Having more than one project under the default workspace crashes on quit.

My default.workspace file:

Code
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<CodeBlocks_workspace_file>
<Workspace title="Default workspace">
<Project filename="..\..\..\..\MT\mt.cbp" />
<Project filename="..\..\..\..\c++\middleages\middle.cbp" active="1" />
</Workspace>
</CodeBlocks_workspace_file>

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: The 20 July 2006 build is out.
« Reply #25 on: July 26, 2006, 07:53:08 am »
Hmmm... I still can't reproduce, too. Could you please explain your folder structure, thus give us the full path to:
- your C::B installation
- your default workspace file
- your two projects in question
Maybe this will help to enable reproducing this issue (I tried with a path like "1\2\3\4\5" but this seems to work very well).
With regards, Morten.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
Re: The 20 July 2006 build is out.
« Reply #26 on: July 26, 2006, 11:30:27 am »
or could you provide us with a zip fiole containing your projects (with as much of your code removed as possible) and see if with those dummy projects it still crashes.

Could you also try it out with a clean CB installation (nightly in new directory and remove/rename your default.conf) ??

I had the crash exactly once, but after that I was no longer able to reproduce it. Then I did some fixes and also not able to reproduce after these fixes ;-) . The fixes I have done are these :

- constructor of cbWorkspace now initializes all members, when you had no default.conf yet, the Load part of the constructor would fail because it did not find the file (duh) and several members remained uninitialized, a bit later the IsModified was checked and the modified member was by accident true this resulted in the startup of CB to ask to save the defaul.conf, while actually nothing had happened to it. Maybe some of these uninitialized behaviour could have caused the crashes. Due to the failure of the loading (NotOk) the project manager had no valid pointer value for m_pWorkSpace

- continueing on the previous issue, when a project was then loaded, nothing happened to the workspace because of the no valid m_pWorkSpace pointer, and at shutdown of CB the same thing happened, nothing got saved in the default.workspace since the m_pWorkSpace  was 0.

- the workspace loaders :
  + one of them had a member for a version number which was totaly unused ->removed
  + they contained a title member which they only used at Open and could be "Get" but at save one had to specify the title as an argument --> title member has been removed as a member and is now an I/O argument to the Open method where the only client of those workspaceloeaders (cbWorkspace) will deal with it, cbWorkspace not itselves start's with it's title being "Default Workspace". So things are a bi more consistent.
   [SideNote : during debugging those workspace loaders would return intheir GetTitle method either their m_Title or in the case it was empty "Default workspace", but I saw oit ending up injust the first character 'D", and it was the first character because in once changed the code to "Xefault workspace" ;-) and then I had an X . cbWorkspace could also have an empty title when there was no workspace loader, but there's should always be a workspace loader, now also i nthis case the title will be the default ]

- the client of the workspace : the project manager and the app (main.cpp app.cpp projectmanager.cpp) : very little change in the project manager instead of having 3 times the same code, 2 of them fall back on the third method. And on the app level no need to specify the default argument, a call without specified arguments is sufficient (also here it was inconsistent : once called without specifying it once with)

Another thing I also want to change (did no do it yet) is moving the DEFAULT_CONF (== default.workspace) from globals.h to cbWorkSpace. it is used in the cbWorkSpace (obviously) and as default argument to LoadWorkSpace method of the projectmanager. It even can be exported i think in the dll. My view : it does not belong in the globals.h, it should be a public static member of cbWorkSpace --> cbWorkSpace::DefaultConf.

That's about it for my changes.
« Last Edit: July 26, 2006, 11:32:15 am by killerbot »

marfig

  • Guest
Re: The 20 July 2006 build is out.
« Reply #27 on: July 26, 2006, 01:55:32 pm »
Well, I did as you suggested and did a clean install on another folder, having previously removed default.workspace and default.conf. It works like a charm. I can no longer reproduce the error.  :)

I don't have much free time right now. But if after this, if you would still prefer a more detailed testing and some cut down version of my projects, let me know and I will provide them tonight (I'm at GMT).

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
Re: The 20 July 2006 build is out.
« Reply #28 on: July 26, 2006, 02:11:08 pm »
well good to hear now everything works. I suspect your default.conf to maybe be the guilty party.
When you have time and you feel to further investigate you are always welcome to do so. Now we don't know yet what the "real" cause is. It is always better to know ;-)
But if you don't feel like it, well no problem, major point is thing is solved also know on your system :-)