Problems on window 7

User avatar
Cer989
New member
Posts: 4
Joined: Sat May 14, 2011 15:58

Problems on window 7

by Cer989 » Post

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

User avatar
Cer989
New member
Posts: 4
Joined: Sat May 14, 2011 15:58

by Cer989 » Post

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

User avatar
smg
New member
Posts: 5
Joined: Sat Jul 30, 2011 22:40

by smg » Post

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?

User avatar
smg
New member
Posts: 5
Joined: Sat Jul 30, 2011 22:40

by smg » Post

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.

User avatar
celeron55
Administrator
Posts: 469
Joined: Tue Apr 19, 2011 10:10
GitHub: celeron55
IRC: celeron55

by celeron55 » Post

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...

User avatar
Fixer
Member
Posts: 898
Joined: Sun Jul 31, 2011 11:23
IRC: Fixer
In-game: Fixer
Location: Ukraine

by Fixer » Post

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.

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:

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)
Last edited by Fixer on Sun Jul 31, 2011 12:02, edited 1 time in total.
ContentDB | MODsearch | Bugs\FR\PR | DevWiki | ModdingBook | BisectBug | Compile with MSYS2/mingw64 | Minetest 5 win64 build has GC64 support (no OOMs)
GDB backtrace: 1) compile mt with -DCMAKE_BUILD_TYPE=Debug 2) run in console: gdb path_to_minetest_binary; then in gdb: set logging on; run; when crash: thread apply all bt

User avatar
Destroyer661
New member
Posts: 1
Joined: Sun Jul 31, 2011 15:13

by Destroyer661 » Post

Getting the exact same error on Win7. :D

User avatar
smg
New member
Posts: 5
Joined: Sat Jul 30, 2011 22:40

by smg » Post

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.

User avatar
Fixer
Member
Posts: 898
Joined: Sun Jul 31, 2011 11:23
IRC: Fixer
In-game: Fixer
Location: Ukraine

by Fixer » Post

smg wrote: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 ... -win32.zip ?
ContentDB | MODsearch | Bugs\FR\PR | DevWiki | ModdingBook | BisectBug | Compile with MSYS2/mingw64 | Minetest 5 win64 build has GC64 support (no OOMs)
GDB backtrace: 1) compile mt with -DCMAKE_BUILD_TYPE=Debug 2) run in console: gdb path_to_minetest_binary; then in gdb: set logging on; run; when crash: thread apply all bt

User avatar
smg
New member
Posts: 5
Joined: Sat Jul 30, 2011 22:40

by smg » Post

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

User avatar
smg
New member
Posts: 5
Joined: Sat Jul 30, 2011 22:40

by smg » Post

so far so good i this works.

User avatar
Fixer
Member
Posts: 898
Joined: Sun Jul 31, 2011 11:23
IRC: Fixer
In-game: Fixer
Location: Ukraine

by Fixer » Post

smg wrote:so far so good i this works.
Please try this newest build from Weedy - http://weedy.ca/minetest/minetest-0.2.2 ... -win32.zip
Last edited by Fixer on Tue Aug 02, 2011 19:12, edited 1 time in total.
ContentDB | MODsearch | Bugs\FR\PR | DevWiki | ModdingBook | BisectBug | Compile with MSYS2/mingw64 | Minetest 5 win64 build has GC64 support (no OOMs)
GDB backtrace: 1) compile mt with -DCMAKE_BUILD_TYPE=Debug 2) run in console: gdb path_to_minetest_binary; then in gdb: set logging on; run; when crash: thread apply all bt

User avatar
kryyss
Member
Posts: 11
Joined: Sun Jul 31, 2011 00:40

by kryyss » Post

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 :-)
cooked rat for diner !

User avatar
parlock
New member
Posts: 6
Joined: Sun Aug 07, 2011 04:09

by parlock » Post

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?

User avatar
No-Half-Measures
Member
Posts: 149
Joined: Tue Jul 26, 2011 00:42
Contact:

by No-Half-Measures » Post

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)

User avatar
Fixer
Member
Posts: 898
Joined: Sun Jul 31, 2011 11:23
IRC: Fixer
In-game: Fixer
Location: Ukraine

by Fixer » Post

