Problems on window 7

[Cer989]

I have tried running this game with window 7 on compatibility mode windows xp service pack 3. When I start the game and generate a world I will play for about 30 seconds then the game will freeze and shutdown

[Cer989]

How could I stop this I'm running a considerbly fast computer

[smg]

I'm having the same problem. i can play games on the public servers fine though. it sounds like it is in the server side. any ideas?

[smg]

here is a line from the debug.txt file.
WARNING: Invalid block data on disk fullpath=C:\Users\shawn\Documents\minetest-0.2.20110731_0-win32\minetest-0.2.20110731_0-win32\bin/..//world/sectors2/ff9/ffd/fffe (SerializationError). what()=MapBlockObjectList::update(): Unknown MapBlockObject type

In thread d38:
z:\softat\minetest-hg\src\map.cpp:3275: ServerMap::loadBlock: Assertion '0' failed.

[celeron55]

It either is some very old data from a very old map or it's just otherwise corrupted for some reason (an unclean shutdown of the game or something like that could cause it.) The game shuts down immediately when it tries to load invalid map data, to keep the data safe.

You can probably get rid of this problem by removing the file that it tells is invalid:

C:\Users\shawn\Documents\minetest-0.2.20110731_0-win32\minetest-0.2.20110731_0-win32\bin/..//world/sectors2/ff9/ffd/fffe

That file is a 16x16x16 chunk of map data at around (-110, 50, -30).

Or if your world is totally worthless, just delete the whole world...

[Fixerol]

I can confirm that bug too, saw it on ALL releases on my windows xp sp3 (avast antivirus+comodo firewall) except of 'Weedy compiled' (needs proof). You can catch it by simply walking (aggressively to the edge of generated terrain). Also, it happens on brand new map on healthy FS and healthy HDD. Happens in a few minutes of walking or instantly.

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

WARNING: Invalid block data on disk fullpath=E:\Games\Minetest\source\minetest_new\bin/..//world/sectors2/003/ffa/0000 (SerializationError). what()=MapBlockObjectList::update(): Unknown MapBlockObject type

