Code::Blocks Forums
User forums => Help => Topic started by: l_inc on October 29, 2015, 06:58:07 am
-
Good day. I have the following problem. If there are many files open in a project and with some planets incorrectly aligned C::B corrupts the layout file while just opening and closing the project. This includes for instance modification of some values position and topLine for the cursor. I attached a sample project, where opening and closing the project in C::B four times leads to splitting the view, which is then impossible to get rid of.
I'm getting this with CodeBlocks 13.12.svn.10538 on Fedora 22.
-
svn build rev 10538 (2015-10-18 12:10:34) gcc 4.9.2 Windows/unicode - 32 bit
I too have experienced this problem: the screen splits when loading an additional project into the workspace.
Deleting the "<EditorTabsLayout layout=" entry in the layout file solved the problem.
-
Pecan
the screen splits when loading an additional project into the workspace
The problem I reported is not related to loading additional projects. It's just enough to start and close the same project multiple times and the layout will gradually get corrupted eventually leading to the split view without any other projects involved.
Deleting the "<EditorTabsLayout layout=" entry in the layout file solved the problem.
It solves the problem of splitting for the next few loads of the project, and then the split will reappear. And it does not solve the problem of corrupting the other (even if those are minor) parameters of the layout.
-
Today, I got this twice, never had it before (nearly latest trunk build)
-
Well that is interesting: Indeed, also on Windows if you open the provided project 3 times it starts splitting the editors... everytime after that another split gets introduced...
Well that is weird...
Lets see what the latest changes to the layout mechanism were...
-
One update: It seems related to the fact that the project file includes references to source files that are not present. Could you (guys) please verify if this also happens in case all files are really present? (You can use the "find broken files" plugin to clean-up the project).
-
Probably this is related to the changes done by Jens to support preserving the splits in the layout.
-
No broken files were found by "find broken files" on either of the two projects in the workspace.
-
My implementation below overcomes (not fixes) this problem when enabled. It might help till the problem is fixed.
http://sourceforge.net/p/codeblocks/tickets/182/ (http://sourceforge.net/p/codeblocks/tickets/182/)
-
MortenMacFly
One update: It seems related to the fact that the project file includes references to source files that are not present.
Yes, that seems correct. No layout attributes get modified when there are no missing project files.
-
Probably this is related to the changes done by Jens to support preserving the splits in the layout.
If the EditorTabsLayout-part is broken, this might be.
But this should not not chage cursor-position or top-line.
I try to investigate, but I'm very busy at the moment.
I only get it, if some source files are not present.
I mean the "autromatically" split (and break layout) when closing and reopening the project.
The fact that the tabs of two (or more) projects might get incorrectly merged or (at least in an unecpected way) is another thing.
-
Probably this is related to the changes done by Jens to support preserving the splits in the layout.
The issue with the example project of the OP should be fixed in trunk.
It was indeed, because of missing source-files, with fileOpen-attribute-set in the layout file.
After some closing and opening, it ended with several fioles with the same tab-position.
And this seems to lead to a corruption in cbauibook::LoadPerspective().
I also changed the SavePerspective()-code in a way, that a project layout-file only saves the tab-layout of files belonging to the project, and that the tab-layout of files not belonging to any project is no longer saved.
Workspace-layout files should save the tab-layout of all files belonging to any project.
-
jens
Thank you. The layout attributes are not continuously changed anymore. But I'd like to note that these still are modified as long as EditorTabsLayout contains those missing files. It's currently not usability critical, because the missing files are thrown out of EditorTabsLayout once the project is opened, and the layout attributes (such as tabpos, position and topLine) get then stable values, but the new values are read from some unexpected memory locations. So the bug is worked around, but still seems to persist and could get in the way later, e.g. as a crash resulting from a read from unallocated memory.
-
jens
Thank you. The layout attributes are not continuously changed anymore. But I'd like to note that these still are modified as long as EditorTabsLayout contains those missing files. It's currently not usability critical, because the missing files are thrown out of EditorTabsLayout once the project is opened, and the layout attributes (such as tabpos, position and topLine) get then stable values, but the new values are read from some unexpected memory locations. So the bug is worked around, but still seems to persist and could get in the way later, e.g. as a crash resulting from a read from unallocated memory.
Can you please be more specific and write where values from unallocated memory are read ?
-
jens
I did not debug it, and reading from unallocated memory was my speculation about such possibility. The point is that the layout attributes a still changed, if the layout contains missing files for whatever reason (might be a common situation btw., e.g. when switching between multiple git branches). I have no idea where the changed values actually come from. Hence the speculation. But the bug is worked around, not fixed.
-
jens
I did not debug it, and reading from unallocated memory was my speculation about such possibility. The point is that the layout attributes a still changed, if the layout contains missing files for whatever reason (might be a common situation btw., e.g. when switching between multiple git branches). I have no idea where the changed values actually come from. Hence the speculation. But the bug is worked around, not fixed.
Steps to reproduce ?
Without speculation !
-
jens
[...]
the new values are read from some unexpected memory locations. So the bug is worked around, but still seems to persist and could get in the way later, e.g. as a crash resulting from a read from unallocated memory.
So you should be more clar in your statements.
And please tell me why you think the bug is unfixed and why you think it can result in read from unallocated memory.
And please be more specific and do not jsut guess what happens.
-
jens
Steps to reproduce ?
Same as before. Open and close the attached project from the first post. The incorrect result are changed values in the layout file. E.g. the cursor position value for the file "../aaq/138.c" is initially 1530, but after closing the project it becomes 3322. CB svn 10621.
And please be more specific and do not jsut guess what happens.
I thought, I was very specific: "The layout attributes are not continuously changed anymore. But I'd like to note that these still are modified as long as EditorTabsLayout contains those missing files". That's the bug description. And it's the same bug as it was before.
-
[...]
E.g. the cursor position value for the file "../aaq/138.c" is initially 1530, but after closing the project it becomes 3322. CB svn 10621.
[...]
It's vice versa and the size of 138.c is just 1530 bytes, so the cursor position is correct after closing the project and was wrong before.
I would not say, that it is an issue.
I don't see other cursor-position changes, but changes in the open-state (for non existing files) and changes in the top-value (only one editor can be active at the time in one frame obviously).
-
jens
It's vice versa and the size of 138.c is just 1530 bytes, so the cursor position is correct after closing the project and was wrong before.
Oh, this is embarrassing. Especially because I double checked that it wasn't vice versa. I remember to have seen more changes in the layout of other projects, but I probably won't be able to reproduce that anymore.
-
quote author=l_inc link=topic=20667.msg141690#msg141690 date=1450185898]
jens
It's vice versa and the size of 138.c is just 1530 bytes, so the cursor position is correct after closing the project and was wrong before.
Oh, this is embarrassing. Especially because I double checked that it wasn't vice versa.
[/quote]
It was late last night (at least here), but you can download your project and look at the size of the file and what the cursor-position is in the layout-file before opening the project.
I remember to have seen more changes in the layout of other projects, but I probably won't be able to reproduce that anymore.
Again nothing concrete.
I stop the discussion here, because it leads to nothing.
-
jens
It was late last night (at least here), but you can download your project and look at the size of the file and what the cursor-position is in the layout-file before opening the project.
And how do you think I checked it before? Telepathy? When I explicitly say, it's my mistake, what's your reasoning to recommend to check it again?
Again nothing concrete.
It's amazing how you manage to continuously misunderstand simple statements. Yes, I almost explicitly said that I currently had nothing concrete anymore. Thank you for rediscovering that, Sherlock.
I stop the discussion here, because it leads to nothing.
Good for you. But understanding this one post earlier would be even better.
-
Good for you. But understanding this one post earlier would be even better.
Please be gentle. Remember that most people here are no native speakers, so misunderstanding can easily happen.
We know that there is a bug and how to reproduce. If you can provide additional information to track it down, please tell.
-
If the EditorTabsLayout-part is broken, this might be.
BTW, what I noticed
- if you have two projects open with
- both having a single editor open (two editors in total),
- close C::B and inspect the layout part
- you see in one project e.g.:
|dock_size(5,0,0)=202|
...and on the other one:
|dock_size(4,0,0)=202|dock_size(5,0,0)=202|
Note the repetition of the dock_size in the second layout. If one editor of each project is open, there should not be 3 docking sizes, right?