| *** Zehra <Zehra!~Yukari@user/yukari> has joined #bzflag | 00:11 | |
| *** Juesto <Juesto!~Juest@user/Juest> has joined #bzflag | 01:35 | |
| *** Juest <Juest!~Juest@user/Juest> has quit IRC (Ping timeout: 256 seconds) | 01:37 | |
| *** Juesto is now known as Juest | 01:37 | |
| *** Sgeo_ <Sgeo_!~Sgeo@user/sgeo> has quit IRC (Read error: Connection reset by peer) | 02:01 | |
| *** Sgeo <Sgeo!~Sgeo@user/sgeo> has joined #bzflag | 02:01 | |
| *** the_map_ <the_map_!~the_map@user/the-map/x-5158391> has quit IRC (Ping timeout: 244 seconds) | 02:28 | |
| *** the_map_ <the_map_!~the_map@user/the-map/x-5158391> has joined #bzflag | 02:30 | |
| *** Zehra <Zehra!~Yukari@user/yukari> has quit IRC (Quit: Leaving) | 03:43 | |
| *** disco <disco!~user@154.51.119.136> has quit IRC (Ping timeout: 256 seconds) | 07:01 | |
| *** disco <disco!~user@154.51.119.136> has joined #bzflag | 07:07 | |
| *** FastLizard4 is back | 07:36 | |
| *** FastLizard4 is now away: AWAY from keyboard | 08:01 | |
| *** FastLizard4 is back | 08:29 | |
| *** FastLizard4 is now away: IN-GAME - Baldur's Gate 3 | 08:34 | |
| *** Sgeo <Sgeo!~Sgeo@user/sgeo> has quit IRC (Read error: Connection reset by peer) | 09:01 | |
| *** Flash_ <Flash_!~Flash@user/flash> has quit IRC (Ping timeout: 244 seconds) | 09:03 | |
| *** Flash <Flash!~Flash@user/flash> has joined #bzflag | 09:06 | |
| *** Cobra_Fast is now away: offline | 12:46 | |
| *** Cobra_Fast is back | 12:46 | |
| *** FastLizard4 is back | 13:00 | |
| *** FastLizard4 is now away: AWAY from keyboard | 14:33 | |
| *** FastLizard4 is back | 14:59 | |
| *** FastLizard4 is now away: AWAY from keyboard | 15:08 | |
| *** FastLizard4 is back | 15:19 | |
| *** FastLizard4 is now away: AWAY from keyboard | 15:45 | |
| *** FastLizard4 is now away: GONE - Screen Detached and Disconnected from IRC (I'm probably asleep, at work, or doing something in real life) | 16:12 | |
| *** Sgeo <Sgeo!~Sgeo@user/sgeo> has joined #bzflag | 18:49 | |
| tupone | blast007: I can revert that. It is strange that this create a problem, but plugins could bypass FlagType | 20:18 |
|---|---|---|
| tupone | or you fixed already ? | 20:23 |
| blast007 | I was gonna check on it a bit further to see if there are any other side effects or if it was jsut plugins | 21:04 |
| blast007 | just* | 21:04 |
| blast007 | without the fix, I do get two memory leaks reported by LeakSanitizer (one 40 bytes direct and one 8 bytes indirect) | 21:13 |
| blast007 | hmm.. maybe that's not right... now I'm seeing it with that commit in place... | 21:16 |
| blast007 | I guess the leak I'm seeing is somehow released to what my test plugin is doing. It just happened that when I just ran an unmodified bzfs with that plugin it didn't, and then when I turned right around and removed that line from the FlagType destructor and ran bzfs with that plugin again it DID generate that memory leak. | 21:23 |
| blast007 | (but then I put the line back and ran the original way again, and did get the leak) | 21:24 |
| tupone | to me it seems natural to clean the flagAbbv as it should be created by the constructor, unless that flagAbbrev was already in place and then flagtype override it :/ | 21:25 |
| blast007 | ah, running it through gdb seems to either prevent or mask the leak, or disable the LeakSanitizer | 21:26 |
| blast007 | I just have only run it through gdb the first time | 21:26 |
| blast007 | yeah, the problem is that we make a const copy of a FlagType in at least one spot, so that ends up calling the destructor prior to the server shutting down | 21:27 |
| blast007 | we do it in at least WorldWeapons::fire() | 21:28 |
| blast007 | oh sorry, we make a non-const copy | 21:28 |
| tupone | getFlagMap()[flagAbbv] = this; << could be that we did more then once ? | 21:32 |
| blast007 | no, it's just that we're making a copy of a FlagType object in a function we call, and when it leaves the scope it calls the destructor, removing the flag type from the flag map on a running server | 21:34 |
| tupone | ahh, that explain it | 21:34 |
| blast007 | I think I fixed it by using a const_cast in WorldWeapons::fire() | 21:35 |
| blast007 | I'll do some more testing | 21:35 |
| blast007 | right now, instead of "FlagType type = *(w->type);" I'm doing "FlagType *type = const_cast<FlagType *>(w->type);", and then I remove the & from type on the call to fireShot | 21:36 |
| tupone | for the high frame problem I have not coded anything but I think the solution for the remote player is to save the last time we receive the remote msg , and the last cinematic we rx. and use dead reckon (always from the same pos/speed) until we get a new msg | 21:38 |
| tupone | For the local is a bit more problematic. I have not yet in mind the solution. Need to integrate the movement maybe :/ | 21:39 |
| blast007 | are you referring to issue #327 ? | 21:49 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!