Problems on window 7

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

Problems on window 7

by Cer989 » Sat May 14, 2011 16:01

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
New member
 
Posts: 4
Joined: Sat May 14, 2011 15:58

by Cer989 » Sat May 14, 2011 16:02

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

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

by smg » Sat Jul 30, 2011 22:43

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
New member
 
Posts: 5
Joined: Sat Jul 30, 2011 22:40

by smg » Sun Jul 31, 2011 00:25

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
Administrator
 
Posts: 453
Joined: Tue Apr 19, 2011 10:10
GitHub: celeron55
IRC: celeron55

by celeron55 » Sun Jul 31, 2011 00:47

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: 891
Joined: Sun Jul 31, 2011 11:23
Location: Ukraine
IRC: Fixer
In-game: Fixer

by Fixer » Sun Jul 31, 2011 11:29

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
 

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

by Destroyer661 » Sun Jul 31, 2011 15:16

Getting the exact same error on Win7. :D
 

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

by smg » Sun Jul 31, 2011 23:24

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: 891
Joined: Sun Jul 31, 2011 11:23
Location: Ukraine
IRC: Fixer
In-game: Fixer

by Fixer » Mon Aug 01, 2011 13:28

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-0.2.20110724_0-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
 

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

by smg » Mon Aug 01, 2011 16:27

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

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

by smg » Tue Aug 02, 2011 02:32

so far so good i this works.
 

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

by Fixer » Tue Aug 02, 2011 19:12

smg wrote:so far so good i this works.


Please try this newest build from Weedy - http://weedy.ca/minetest/minetest-0.2.20110801-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 » Wed Aug 03, 2011 21:27

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 » Sun Aug 07, 2011 04:11

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
Member
 
Posts: 149
Joined: Tue Jul 26, 2011 00:42

by No-Half-Measures » Sun Aug 07, 2011 09:54

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: 891
Joined: Sun Jul 31, 2011 11:23
Location: Ukraine
IRC: Fixer
In-game: Fixer

by Fixer » Sun Aug 07, 2011 10:38

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

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

by No-Half-Measures » Sun Aug 07, 2011 11:51

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

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

by parlock » Sun Aug 07, 2011 12:32

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: 891
Joined: Sun Jul 31, 2011 11:23
Location: Ukraine
IRC: Fixer
In-game: Fixer

by Fixer » Sun Aug 07, 2011 12:42

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: 891
Joined: Sun Jul 31, 2011 11:23
Location: Ukraine
IRC: Fixer
In-game: Fixer

by Fixer » Sun Aug 07, 2011 12:47

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
 

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

by No-Half-Measures » Sun Aug 07, 2011 13:01

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 » Sun Aug 07, 2011 13:18

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: 891
Joined: Sun Jul 31, 2011 11:23
Location: Ukraine
IRC: Fixer
In-game: Fixer

by Fixer » Sun Aug 07, 2011 13:19

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: 891
Joined: Sun Jul 31, 2011 11:23
Location: Ukraine
IRC: Fixer
In-game: Fixer

by Fixer » Sun Aug 07, 2011 13:22

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
 

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

by DMV27 » Sun Aug 07, 2011 20:30

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;
 

Next

Return to Problems



Who is online

Users browsing this forum: No registered users and 4 guests