Time Nick Message 18:05 hmmmm hrmm 18:06 hmmmm never really noticed it, but Client and Server are so un-orthogonal 18:06 hmmmm why does the Server manage its own gamedef components while Client does not? 18:18 celeron55 probably because random 18:18 celeron55 this is one of those questions 18:19 celeron55 i mean, there might have been a reason some years ago, but i'm sure that reason does not exist anymore 19:21 hmmmm I think it's mostly because Game is messy 19:21 hmmmm sure - the file may have been broken up into lots of simple functions, but that doesn't do anything about the actual interface design 19:23 kahrl speaking of Zeno_, what was the last news about the ogre3d branch? 19:24 hmmmm last time he was here, it works but it's buggy 19:24 hmmmm :-) 19:24 kahrl well that's to be expected 19:24 kahrl like any huge rewrite 19:24 hmmmm i hope it doesn't cause too many conflicts with client side modding 19:49 paramat yesterday kilbith posted http://irc.minetest.ru/minetest-dev/2015-08-22#i_4374313 i'm noticing very short rendering freezes in random bursts of 1 or 2, every second or so. more noticeable when flying. i don't seem to remember this happening before 20:01 OldCoder I've been asked if this is significant: serialize.cpp:161:21: warning: comparison between signed and unsigned [-Wsign-compare]: if (is.gcount() != s_size) 20:02 paramat not a big problem, that's why it's only a 'warning' 20:02 OldCoder The person in question states that compiles fail but I don't see how... 20:02 OldCoder unless he has turned on fatal warnings. One more datum... 20:02 OldCoder He states that he has regular serialization errors at runtime and feels this line may be related 20:03 OldCoder Does the speculation seem unwarranted? 20:03 OldCoder Thank you 20:04 paramat actually i notice these brief rendering freezes in 0.4.12 too, perhaps not as often though 20:05 OldCoder Ah. He adds that the runtime message is: Client::handleCommand_ActiveObjectMessages: caught SerializationError: deSerializeString: couldn't read all chars 20:05 OldCoder If anybody is able to comment, I will work on debugging this with him 20:05 OldCoder This seems to be a power user in Romania BTW 20:09 OldCoder Looking at the code, I'd need to speculate myself it's an internationalization issue 21:19 est31 OldCoder, doesn't that error output more? 21:19 est31 I've thought it actually outputs an actual size 21:19 est31 either way, the issue is that he might have too much blocks 21:19 est31 or mods 21:20 est31 or too large media files 21:20 est31 but we are still tweaking the size, so it would be interesting to have it 21:20 OldCoder est1, that is all, it appears; I have a screenshot. What I will do is debug it with him. 21:21 OldCoder I suspect internationalization 21:21 est31 np 21:21 est31 no 21:21 est31 that isnt the problem 21:21 OldCoder No? Not into a JSON file? 21:21 OldCoder There is a Serialize Wide routine 21:21 est31 what does this have to do with json 21:21 est31 this is about ActiveObjectMessages 21:22 est31 there is no json for those 21:22 OldCoder Ah 21:22 OldCoder Moment, getting PNG 21:22 est31 seems to be too many mobs 21:22 OldCoder http://minetest.org/serialize.png 21:23 OldCoder Too many mobs might produce that context est1? ^ 21:23 OldCoder See screenshot 21:23 OldCoder I have a user who is willing to help debug; what would you like us to try? 21:24 est31 its not precisely a bug 21:24 est31 but I think hmmmm added actual limit printing to the error msg 21:24 est31 seems I'm mistaken 21:26 est31 OldCoder, what version is the server? 21:26 OldCoder Latest git 21:26 OldCoder Moment 21:26 OldCoder Well, recent. Looks like I built it fresh on August 9. 21:27 OldCoder What's the GUI key to report the exact server string? 21:27 OldCoder It just says 0.4.13-dev 21:28 OldCoder est31, ^ 21:28 est31 HybridDog gets the error as well... 21:28 est31 OldCoder, type /status 21:28 OldCoder Says 0.4.13-dev 21:28 OldCoder Git date was about 150809 21:29 est31 0.4.13-dev is after the 0.4.13 release 21:29 est31 that cant be 21:29 est31 before we had 0.4.12-dev 21:29 OldCoder Checking sources 21:29 est31 we have 0.4.13 dev since this week 21:30 OldCoder Checking sources 21:30 OldCoder And yet this is what it says :-) 21:30 OldCoder Moment 21:31 OldCoder In fact you made the latest commit... 21:31 OldCoder Author: est31 21:31 OldCoder Date: Sun Aug 9 23:49:39 2015 +0200 21:31 OldCoder Continue with 0.4.13-dev 21:31 OldCoder Shall I update? 21:31 est31 ouch 21:32 est31 seems you pulled in those few hours where we had this release at HEAD 21:32 OldCoder Heh 21:32 OldCoder So this is the wrong release? 21:32 est31 and then hmmmm reverted it 21:32 OldCoder What is there now and should I rebuild? 21:33 est31 yes you should 21:33 OldCoder What will happen or should I do with the error message? 21:33 est31 its more likely a server error than a client error 21:33 est31 can you reproduce it? 21:34 est31 perhaps open a bug for it, HybridDog seems to get it as well 21:34 OldCoder Yes with the player's assistance. This is w_laenger in Germany. 21:34 OldCoder So, the issue is observed but the cause is not known? It is not too many mobs? 21:35 est31 no 21:35 est31 something else 21:37 OldCoder Recompiling. I will report back. Thank you. 21:38 OldCoder It will not be rapid progress; I need to coordinate with a player in Germany but he is interested. 23:20 hmmmm [05:24 PM] but I think hmmmm added actual limit printing to the error msg 23:20 hmmmm I did, but only if the error is actually "the message is too big to (de)serialize" 23:20 est31 yes, realized that later 23:20 hmmmm that error in the screenshot clearly says "couldn't read all chars" 23:20 hmmmm i.e. you've got an invalid pascal string 23:21 est31 pascal? 23:21 est31 dont know pascals memory layout 23:21 hmmmm a string where the length is prefixed to the actual string data is a pascal string 23:21 hmmmm as opposed to a C-string 23:22 est31 arent c++ strings this, too? 23:22 hmmmm C++ std::string? 23:22 est31 I guess its called pascal strings because pascal is older 23:22 hmmmm no, it's an opaque class 23:22 est31 but C hasnt invented that way of strings either have they? 23:22 hmmmm C invented C-strings 23:23 hmmmm null terminator indicates the end of a string 23:23 hmmmm this makes string manipulation functions very simple to write, at the cost of an O(n) length lookup, O(n) concatenation, buffer overrun horror stories, countless off-by-one errors, etc. 23:24 est31 and you can have arbitrarily long strings 23:25 est31 hmmmm, does pascal actually specify the memory layout? 23:25 hmmmm yes 23:25 est31 and c++ doesnt? 23:25 hmmmm absolutely not.. 23:25 est31 then it makes some sense to call them pascal strings 23:26 est31 but it would be interesting to have an implementation of c++ that implements std::string as C-strings 23:26 hmmmm why..? 23:26 est31 because if it doesnt implement them as c-strings it has to store the length some way 23:27 est31 so the only way the spec can be fulfilled is by doing it c-string way, or with similar costs 23:27 hmmmm storing the length along with data doesn't make it a pascal string 23:27 hmmmm pascal strings have definite memory layout 23:28 hmmmm there is absolutely nothing stopping you from writing a class that stores a char array with a length field 23:28 hmmmm if that's non-POD, which std::strings are not, that's not going to have a well-defined memory layout... 23:29 hmmmm some std::string implementations have a built-in buffer for small strings 23:29 hmmmm then above a certain length threshhold they use memory allocated with new[] 23:29 est31 pascal doesnt store strings, it stores arrays 23:29 hmmmm some std::string implementations also have COW 23:29 hmmmm std::string says absolutely nothing about a memory layout 23:30 hmmmm pascal does 23:30 hmmmm it's built into the compiler 23:31 est31 where is the pascal spec? 23:31 hmmmm somewhere on google i suppose 23:31 est31 there are tons of pascal flavours 23:36 est31 ok lets stop this 23:36 est31 perhaps include the actual counts that differed? 23:36 est31 "read 5, but claimed to get 10" 23:37 hmmmm lol no 23:37 hmmmm it's more like "read 2, but claimed to get 0xD74C" 23:37 hmmmm it's clearly memory corruption 23:37 hmmmm because it mostly seems to work, i'm not too concerned with it 23:37 est31 you have to be very sure until you give hardware the fault 23:38 hmmmm ?? 23:38 hmmmm i never claimed the hardware was at fault.. 23:38 est31 it's clearly memory corruption 23:38 hmmmm how does that sentence imply a hardware problem 23:39 est31 ah 23:39 est31 nvm 23:39 est31 still, why are you that sure 23:40 hmmmm there's no other actual explanation 23:40 hmmmm somehow something overwrites that memory 23:41 hmmmm it could be a use-after-free 23:41 est31 from how I get it, memory corruption is this kind of thing that can happen if you use undefined behaviour 23:42 est31 but there can be other parts that cause problems too 23:42 est31 e.g. is the size written the right way? 23:42 hmmmm it's useless to speculate on the exact cause 23:42 est31 perhaps only one active object message type is affected? 23:42 est31 and thats super seldomly used 23:42 hmmmm it's not 23:43 hmmmm this happens at the networking layer somehow 23:43 hmmmm i had vanessae capture logs of raw AOMs before sending 23:44 est31 it still would be interesting to have the actual count 23:44 est31 if its a memory corruption as you claim, the number will likely be very high 23:45 est31 if its another bug, it might perhaps be related to the number, e.g. always higher by two 23:46 hmmmm it happens only on vanessae's server where the number of objects is very high 23:46 hmmmm VERY high 23:46 hmmmm my client gets DDoSed with active object messages from vanessaes server 23:46 est31 I have found a fix for a related bug also by simply looking at the size, seeing that its as double as much than the actual payload, and then correctly speculating that the size gets +=ed twice 23:47 hmmmm maybe 23:48 hmmmm as that bug doesn't actually affect gameplay and it only happens rarely, it's on my backburner 23:48 hmmmm you can chase it if you'd like 23:48 est31 as long as you dont wait until 2 days before release until you give it the blocker labell 23:49 est31 only to stall the date 23:50 est31 either way, I'm right now doing non-core engine stuff, so wont help too much with the engine 23:52 hmmmm it's not a blocker, but it would still be nice if non-blocking bugs got solved...