parlock wrote: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.2 ... -win32.zip Or at least you can try to build with MSVC2010.
Last edited by Fixer on Sun Aug 07, 2011 10:40, edited 1 time in total.
ContentDB | MODsearch | Bugs\FR\PR | DevWiki | ModdingBook | BisectBug | Compile with MSYS2/mingw64 | Minetest 5 win64 build has GC64 support (no OOMs)
GDB backtrace: 1) compile mt with -DCMAKE_BUILD_TYPE=Debug 2) run in console: gdb path_to_minetest_binary; then in gdb: set logging on; run; when crash: thread apply all bt

User avatar
No-Half-Measures
Member
Posts: 149
Joined: Tue Jul 26, 2011 00:42
Contact:

by No-Half-Measures » Post

No-Half-Measures wrote:
Fixerol wrote:Try this http://weedy.ca/minetest/minetest-0.2.2 ... 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.

User avatar
parlock
New member
Posts: 6
Joined: Sun Aug 07, 2011 04:09

by parlock » Post

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.

User avatar
Fixer
Member
Posts: 898
Joined: Sun Jul 31, 2011 11:23
IRC: Fixer
In-game: Fixer
Location: Ukraine

by Fixer » Post

No-Half-Measures wrote: 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.
ContentDB | MODsearch | Bugs\FR\PR | DevWiki | ModdingBook | BisectBug | Compile with MSYS2/mingw64 | Minetest 5 win64 build has GC64 support (no OOMs)
GDB backtrace: 1) compile mt with -DCMAKE_BUILD_TYPE=Debug 2) run in console: gdb path_to_minetest_binary; then in gdb: set logging on; run; when crash: thread apply all bt

User avatar
Fixer
Member
Posts: 898
Joined: Sun Jul 31, 2011 11:23
IRC: Fixer
In-game: Fixer
Location: Ukraine

by Fixer » Post

parlock wrote: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.
ContentDB | MODsearch | Bugs\FR\PR | DevWiki | ModdingBook | BisectBug | Compile with MSYS2/mingw64 | Minetest 5 win64 build has GC64 support (no OOMs)
GDB backtrace: 1) compile mt with -DCMAKE_BUILD_TYPE=Debug 2) run in console: gdb path_to_minetest_binary; then in gdb: set logging on; run; when crash: thread apply all bt

User avatar
No-Half-Measures
Member
Posts: 149
Joined: Tue Jul 26, 2011 00:42
Contact:

by No-Half-Measures » Post

Fixerol wrote: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.

Fixerol wrote: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.
Last edited by No-Half-Measures on Sun Aug 07, 2011 13:02, edited 1 time in total.

User avatar
parlock
New member
Posts: 6
Joined: Sun Aug 07, 2011 04:09

by parlock » Post

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.

User avatar
Fixer
Member
Posts: 898
Joined: Sun Jul 31, 2011 11:23
IRC: Fixer
In-game: Fixer
Location: Ukraine

by Fixer » Post

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?
Last edited by Fixer on Sun Aug 07, 2011 13:26, edited 1 time in total.
ContentDB | MODsearch | Bugs\FR\PR | DevWiki | ModdingBook | BisectBug | Compile with MSYS2/mingw64 | Minetest 5 win64 build has GC64 support (no OOMs)
GDB backtrace: 1) compile mt with -DCMAKE_BUILD_TYPE=Debug 2) run in console: gdb path_to_minetest_binary; then in gdb: set logging on; run; when crash: thread apply all bt

User avatar
Fixer
Member
Posts: 898
Joined: Sun Jul 31, 2011 11:23
IRC: Fixer
In-game: Fixer
Location: Ukraine

by Fixer » Post

parlock wrote: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
Last edited by Fixer on Sun Aug 07, 2011 13:23, edited 1 time in total.
ContentDB | MODsearch | Bugs\FR\PR | DevWiki | ModdingBook | BisectBug | Compile with MSYS2/mingw64 | Minetest 5 win64 build has GC64 support (no OOMs)
GDB backtrace: 1) compile mt with -DCMAKE_BUILD_TYPE=Debug 2) run in console: gdb path_to_minetest_binary; then in gdb: set logging on; run; when crash: thread apply all bt

User avatar
DMV27
New member
Posts: 3
Joined: Sun Aug 07, 2011 19:35
In-game: DMV27

by DMV27 » Post

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.

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;

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests