Time |
Nick |
Message |
00:00 |
hmmmm |
say it out loud in a sentence: "oh this variable is the mtsetting value" |
00:00 |
hmmmm |
vs. "this is the setting instead" |
00:01 |
hmmmm |
the latter of the two sounds like you were having a conversation with somebody, and you don't have a sentence or two of context |
00:01 |
|
paramat joined #minetest-dev |
00:01 |
hmmmm |
the former can stand on its own |
00:06 |
paramat |
hmmmm i'm beginning to think #2665 may just be a natural result of using a lua mapgen with a heavy use of noise. my own tests show watershed uses up to 1.5GB of memory, riverdev uses up to 2GB (10 3D noises, 6 2D noises) |
00:06 |
ShadowBot |
https://github.com/minetest/minetest/issues/2665 -- get_perlin_map consumes all memory and brings down servers |
00:06 |
hmmmm |
no there's a memory leak somewhere |
00:07 |
hmmmm |
i was trying something out before |
00:07 |
paramat |
aha |
00:07 |
hmmmm |
also see the two other issues related to memory |
00:08 |
paramat |
ok |
00:12 |
paramat |
it's also present in 0.4.12 stable, same results |
00:21 |
paramat |
testing mgv7, it has a steady rise in memory use when flying and generating, after 5 mins i'm up to 2GB usage. if i stop exploring it stays level |
00:21 |
paramat |
doesn't fall |
00:22 |
hmmmm |
sure... but that has nothing to do with noise |
00:23 |
hmmmm |
set the unused block unload timeout to be very short, after flying around you should expect the memory usage to be around what you started at |
00:23 |
paramat |
whereas a lua mapgen has a rise and fall of memory use during flying and generating |
00:23 |
hmmmm |
like after flying around, stare at the ground and do nothing for a few minutes |
00:24 |
paramat |
seems a core mapgen problem |
00:24 |
hmmmm |
eh, i'm not so sure it's a mapgen problem |
00:24 |
hmmmm |
the mapgen allocates no memory when it's generating map |
00:24 |
hmmmm |
unless there was some kind of change i wasn't aware of |
00:40 |
paramat |
ok with block unload timeout of 1 min the memory use rise is slower, 1GB after 5min. now staring at the ground but no reduction yet |
01:13 |
paramat |
same behaviour in mgv5. flying back and forth over generated terrain doesn't increase memory use, seems to be due to generating new terrain |
01:13 |
|
paramat left #minetest-dev |
01:30 |
|
Wayward_One joined #minetest-dev |
01:30 |
|
Wayward_One joined #minetest-dev |
01:30 |
|
Wayward_One joined #minetest-dev |
01:30 |
|
Wayward_One joined #minetest-dev |
01:32 |
|
Zeno` joined #minetest-dev |
01:45 |
|
Wayward_Tab joined #minetest-dev |
01:47 |
hmmmm |
est31, https://github.com/minetest/minetest/pull/1885 |
01:51 |
Zeno` |
noooooO! |
01:51 |
Zeno` |
That is not good |
01:51 |
hmmmm |
good or not good |
01:51 |
Zeno` |
not |
01:51 |
hmmmm |
[05:49 PM] <est31> hmmmm, what do you think is the preprocessor hack ugly or nice? https://github.com/est31/minetest/commit/4129674ad8446ada991b842041d0bcae775cd738 |
01:51 |
hmmmm |
est31 wants to bring CoreSettings back |
01:52 |
Zeno` |
oh hang on./. |
01:52 |
hmmmm |
I think it's great, personally, instead of adding some kind of callback mechanism why not just make settings fast |
01:52 |
hmmmm |
and atomic |
01:53 |
Zeno` |
that's my second version, so it's half ok |
01:54 |
Zeno` |
The reason I left this and didn't complete what I started is I realised it wasn't worth it |
01:55 |
Zeno` |
The whole (current) design is kind of wrong |
01:55 |
Zeno` |
hang on... |
01:55 |
hmmmm |
est is very eager to code stuff =] |
01:57 |
Zeno` |
How is this new version faster? |
01:57 |
Zeno` |
oh i see |
01:58 |
hmmmm |
a single memory location read vs. a lock, a std::map lookup, and then a string-to-whatever conversion?? |
01:58 |
Zeno` |
Yes, well this is more like how it should have been done |
01:58 |
Zeno` |
in the first place I mean |
01:58 |
hmmmm |
right |
01:59 |
hmmmm |
this doesn't replace callbacks |
01:59 |
Zeno` |
*nod* |
01:59 |
hmmmm |
callbacks and this can coexist peacefully |
01:59 |
Zeno` |
I don't give a @*(#*@ about callbacks tbh :) |
01:59 |
hmmmm |
they need to be there so events can be triggered on changing a setting other than setting the value to something new |
01:59 |
Zeno` |
If I had gotten back to this, this (est31 current) is more like how I would have approached it |
02:00 |
hmmmm |
well actually no that doesn't need to be there |
02:00 |
Zeno` |
the callback cannot hurt... it's actually nice to know if a setting has changed |
02:00 |
hmmmm |
well if a setting has been Set |
02:00 |
Zeno` |
yes |
02:00 |
hmmmm |
if a setting had set called on it and it happened to be the same value as it was previously, there's no telling |
02:01 |
Zeno` |
yes, but there is a fine line there :) |
02:02 |
hmmmm |
btw zeno, how do you feel about overloading functions and operator overloading in general |
02:02 |
Zeno` |
kahrl and I had this discussion when I noticed that something was using some setting like it was a variable |
02:02 |
Zeno` |
which was obviously very, very, very slow |
02:02 |
hmmmm |
est wants to get rid of the setU32() setBool() etc. distinctions and have overloaded set() |
02:03 |
Zeno` |
:( |
02:03 |
Zeno` |
I don't like it |
02:03 |
hmmmm |
all in the name of 'expressiveness' |
02:03 |
hmmmm |
grr |
02:03 |
hmmmm |
hold a vote |
02:03 |
Zeno` |
why, grrr? :) |
02:03 |
hmmmm |
because I want things to be immediately obvious and not dependent upon context |
02:04 |
Zeno` |
just let me remember why I don't like it... I have to look something up |
02:04 |
Zeno` |
oh this is just for settings you mean? |
02:04 |
hmmmm |
yeah |
02:04 |
hmmmm |
btw what is our policy on operator overloading? |
02:05 |
Zeno` |
that's different. I thought you meant in general (everywhere) |
02:05 |
Zeno` |
for settings it makes sense |
02:06 |
Zeno` |
My "policy" is that if the calling "program" should never, ever, care what the internals should be then it's ok |
02:07 |
Zeno` |
it can get confusing |
02:08 |
Zeno` |
I think maybe getNode() is a good example |
02:08 |
Zeno` |
nope, that's not a good example of this, but it is confusing |
02:09 |
hmmmm |
so in general we can agree that being explicit is better than implicit |
02:09 |
Zeno` |
in general, yes |
02:09 |
hmmmm |
overloaded things require context to make sense of them, and context means that you have a higher cognitive burden |
02:10 |
hmmmm |
minetest is already complicated enough as it is |
02:10 |
hmmmm |
ugh |
02:10 |
Zeno` |
correct, so the more abstracted something is the more implicit it can be |
02:11 |
Zeno` |
*sigh* |
02:11 |
Zeno` |
minetest is not like that though |
02:11 |
Zeno` |
just look at how intermingled and entrenched irrlicht is |
02:11 |
Zeno` |
there is no reason for that... there is no "separation" |
02:12 |
hmmmm |
switching to a new engine would be a great time for fixing this |
02:12 |
Zeno` |
so I think adding implicitness all over the place is, in general, not a good idea at this time |
02:12 |
hmmmm |
i think it can be done without restarting the entire project from scratch |
02:12 |
Zeno` |
I believe it could be done as well |
02:13 |
Zeno` |
I even started |
02:13 |
Zeno` |
:) |
02:13 |
Zeno` |
but then got sidetracked haha |
02:13 |
Zeno` |
(I don't start things that I don't believe can be done) |
02:18 |
Zeno` |
going back, for settings I think explicit like setU32() is silly because a) The programmer *must know the type anyway* of the setting (i.e. selecting the right function depends upon the actual setting so you have to have a general idea at least of the setting type to store a value of that type in a local object, which you are likely to base your new set() call off)) |
02:18 |
Zeno` |
hmmmm, do you know Qt? |
02:18 |
hmmmm |
nope |
02:19 |
Zeno` |
http://doc.qt.io/qt-4.8/qvariant.html |
02:19 |
hmmmm |
so I guess set() works, but definitely not get() |
02:19 |
Zeno` |
That is a class I actually like |
02:19 |
hmmmm |
that's downright dangerous |
02:20 |
Zeno` |
so you have a settings class that returns a QVariant (I'm just rambling for an example)... |
02:20 |
hmmmm |
QVariant.asString() or something? |
02:20 |
Zeno` |
then you can do assert(var.isBool); then bool var = var.toBool() |
02:20 |
Zeno` |
asBool() |
02:20 |
Zeno` |
yeah |
02:21 |
hmmmm |
it does seem architecturally nice but isn't that going to be more efficient in the long run |
02:21 |
hmmmm |
less efficient i mean |
02:21 |
hmmmm |
what's wrong with what we got |
02:22 |
Zeno` |
correct. I'm just using it as an example where I think the implicitness is done Right(TM) |
02:22 |
Zeno` |
QVariant is mostly used for settings and callbacks |
02:22 |
hmmmm |
the beer we got drank pretty gud, don't it? |
02:22 |
Zeno` |
heh |
02:22 |
hmmmm |
https://www.youtube.com/watch?v=MZoTJzh13n8 |
02:23 |
Zeno` |
By example, it was more an answer to your question in general... not an answer for minetest :P |
02:23 |
hmmmm |
you're going to write the same amount of code to do it either way |
02:23 |
hmmmm |
probably more code with the QVariant-type thing |
02:24 |
Zeno` |
lots more code |
02:24 |
hmmmm |
each getThing() maps to a get() + an asThing() |
02:24 |
Zeno` |
I'm not suggesting it as an answer :) |
02:24 |
Zeno` |
Sometimes I just like discussing things heh |
02:24 |
Zeno` |
I should preclude these discussions with <StartRamblingNow> |
02:25 |
Zeno` |
Next we'll be using templates for Settings.... |
02:26 |
hmmmm |
pew |
02:26 |
|
VanessaE joined #minetest-dev |
02:27 |
Zeno` |
yay |
02:27 |
Zeno` |
oops, spoke to soon. |
02:27 |
Zeno` |
android is annoying :( |
02:53 |
Zeno` |
maybe it's a java error :( |
02:55 |
Zeno` |
E/minetest(17340): Shutting down minetest. |
02:55 |
Zeno` |
V/threaded_app(17340): android_app_destroy! |
02:55 |
Zeno` |
and yet... it's still there in the task manager |
02:57 |
Zeno` |
maybe I can check the android version somehow and just put the exit(0) hack back |
03:29 |
Zeno` |
hmmmm |
03:29 |
Zeno` |
https://github.com/minetest/minetest/commit/f1ccfd3c3d7d626087f70b8c5798110cd28b248a#diff-60aa608aac2fefb1a86d4c2861a08eb7R361 |
03:29 |
hmmmm |
yes i know |
03:29 |
hmmmm |
didn't somebody fix that already? |
03:29 |
Zeno` |
doesn't look like it |
03:29 |
hmmmm |
:| |
03:33 |
Zeno` |
I wonder if I added the incorrect assert |
03:33 |
Zeno` |
(i.e. should have been assert (i <= 6);) |
03:34 |
hmmmm |
no, because i can never be equal to 6 inside of that loop |
03:34 |
hmmmm |
it's supposed to range from 0 to 5 |
03:34 |
hmmmm |
0 to 5 is 6 materials |
03:34 |
Zeno` |
lol |
03:35 |
hmmmm |
but the assert was completely incorrect. this is a class of bugs |
03:35 |
Zeno` |
yes |
03:35 |
hmmmm |
developers too smart for their own good think they're adding correctness by using an assert() in a place where input is provided by a remote peer |
03:35 |
hmmmm |
i think this is the 4th? time this particular class of bug cropped up |
03:37 |
Zeno` |
when I changed the asserts to remain in release builds the only ones I left as assert were ones I were not sure of, or ones I put back because sapier said "no, they're real asserts" |
03:37 |
Zeno` |
I were, I were! |
03:37 |
Zeno` |
I must have missed that one |
03:38 |
Zeno` |
wait... filename starts with w |
03:38 |
Zeno` |
I would have been sick to death of checking everything by the time I got to w lol |
03:38 |
Zeno` |
=D |
03:43 |
Zeno` |
Did a recent commit change font sizes? |
03:45 |
hmmmm |
doesn't look like it |
03:47 |
|
FR^4 joined #minetest-dev |
03:47 |
Zeno` |
weird |
03:57 |
|
FR^4 joined #minetest-dev |
04:07 |
|
FR^4 joined #minetest-dev |
04:20 |
Zeno` |
#2665 for anyone awake |
04:21 |
ShadowBot |
https://github.com/minetest/minetest/issues/2665 -- get_perlin_map consumes all memory and brings down servers |
04:21 |
Zeno` |
I dunno if the noise has a leak |
04:21 |
hmmmm |
it doesn't |
04:21 |
Zeno` |
I made a beautiful graph |
04:21 |
hmmmm |
did you run valgrind? |
04:21 |
Zeno` |
massif, yeah |
04:22 |
hmmmm |
the last time you ran massif, noise didn't even show up |
04:22 |
Zeno` |
with minimal game and just the test he provided |
04:22 |
hmmmm |
and what |
04:22 |
Zeno` |
took me a bit to realise I had to type /regen to start the test |
04:22 |
hmmmm |
lua is garbage collected; i can see the kind of problem he's talking about IF he has a low amount of ram, a disabled swapfile, and lua doesn't garbage collect often enough |
04:22 |
Zeno` |
(which is why there is about 10 seconds at the start where no mem at all is really used) |
04:23 |
Zeno` |
yeah |
04:23 |
Zeno` |
as I said in my comment it seems to be normal Lua GC behaviour |
04:23 |
hmmmm |
that guy won't give any details about his test machine |
04:23 |
hmmmm |
in any case, the lua gc should kick in long before there are any crashes due to lack of memory |
04:26 |
Zeno` |
I would think so |
04:27 |
Zeno` |
Although there is a leak *somewhere* |
04:27 |
Zeno` |
just not there |
04:28 |
Zeno` |
probably still the liquids hehe |
04:28 |
Zeno` |
his comment: If you type "/regen" fast enough, memory will keep going up as it does not free up the old memory fast enough. |
04:29 |
Zeno` |
that cannot be right... my test is using the infinite loop so I'm sure the loop is faster than his typing |
04:29 |
Zeno` |
and memory did not just keep going up |
04:38 |
hmmmm |
regardless, the memory consumption is too high for such a mundane task |
04:38 |
hmmmm |
I'm going to split up generating noise and then fetching the table of values |
04:38 |
Zeno` |
yes |
04:38 |
hmmmm |
that also might even make it faster |
04:38 |
Zeno` |
I'm just trying with a larger threshold but splitting would be better |
04:39 |
hmmmm |
i can do splitting in the core Noise object too, but the benefit is nowhere nearly as much |
04:41 |
Zeno` |
I wonder if it's feasible to run massif on my server for "real" data |
04:42 |
Zeno` |
probably way too slow :( |
04:43 |
Zeno` |
valgrind hooks can be in the C++ though... maybe I could utilise that to make a fast version heh |
04:46 |
Zeno` |
866GB is kind of high |
04:47 |
Zeno` |
err MB |
04:48 |
|
chchjesus joined #minetest-dev |
04:48 |
hmmmm |
:/ |
04:48 |
hmmmm |
gonna require some alcohol for this |
04:57 |
Zeno` |
what kind? Pure ethanol? |
04:58 |
hmmmm |
an ethanol/water/grain mash blend with hints of oak flavor |
05:00 |
Zeno` |
bourbon, whiskey or brandy? lol |
05:00 |
hmmmm |
wild turkey |
05:01 |
hmmmm |
by the way, nerzhul pretty much admitted he's not coming back to minetest. i think it's time to fix the HP damage flash |
05:01 |
Zeno` |
ok |
05:02 |
Zeno` |
he did? |
05:02 |
hmmmm |
ye in a PR on github |
05:02 |
Zeno` |
ok, I'll fix it after I finish my tests |
05:02 |
Zeno` |
I didn't bother making a branch because it was 2 lines |
05:04 |
hmmmm |
good riddance, right? i think he could've been an awesome dev |
05:14 |
Zeno` |
http://dpaste.com/0EY7MRN :/ |
05:25 |
hmmmm |
dammit lua, y u take up so much space |
05:26 |
|
Calinou joined #minetest-dev |
05:39 |
hmmmm |
https://github.com/kwolekr/minetest/commit/6e2c214dd172ee1bf21f2172fb8c59b0628bb26f |
05:41 |
hmmmm |
actually no that's stupid |
05:42 |
hmmmm |
I'm going to add a force_place = true boolean per node definition for lua schematics |
05:42 |
hmmmm |
why should I expose lua users to scary bitfields |
05:42 |
Zeno` |
*nod* |
05:43 |
hmmmm |
i'm glad i thought about this more before pushing it |
06:01 |
|
jin_xi joined #minetest-dev |
06:14 |
hmmmm |
alrighty, here is my final version https://github.com/kwolekr/minetest/commit/faf2a7ea91e5c35e922427a3ebd412fce5332b40 |
06:34 |
|
Hunterz joined #minetest-dev |
06:46 |
|
cib0 joined #minetest-dev |
06:50 |
hmmmm |
will push if nobody has anything to say... |
06:54 |
|
kilbith joined #minetest-dev |
07:47 |
|
OldCoder joined #minetest-dev |
07:48 |
|
Chrispm84 joined #minetest-dev |
08:04 |
|
Yepoleb joined #minetest-dev |
08:48 |
|
cib0 joined #minetest-dev |
09:13 |
|
ElectronLibre joined #minetest-dev |
09:25 |
|
Megaf_ joined #minetest-dev |
09:28 |
|
VargaD joined #minetest-dev |
09:31 |
|
Anchakor joined #minetest-dev |
10:51 |
|
cib0 joined #minetest-dev |
11:14 |
|
SopaXT joined #minetest-dev |
12:06 |
|
younishd joined #minetest-dev |
12:23 |
|
Anchakor joined #minetest-dev |
12:52 |
|
cib0 joined #minetest-dev |
13:15 |
|
MinetestForFun joined #minetest-dev |
13:27 |
|
Amaz joined #minetest-dev |
13:38 |
|
cyberarm joined #minetest-dev |
14:22 |
|
prozacgod joined #minetest-dev |
14:24 |
|
prozacgod joined #minetest-dev |
14:53 |
|
cib0 joined #minetest-dev |
15:11 |
|
TheWild joined #minetest-dev |
15:12 |
|
hmmmm joined #minetest-dev |
15:31 |
|
Wayward_One joined #minetest-dev |
15:32 |
|
TheWild joined #minetest-dev |
15:35 |
|
TheWild joined #minetest-dev |
16:14 |
|
crazyR_ joined #minetest-dev |
16:27 |
|
cib_ joined #minetest-dev |
16:36 |
|
Anchakor joined #minetest-dev |
16:53 |
|
cib0 joined #minetest-dev |
16:58 |
|
est31 joined #minetest-dev |
17:06 |
|
Krock joined #minetest-dev |
17:26 |
|
zat joined #minetest-dev |
17:28 |
est31 |
<hmmmm> est wants to get rid of the setU32() setBool() etc. distinctions and have overloaded set() |
17:28 |
est31 |
in fact no |
17:28 |
hmmmm |
I thought that's what you said |
17:28 |
est31 |
original plan was just to overload once |
17:28 |
est31 |
so that you have the same method for the string name and the enum setting type |
17:29 |
hmmmm |
ahh |
17:29 |
est31 |
so setBool(mt_setting_draw_clouds, true) and setBool("draw_clouds", true) |
17:29 |
est31 |
(imagine the mt_setting stuff in uppercase) |
17:29 |
hmmmm |
yes |
17:30 |
hmmmm |
by the way you know how I always harp on readability |
17:30 |
hmmmm |
over brevity |
17:30 |
hmmmm |
when you have something as commonly used as MT_SETTING_DRAW_CLOUDS or whatever it probably makes sense to have a shorter constant name |
17:31 |
hmmmm |
I would have recommended CS_ (for CoreSetting) but that's being used by ClientState |
17:31 |
est31 |
like? |
17:31 |
est31 |
I'm ok with shorter prefixes |
17:31 |
hmmmm |
what if MT_SETTING_ were switched with CFG_ |
17:31 |
hmmmm |
CFG_DRAW_CLOUDS ? |
17:31 |
est31 |
sounds good |
17:31 |
hmmmm |
yea |
17:31 |
hmmmm |
because people have to type this all the time |
17:32 |
est31 |
yes |
17:32 |
hmmmm |
and precisely because people use it all the time, this is why it's not as necessary to have things more verbose and clear |
17:32 |
hmmmm |
at least i would argue |
17:32 |
hmmmm |
because it's so commonplace and better understood than the SRP implementat would be |
17:33 |
est31 |
what does this have to do with srp? |
17:35 |
hmmmm |
because I realize what I'm saying sounds contradictory to what I was saying about the naming of constructs in SRP |
17:35 |
est31 |
ah |
17:35 |
est31 |
yea |
17:36 |
est31 |
gtg brb |
17:59 |
|
devmarth joined #minetest-dev |
18:20 |
|
Wayward_One joined #minetest-dev |
18:42 |
|
Wayward_One joined #minetest-dev |
18:47 |
|
paramat joined #minetest-dev |
18:48 |
paramat |
hmmmm yeah a per-node force-place bool is much better |
18:49 |
paramat |
you just need to update mg_schematic.h lines 54-56 |
18:49 |
paramat |
and add notes about the bool |
18:52 |
|
est31 joined #minetest-dev |
18:53 |
paramat |
so now soon i will add the full set of biomes to mgv5/v7 |
19:05 |
hmmmm |
what do you mean update 54-56? |
19:05 |
hmmmm |
that's the file format, not the lua table format |
19:06 |
hmmmm |
when you define a schematic through a lua table you write the nodes like |
19:06 |
hmmmm |
{name="default:tree", prob=255, param2=0, force_place=true} |
19:08 |
paramat |
aha so bit 7 is still used as the force-place flag in the schem format.. |
19:09 |
hmmmm |
why would you care about user friendliness of a binary file format |
19:09 |
paramat |
exactly |
19:11 |
hmmmm |
so also because yslice probabilities follow the same bitfield format there's a free bit for each vertical level of the schematic |
19:11 |
paramat |
so we actually have 128 levels of prob, but written as 0-255 in the lua table |
19:12 |
hmmmm |
yes |
19:12 |
hmmmm |
so 254 and 255 are technically the same probability value, as is 0 and 1 |
19:12 |
paramat |
clever. is serialize_schematic updated yet, i guess not |
19:12 |
hmmmm |
oh shoot |
19:13 |
hmmmm |
well there's a bug |
19:24 |
|
Calinou joined #minetest-dev |
19:34 |
|
Wayward_Tab joined #minetest-dev |
19:52 |
|
TenPlus2 joined #minetest-dev |
19:52 |
TenPlus2 |
Hi folks, any devs around today ? |
19:53 |
est31 |
yess |
19:53 |
est31 |
:p |
19:53 |
TenPlus2 |
lol, joy!! |
19:54 |
est31 |
what does the error say |
19:54 |
TenPlus2 |
any idea what would cause an std::bad_alloc error ? |
19:54 |
est31 |
how does it happen? |
19:54 |
TenPlus2 |
2015-04-30 12:12:35: ACTION[ServerThread]: player G1127 crafts default:stick 4 |
19:54 |
TenPlus2 |
terminate called after throwing an instance of 'std::bad_alloc' |
19:54 |
TenPlus2 |
what(): std::bad_alloc |
19:54 |
TenPlus2 |
that's one of them |
19:54 |
est31 |
so you know how to reproduce? |
19:54 |
TenPlus2 |
it's random |
19:55 |
est31 |
what version does the server run? |
19:55 |
TenPlus2 |
not always stick being crafted, can be farming, opening chest etc |
19:55 |
TenPlus2 |
server is using 0.4.12 stable for linux... |
19:55 |
TenPlus2 |
I've also tried latest dev to see if it was inadvertanly fixed, bu nope |
19:55 |
est31 |
ok |
19:56 |
TenPlus2 |
*inadvertently |
19:56 |
est31 |
then we obviously have to do something about it :) |
19:56 |
est31 |
(as devs) |
19:56 |
TenPlus2 |
I sit on a test platform far above spawn where nothing happens/spawns/no abms... and wait for the fire sound to disappear, that's when I know server has crashed |
19:57 |
est31 |
so it also happens when no players are online? |
19:57 |
TenPlus2 |
yeah, and the odd time I run standalone server it fails and comes up either std:bad_alloc or segfault |
19:57 |
TenPlus2 |
just ooutta the blue |
19:58 |
est31 |
what do you mean with that? |
19:58 |
TenPlus2 |
I have a copy of the server standalone also so I can test mods before they go live... it happens standalone (singleplayer) also |
19:58 |
TenPlus2 |
but mostly on server |
19:59 |
est31 |
so it seems to be a mod problem? |
19:59 |
TenPlus2 |
no error for ANY of the mods, I was told it was memory problem (running out) so stripped down server to see if that helped... nothing... disabled each mod in turn... nope... |
19:59 |
est31 |
I mean an error a mod caused, but the engine has a bug too and doesnt show the error as such |
20:00 |
TenPlus2 |
most of the errors is simply: "terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc" |
20:01 |
est31 |
There are two possible reasons |
20:01 |
est31 |
1. not enough space |
20:02 |
TenPlus2 |
HDD Space ? |
20:02 |
est31 |
no ram space |
20:02 |
TenPlus2 |
ah, server has 4gb... |
20:02 |
TenPlus2 |
it never goes above 1gb... never! |
20:02 |
est31 |
should be enough in theory |
20:02 |
TenPlus2 |
and the Os (lubuntu 14.04) only uses 102mb |
20:03 |
TenPlus2 |
what's the other reason ? |
20:04 |
est31 |
not enough space in one piece |
20:04 |
est31 |
but I guess thats just wrong |
20:04 |
est31 |
I mean with virtual memory |
20:04 |
est31 |
(read it on the internet) |
20:04 |
est31 |
so in theory it may happen |
20:04 |
TenPlus2 |
we dont use virtual memory... that's disabled and all in tmp space |
20:04 |
est31 |
sorry meant virtual address space |
20:05 |
TenPlus2 |
ahh |
20:05 |
TenPlus2 |
https://github.com/minetest/minetest/issues/2661 |
20:06 |
est31 |
next idea |
20:06 |
est31 |
open it in a debugger |
20:06 |
est31 |
and let it print a stacktrace |
20:06 |
TenPlus2 |
standalone or server ? server isnt physically with me, it's in Wisconsin |
20:07 |
est31 |
whereever you want to debug :) |
20:07 |
est31 |
usually debuggers dont cause overhead |
20:07 |
est31 |
if you only let them print stacktraces |
20:07 |
TenPlus2 |
so add --debug to command line ? |
20:07 |
est31 |
no |
20:07 |
est31 |
thats setting it to debug logleve |
20:07 |
est31 |
l |
20:07 |
est31 |
might be worth the try too |
20:07 |
TenPlus2 |
in minetest.conf... |
20:08 |
TenPlus2 |
gotcha |
20:08 |
est31 |
just expect to have much much more output |
20:08 |
est31 |
really much mor |
20:08 |
est31 |
e |
20:08 |
TenPlus2 |
in that case I'll prolly run it on standalone server tomorrow, the server is on 120gb ssd... |
20:09 |
est31 |
ok then |
20:09 |
est31 |
do you daily truncate the log? |
20:10 |
TenPlus2 |
no, server script copies previous log to another file and starts a new one on restart or crash... so I have a copy... |
20:10 |
TenPlus2 |
I always get to see the last error though and a log of how many times it's restarted |
20:11 |
est31 |
nice |
20:11 |
TenPlus2 |
#!/bin/bash |
20:11 |
TenPlus2 |
while true |
20:11 |
TenPlus2 |
do |
20:11 |
TenPlus2 |
echo "- = R E S T A R T I N G S E R V E R = -" |
20:11 |
TenPlus2 |
sleep 1 |
20:11 |
TenPlus2 |
date >> ~/lastrun.txt |
20:11 |
TenPlus2 |
minetest --server |& tee ~/log.txt |
20:11 |
TenPlus2 |
cp ~/log.txt ~/crashlog.txt -f |
20:11 |
TenPlus2 |
done |
20:11 |
est31 |
next time use a pastebin :) |
20:11 |
TenPlus2 |
oops, my bad |
20:11 |
TenPlus2 |
am too use to using yahoo chat :) |
20:13 |
TenPlus2 |
normally I'd go back to using 0.4.11 but too many mods have been changed over to easily do that, and the players enjoy the new features and new mapgen |
20:15 |
est31 |
try whether verbose logging will help |
20:15 |
est31 |
verbose loglevel |
20:15 |
est31 |
what generally will help is a stacktrace |
20:15 |
est31 |
at least isolates the region |
20:16 |
TenPlus2 |
will give that a go... thanks for the help... and I'll definitely use pastebin for that output :) |
20:16 |
TenPlus2 |
you guys really do work hard on Minetest and it really is an amazing game... thanks for all of that... |
20:16 |
est31 |
loglevels cant give you a stacktrace though |
20:17 |
est31 |
I dont know a method to open gdb for example so that it does nothing more than print stacktraces |
20:17 |
est31 |
and exit |
20:17 |
est31 |
(because I guess that would be what you need) |
20:18 |
|
paramat left #minetest-dev |
20:18 |
TenPlus2 |
will see what can be done tommorrow :) thanks again est... nite all |
20:23 |
|
leat joined #minetest-dev |
20:26 |
|
TheWild joined #minetest-dev |
20:35 |
|
OldCoder joined #minetest-dev |
21:33 |
|
book` joined #minetest-dev |
21:36 |
|
Wayward_One joined #minetest-dev |
22:55 |
hmmmm |
Hmm |
22:56 |
hmmmm |
I think i have a good interm solution for high lua mapgen memory usage |
22:57 |
est31 |
? |
23:00 |
|
Wayward_One joined #minetest-dev |
23:25 |
|
vadim__ joined #minetest-dev |
23:29 |
hmmmm |
garbagecollect() |
23:31 |
hmmmm |
oh wait the guy reporting the bug already knows about this |
23:32 |
hmmmm |
jeez he sure talks a lot |