FreeOrion

вы там не обалдели часом? вообще-то, насколько я знаю, считается неприличным общаться на языке незнакомом собеседнику в его присутствии

fleets:
after flying to a other system dragging funcs, menu still crashes.

You're going to have to write out what you mean more clearly... Exactly what did you do, what was the initial situation, what is different, etc. Was this in response to my previous post about being disconnected from the server?

i mean, that i started the game again over the quickstart menu the thing that i changed was that i moved a fleet to another star system and made a turn end.
after that i tried to split - and splitting the forces with drag and drop was functionizing. but over the pulldownmenu it still didn't work.
but when you start a normal sp game it is the same.

That's much clearer, thanks. Could you post the last 10 lines of freeorion.log and freeoriond.log after trying to use the FleetWnd right-click popup to split a fleet?

i've found the error...
after changing in FleetWnd::FleetRightClicked

if (popup.Run()) {
switch (popup.MenuID()) {
case 1: { // rename fleet
std::string fleet_name = fleet->Name();

to
if (popup.Run()) {
switch (popup.MenuID()) {
case 1: { // rename fleet
std::string fleet_name = "test";//fleet->Name();

the error dissappears and i can split fleets over drag&drop and menu.... but still splitting the home fleet does not functionizing over the menu.

Does that mean that the popup split fleet command works for all fleets except the home fleet? Does it crash or do nothing for the home fleet?

I have no idea why changing what the rename menu command is doing would affect how the separate split fleet command functions...

after debugging today seems it that i have problems with the c++ stdlib. i have suse linux 11.1.
every time a map, vector, or list comes the debugger crashes. although the renaming above mentioned by me nothing has to do with splitting ships, there are less crashes as mentioned, but if every codepart is affected where the c++ stdlib comes, the whole freeorion is not stable because of the lib.

i'll get the newest version tomorrow, goodnight everyone.

I'VE GOT IT!

change in func: FleetWnd::FleetRightClicked(GG::ListBox::iterator it, const GG::Pt& pt)

to

for (it = ship_ids_set.begin(); it != ship_ids_set.end(); it++) {
std::vector<int> ship_ids_vec;
ship_ids_vec.reserve(30);
ship_ids_vec.push_back(*it);
CreateNewFleetFromShips(ship_ids_vec);


this means you must reserve some space for the vector prior assinging data to it.
and freeorion wont crash anymore.
so says my smart c++ stdlib book

As far as I know, that shouldn't be required, so I suspect you've still got a buggy stdlib.

What happens if you construct the vector directly with one value in it?

(And then don't push anything more into it...)

as it worked often for the vector with the 2 ships of the battle fleet, it worked never for the home fleet, because the memory corrupted was too large. this is exact that what happens when a memory leak occours.

i'll tell you what my c++ stdlib book says to this:

"capacity() returns the number of elements which can used by the vector, without allocating new space. this value is important for the speed, because when new memory is needed (reallocation), all pointers to the elements become invalid. this means concretly, that all iterators and references become invalid."

as i have seen that this error is at many more points, it is a very serious bug causing the whole game to crash very often.

That's not relevant to what's happening in this particular bit of code. There are no iterators or references to integers in the the vector stored when the single integer is pushed into the vector...

The vector is local in scope to each iteratation of the loop, and there is no vector iterator or pointer to int in that code. If there was an vector iterator created before the push_back call, it would be invalidated, but there isn't.


You're the only person who's had any issues of this sort, so I'm still inclined to believe its a problem with your C++ standard library.

Also, could you check what happens with the alternative code I suggested in my previous post?

both battlefield and homefield splitting crashes cause the size is 1

try this:

#include <iostream>
#include <stdexcept>
#include <string>
#include <map>
#include <vector>

using namespace std;

int main() {
vector<int> v;
cout << "v max elements without allocating new space: " << v.capacity();
cout << "v actual elements in vector: " << v.size();
v.push_back(1);//should crash anywhere here
v.push_back(2);
v.push_back(3);
v.push_back(4);
v.push_back(5);
v.push_back(6);
v.push_back(7);
v.push_back(8);
int i2 = v[5]; //no arraytest
int i23 = v.front(); //no arraytest
int i34 = v.back(); //no arraytest



vector<int> v2;
v2.reserve(500);
cout << "v2 max elements without allocating new space: " << v2.capacity();
cout << "v2 actual elements in vector: " << v2.size();
v2.push_back(1);//crashes no more
v2.push_back(2);
v2.push_back(3);
v2.push_back(4);
v2.push_back(5);
v2.push_back(6);
v2.push_back(7);
v2.push_back(8);
int i22 = v[5]; //no arraytest
int i233 = v.front(); //no arraytest
int i344 = v.back(); //no arraytest
int i455 = v.at(3);




try {
for(int i=0;i<10;i++){
vector<int> v3(3, 5); //creates a vector with 1 element with the copy of 5
cout << "v3 element: " << i << "is: " << v3.at(i);
}
}catch(const exception& e){
cout << e.what() << endl;
}
return 0;
}


this should give the same results to you, too.

This does not crash, and is not supposed to. See here which says, in part "[vector::push_back] effectively increases the vector size by one, which causes a reallocation of the internal allocated storage if the vector size was equal to the vector capacity before the call."

Accessing contents of a vector outside the valid range, particularly without range checking, could cause crashes, but pushing more data into a vector should not cause a crash no matter what the reseved capacity is. If more capacity is needed to push an item into a vector, the internal storage of the vector is automatically reallocated (thus invalidating the iterators, as noted above).

If somewhere in the freeorion code, such as in the CreateNewFleetFromShips function, the contents of a vector are being accessed outside its valid range, then that's a problem, but all you've pointed out so far is the push_back calls, which are used properly and should not cause any crashes themselves.

ok then you are right ... good that the error was found.