In thread f6c:
z:\softat\minetest-hg\src\map.cpp:3275: ServerMap::loadBlock: Assertion '0' failed.
Debug stacks:
DEBUG STACK FOR THREAD 604:
#0  main
(Leftover data: #1  ClientMap::renderMap)
(Leftover data: #2  ClientEnvironment::step)
(Leftover data: #3  Client::Receive)
(Leftover data: #4  Client::ProcessData)
(Leftover data: #5  MeshUpdateQueue::addBlock)
DEBUG STACK FOR THREAD 658:
#0  ServerThread::Thread
#1  Server::AsyncRunStep
(Leftover data: #2  Server::ProcessData)
(Leftover data: #3  Server::getClient)
(Leftover data: #4  BlockEmergeQueue::addBlock)
(Leftover data: #5  MapBlockObjectList::step: object wrap loop)
DEBUG STACK FOR THREAD 894:
#0  MeshUpdateThread::Thread
DEBUG STACK FOR THREAD f6c:
#0  EmergeThread::Thread
#1  ServerMap::loadBlock
#2  ServerMap::loadBlock
(Leftover data: #3  ServerMap::createSector: p2d=(0,-7))
(Leftover data: #4  ServerMap::loadSectorMeta)

I think it is windows related issue, also I saw some flying block in water (but it crashed then). Also, i've put in exclude list for antivirus and it won't help. Multiplayer is rock stable.

Also, this error before first one:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

WARNING: Invalid block data on disk fullpath=E:\Games\Minetest\source\minetest_new\bin/..//world/sectors2/ff5/ffc/0006 (SerializationError). what()=MapBlock::deSerialize: decompress resulted in size other than nodecount*3

In thread 928:
z:\softat\minetest-hg\src\map.cpp:3275: ServerMap::loadBlock: Assertion '0' failed.
Debug stacks:
DEBUG STACK FOR THREAD 4e4:
#0  MeshUpdateThread::Thread
DEBUG STACK FOR THREAD 88c:
#0  ServerThread::Thread
#1  Server::AsyncRunStep
(Leftover data: #2  ServerEnvironment::step)
(Leftover data: #3  RemoteClient::GetNextBlocks)
(Leftover data: #4  BlockEmergeQueue::addBlock)
(Leftover data: #5  MapBlockObjectList::step: object wrap loop)
DEBUG STACK FOR THREAD 928:
#0  EmergeThread::Thread
#1  ServerMap::loadBlock
#2  ServerMap::loadBlock
(Leftover data: #3  ServerMap::createSector: p2d=(-10,-4))
DEBUG STACK FOR THREAD 9dc:
#0  main
#1  ClientMap::renderMap
(Leftover data: #2  ClientEnvironment::step)
(Leftover data: #3  Client::Receive)
(Leftover data: #4  Client::ProcessData)
(Leftover data: #5  MeshUpdateQueue::addBlock)


[Destroyer661]

Getting the exact same error on Win7. :D

[smg]

i still have this problem. i'm using the latest build "731". it happens on a brand new map, however it takes longer to happen on a new map. i have tried compatibility settings already. also it is a new computer. perhaps it is somthing to do with read/write actions? i realy hope we figure this out the game is fun.

[Fixerol]

i still have this problem. i'm using the latest build "731". it happens on a brand new map, however it takes longer to happen on a new map. i have tried compatibility settings already. also it is a new computer. perhaps it is somthing to do with read/write actions? i realy hope we figure this out the game is fun.

Can you test this minetest-delta - http://weedy.ca/minetest/minetest-delta-0.2.20110724_0-win32.zip ?

[smg]

i am now. i should be able to say for certain by the end of the day.

[smg]

so far so good i this works.

[Fixerol]

so far so good i this works.

Please try this newest build from Weedy - http://weedy.ca/minetest/minetest-0.2.20110801-win32.zip

[kryyss]

I had the same issue with the solo mode crashing after a few minute

I've just tried the weedy just above, playing a 3 hours session of solo mode. not crashing anymore :-)

[parlock]

So I am trying to build it from source and this problem is still there. What was the fix to make the source work for this build?

[No-Half-Measures]

Id like to Point out "Invalid block data on disk" means data can't be loaded because its broken.

Now if you follow the file path it give you in the WARNING line you can delete that file and fix the crashing issue.

So Example:

WARNING: Invalid block data on disk fullpath=E:\Games\Minetest\source\minetest_new\bin/..//world/sectors2/ff5/ffc/0006 (SerializationError). what()=MapBlock::deSerialize: decompress resulted in size other than nodecount*3

In green is the directory and the file name.
The folders to follow: E:\Games\Minetest\source\minetest_new\bin/..//world/sectors2/ff5/ffc/
The file that's throwing the Error: 0006

The reason it Crashes is because its Saving the data from becoming any-more broken than it already is.
If this is the WARNING your receiving and weedy's build stops the error it can only be one of 2 things.

- New World Data
- Or he's removed the safety mech that causes the game to close down to save the data. (This is bad)

[Fixerol]

So I am trying to build it from source and this problem is still there. What was the fix to make the source work for this build?

Try this build - http://weedy.ca/minetest/minetest-0.2.20110801-win32.zip Or at least you can try to build with MSVC2010.

[No-Half-Measures]

Try this http://weedy.ca/minetest/minetest-0.2.20110801-win32.ziip You can move your world there, but you need to delete corrupted file stated in debug.txt.

I'm going to make this Clear

Stop Directing People To Weedy's Build

His build is Based on Minetest-Delta thus there could be a number of other issues or problems that will not get you help here if a unknown problem arises.

Also Weedy's build DOES NOT fix the problem you are having tgp1994.

ALSO Fixerol 4 of 6 of the posts you have made have been telling people to use Weedy's build. Just makes me Think that there's a possibility of Miscellaneous code inside the build that could possibly harm and/or access some ones system since your so keen for people to use it.

[parlock]

I wasn't looking for the build that Weedy made. I am looking for how to fix the source code, so I can run it and continue developing using the source code.

I have seen several different types of messages in playing with the source code. They all come out of the same general error about deserializing blocks from disk. It's an issue that can be seen fairly fast. Just move far enough that it would reload a block and come back. Bam! It then crashes every time for me. I am not sure if its corrupt data on the disk file or corrupted when it loads it back. In either case it does surround compressed blocks stored on disk.

This seems like a major issue to me as it fails even the same way with the official releases too. The only way I can get it to load again is to erase the entire world folder. I have tried the file that shows in the error, but that usually doesn't fix it as when I start it up again it finds another file corrupt.

[Fixerol]

If this is the WARNING your receiving and weedy's build stops the error it can only be one of 2 things.

- New World Data
- Or he's removed the safety mech that causes the game to close down to save the data. (This is bad)

As far is I know Weedy has not removed anything in that particular minetest-0.2.20110801-win32 build of m-c55 but used newer compiler and compiled few other libs himself.

[Fixerol]

I wasn't looking for the build that Weedy made. I am looking for how to fix the source code, so I can run it and continue developing using the source code.

I have seen several different types of messages in playing with the source code. They all come out of the same general error about deserializing blocks from disk. It's an issue that can be seen fairly fast. Just move far enough that it would reload a block and come back. Bam! It then crashes every time for me. I am not sure if its corrupt data on the disk file or corrupted when it loads it back. In either case it does surround compressed blocks stored on disk.

This seems like a major issue to me as it fails even the same way with the official releases too. The only way I can get it to load again is to erase the entire world folder. I have tried the file that shows in the error, but that usually doesn't fix it as when I start it up again it finds another file corrupt.

It is major issue for windows users If you want to isolate this bug, you must use 'git bisect' option and find a build which introduced that bug.

Another consideration: Weedy uses msvc2010 compiler (and builds few other libs himself) but celeron-55 uses msvc2005 (and uses provided libs from packages). Same code runs better in first case. What the cause of this I don't know.

[No-Half-Measures]

As far is I know Weedy has not removed anything in that particular minetest-0.2.20110801-win32 build of m-c55 but used newer compiler and compiled few other libs himself.

Then how would using Weedy's build Help anyone at all, Please stop referring people to his build unless there's actually a legit reason. And compiling a few Libs himself does not help in any factor and is actually a waste of his time.

It is major issue for windows users If you want to isolate this bug, you must use 'git bisect' option and find a build which introduced that bug.

Another consideration: Weedy uses msvc2010 compiler (and builds few other libs himself) but celeron-55 uses msvc2005 (and uses provided libs from packages). Same code runs better in first case. What the cause of this I don't know.

Not just a Windows Issue just on Linux its a Hell lot Easier to Compile code.

Also whether your using 2005 and/or 2010 it does not matter.

This Section is too Help solve a Problem not just push it aside by suggesting something else to use.

[parlock]

Ok. So I was building it with VS 2008. I just switched it up to VS 2010 and it appears that build has fixed the problem of it crashing. Not sure how using the newer one does, but my guess might be they fixed an issue in the standard libraries that come with VS.

[Fixerol]

Then how would using Weedy's build Help anyone at all, Please stop referring people to his build unless there's actually a legit reason. And compiling a few Libs himself does not help in any factor and is actually a waste of his time.

You are suggesting to users to delete invalid blocks every few minutes instead of providing working build (as noted by at least 3 people). It lets people play, they don't want to fix the code (except of parlock and developers).

Also whether your using 2005 and/or 2010 it does not matter.

You can't know everything. And yes - it matters after testing of compilers by perlock.

This Section is too Help solve a Problem not just push it aside by suggesting something else to use.

Users already provided feedback. Developers don't know exact causes of this bug. However, working build available. Why are you insulting?

[Fixerol]

Ok. So I was building it with VS 2008. I just switched it up to VS 2010 and it appears that build has fixed the problem of it crashing. Not sure how using the newer one does, but my guess might be they fixed an issue in the standard libraries that come with VS.

Big thanks parlock! That what I was suspecting. Btw zlib dll has been build with msvc2010 too

[DMV27]

Here is a patch for minetest-0.2.20110731_3 that fixes the crash, and also seems to fix the random block corruption.

The crash is caused by stof() in utility.h due to the use of an uninitialized variable. This code is used on all compilers except MSVC 2010.

loadBlock() in map.cpp has been fixed to remove the assert(0) crash, and fix the save after load code.

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

diff -Nurp8 old/map.cpp new/map.cpp
--- old/map.cpp    2011-07-31 08:54:54 -0400
+++ new/map.cpp    2011-08-07 15:57:29 -0400
@@ -3236,48 +3236,59 @@ void ServerMap::loadBlock(std::string se
         bool created_new = false;
         block = sector->getBlockNoCreateNoEx(p3d.Y);
         if(block == NULL)
         {
             block = sector->createBlankBlockNoInsert(p3d.Y);
             created_new = true;
         }
         
-        // Read basic data
-        block->deSerialize(is, version);
+        try
+        {
+            // Read basic data
+            block->deSerialize(is, version);
 
-        // Read extra data stored on disk
-        block->deSerializeDiskExtra(is, version);
+            // Read extra data stored on disk
+            block->deSerializeDiskExtra(is, version);
+        }
+        catch(...)
+        {
+            if(created_new)
+                delete block;
+            throw;
+        }
         
         // If it's a new block, insert it to the map
         if(created_new)
             sector->insertBlock(block);
         
         /*
             Save blocks loaded in old format in new format
         */
 
         if(version < SER_FMT_VER_HIGHEST || save_after_load)
         {
+            // Close the file before saving to it.
+            is.close();
             saveBlock(block);
         }
         
         // We just loaded it from the disk, so it's up-to-date.
         block->resetModified();
 
     }
     catch(SerializationError &e)
     {
         dstream<<"WARNING: Invalid block data on disk "
                 <<"fullpath="<<fullpath
                 <<" (SerializationError). "
                 <<"what()="<<e.what()
                 <<std::endl;
                 //" Ignoring. A new one will be generated.
-        assert(0);
+        //assert(0);
 
         // TODO: Backup file; name is in fullpath.
     }
 }
 
 MapBlock* ServerMap::loadBlock(v3s16 blockpos)
 {
     DSTACK(__FUNCTION_NAME);
diff -Nurp8 old/utility.h new/utility.h
--- old/utility.h    2011-07-31 08:54:54 -0400
+++ new/utility.h    2011-07-31 15:38:48 -0400
@@ -849,20 +849,17 @@ inline s32 stoi(std::string s)
 
 inline s32 stoi(std::wstring s)
 {
     return atoi(wide_to_narrow(s).c_str());
 }
 
 inline float stof(std::string s)
 {
-    float f;
-    std::istringstream ss(s);
-    ss>>f;
-    return f;
+    return atof(s.c_str());
 }
 
 #endif
 
 inline std::string itos(s32 i)
 {
     std::ostringstream o;
     o<<i;


[celeron55]

The crash is caused by stof() in utility.h due to the use of an uninitialized variable. This code is used on all compilers except MSVC 2010.

That could not have caused anything like this. I suspect the way your code fixes the problem is only that it ignores errors at load time and causes failed-to-load blocks to regenerate, thus destroying data. This is not a fix, it only hides the error.

[No-Half-Measures]

The crash is caused by stof() in utility.h due to the use of an uninitialized variable. This code is used on all compilers except MSVC 2010.

That could not have caused anything like this. I suspect the way your code fixes the problem is only that it ignores errors at load time and causes failed-to-load blocks to regenerate, thus destroying data. This is not a fix, it only hides the error.

Beat me too it though I was just going to Say it looks like a work around not a fix. ^^

Like I Said in a earlier Post the Problem can only be nullified not fixed (may have said in another topic) and that's exactly what this/that does, It is a nice fix how ever if Part of a awesomely big build receives the problem its going to start regenerating those blocks. You might as well let a Greifer come and Destroy it. This Would appear to be similar to what Weedy's Build does too.

It's a nice fix but could potentially cause more problems than needed in the long run.

[celeron55]

This Would appear to be similar to what Weedy's Build does too.

To my knowledge what Weedy has done is that he has just built the unmodified c55 code using self-compiled libraries and VS2010, thus you are wrong. Or am I wrong?

[No-Half-Measures]

To my knowledge what Weedy has done is that he has just built the unmodified c55 code using self-compiled libraries and VS2010, thus you are wrong. Or am I wrong?

Well if it is Self Compiled libraries it be nice of him to share with you to which libraries he's compiled...
But to be greatly honest I don't see how compiling libraries yourself would solve the issue, though MS2010 Might be what does fix it which makes me Wrong on something else I said in another thread >.< But that just means packages included with MS2010 are done better thus nullifying it allot more.

I heard you compile with a 2005 version?
If that true then I'm not sure why I haven't come across this problem with your builds, The one time i had the Build i was using was built with 2010 =/

[celeron55]

I do build it using VS2005... uh, and overally quite a random setup running on a Windows 2000 virtual machine. The good thing about that is that it builds stuff fine without swapping on disk even with 200MB of memory.

Creating an another build environment is time-consuming and getting Windows XP and VS2008 legally is expensive.