Timestamps are in GMT/BST.
| 01:03:02 | raptor | hi |
| 01:03:04 | raptor | nothing new |
| 01:03:09 | raptor | watusimoto, where are you? |
| 01:14:13 | sam686 | hi |
| 01:23:16 | raptor | hi |
| 01:23:24 | sam686 | hi |
| 01:29:39 | raptor | sam686: did you see my e-mail about the memory leaks? |
| 01:29:51 | raptor | it may help with the cause of the crash... |
| 01:50:59 | sam686 | how does it crash now? I can't get it to crash on me as of the newest pushed changes.. |
| 01:55:49 | sam686 | Found a bug, using my map gen 6357 Capture, loaded in editor, press ctrl+R several times, then test level in editor produces junk forcefields that you go through them |
| 02:56:37 | raptor | watusimoto says it still crashes for him, i can't duplicate in Linux.. |
| 02:57:10 | | BFLogBot Commit: 1a164ac464d2 | Author: sam8641 | Message: Check if bitfighter.ini already exists locally and can be modified. |
| 02:59:17 | sam686 | I can't seem to crash at all, the one thing I found is a non-crashing problem with ctrl+r adding buggy forcefield in "test level" |
| 03:00:16 | sam686 | could be 2 things why wasusimoto is still crashing: unpushed changes, or forgot to update to latest changes.. |
| 03:01:24 | sam686 | or a third thing: we don't know how to crash |
| 03:05:38 | sam686 | I think I see the memory leak, by adding thousands of loadout zones or goals, and repeatedly rotating them (hold down or keep pressing R), memory usage slowly climbs. |
| 03:06:00 | | raptor Quit (Ping timeout: 244 seconds) |
| 03:08:30 | sam686 | broken F7's input strings pressing multiple buttons? |
| 03:31:37 | | raptor has joined |
| 03:31:37 | | ChanServ sets mode +o raptor |
| 04:09:31 | raptor | hi again sam686 |
| 04:09:36 | raptor | what about f7? |
| 04:09:49 | raptor | with joystick? |
| 04:10:23 | raptor | haha |
| 04:10:32 | raptor | they're all the same! |
| 04:13:54 | | BFLogBot Commit: a610c5ad8358 | Author: buckyballreaction | Message: Remove now-unneeded #define |
| 04:18:54 | raptor | ok, well, there is a real memory leak with the walls (see my e-mail attachement); stuff is being allocated with 'new' but not released |
| 04:19:00 | raptor | but i'm going to bed |
| 04:19:03 | raptor | good night! |
| 04:19:04 | | koda Quit (Quit: you can't say 'hello' without saying 'hell') |
| 04:21:52 | | raptor Quit () |
| 06:05:59 | | amgine123 Quit (Quit: Page closed) |
| 06:31:05 | | CrazyLinuxNerd Quit (Quit: Leaving) |
| 06:31:24 | | CrazyLinuxNerd has joined |
| 06:38:19 | | amgine1234567890 has joined |
| 06:38:27 | amgine1234567890 | sam? |
| 06:38:40 | | amgine1234567890 Quit (Client Quit) |
| 07:10:11 | | Watusimoto has joined |
| 07:51:59 | | CrazyLinuxNerd Quit (Remote host closed the connection) |
| 07:52:18 | | CrazyLinuxNerd has joined |
| 08:02:01 | | Watusimoto Quit (Ping timeout: 252 seconds) |
| 09:03:41 | | Watusimoto has joined |
| 11:07:54 | | LordDVG has joined |
| 13:01:15 | | Wuzzy has joined |
| 13:46:47 | | raptor has joined |
| 13:46:47 | | ChanServ sets mode +o raptor |
| 13:49:20 | raptor | good morning |
| 14:14:38 | Watusimoto | hi |
| 14:15:02 | Watusimoto | I checked out the memory leaks you sent, and I don;t think they are real |
| 14:15:12 | Watusimoto | at least not the ones related to walls |
| 14:18:59 | raptor | really? |
| 14:19:17 | raptor | because i don't ever remember seeing them in previous valgrind reports |
| 14:27:42 | raptor | i'm not very good at solving memory leak problems, admittedly.. |
| 14:29:15 | Watusimoto | well, take wallEdges, for example |
| 14:29:31 | Watusimoto | oh heck, here are my notes |
| 14:29:35 | Watusimoto | ==16327== 9,936 bytes in 138 blocks are definitely lost in loss record 380 of 383 |
| 14:29:35 | Watusimoto | ==16327== at 0x4C2A6E7: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) |
| 14:29:35 | Watusimoto | ==16327== by 0x6AE86B: Zap::WallSegmentManager::rebuildEdges() (WallSegmentManager.cpp:170) |
| 14:29:35 | Watusimoto | ==16327== by 0x6AE7AA: Zap::WallSegmentManager::recomputeAllWallGeometry(Zap::GridDatabase*) (WallSegmentManager.cpp:146) |
| 14:29:35 | Watusimoto | ==16327== by 0x45F148: Zap::EditorUserInterface::rebuildEverything(Zap::GridDatabase*) (UIEditor.cpp:455) |
| 14:29:37 | Watusimoto | ==16327== by 0x45EDEB: Zap::EditorUserInterface::undo(bool) (UIEditor.cpp:383) |
| 14:29:39 | Watusimoto | ==16327== by 0x46BA7D: Zap::EditorUserInterface::onKeyDown(Zap::InputCode) (UIEditor.cpp:3789) |
| 14:29:41 | Watusimoto | ==16327== by 0x420BD6: Zap::Event::inputCodeDown(Zap::UserInterface*, Zap::InputCode) (Event.cpp:156) |
| 14:29:43 | Watusimoto | ==16327== by 0x4210E2: Zap::Event::onKeyDown(Zap::ClientGame*, SDL_Event*) (Event.cpp:352) |
| 14:29:46 | Watusimoto | ==16327== by 0x420C51: Zap::Event::onEvent(Zap::ClientGame*, SDL_Event*) (Event.cpp:170) |
| 14:29:48 | Watusimoto | ==16327== by 0x61AF53: Zap::idle() (main.cpp:658) |
| 14:29:50 | Watusimoto | ==16327== by 0x61AFD6: Zap::dedicatedServerLoop() (main.cpp:680) |
| 14:29:52 | Watusimoto | ==16327== by 0x61D00A: main (main.cpp:1437) |
| 14:29:54 | Watusimoto | This "new" refers to a new WallEdge, which is immdiately added to a database after it has been created. All objects |
| 14:29:57 | Watusimoto | in databases are properly deleted when the database is deleted (if not before), and all databases are properly deleted when the program is shutdown. Therefore, I do not believe that this memory leak is real. |
| 14:30:01 | Watusimoto | the top bit is the stack trace, the bottom is my analysis |
| 14:30:19 | Watusimoto | similar analysis can be done for wallSegments, which are the other reported memory leak |
| 14:30:53 | raptor | hmm |
| 14:31:08 | raptor | so are they deleted when exiting the editor? |
| 14:31:20 | raptor | or just upon program exit? |
| 14:31:29 | Watusimoto | a bit of both |
| 14:31:59 | Watusimoto | some critical cleanup happens as part of editorUserInterface destruction |
| 14:32:04 | Watusimoto | which happens at program exit |
| 14:32:37 | Watusimoto | I can guarantee that each instance of new with a wallSegment or WallEdge gets inserted in a database |
| 14:33:35 | Watusimoto | well... hold on a sec |
| 14:33:43 | raptor | http://valgrind.org/docs/manual/mc-manual.html#mc-manual.leaks |
| 14:34:00 | raptor | "This means that no pointer to the block can be found. The block is classified as "lost", because the programmer could not possibly have freed it at program exit, since no pointer to it exists" |
| 14:34:11 | raptor | under "definitely lost" |
| 14:34:14 | Watusimoto | There is this one little statement int he editor I may have overlooked |
| 14:34:16 | Watusimoto | GridDatabase *newDB = new GridDatabase(); |
| 14:34:29 | Watusimoto | it may be possible that a database created here is never deleted |
| 14:34:44 | Watusimoto | which would result in objects contained therein to be never deleted |
| 14:35:13 | Watusimoto | ah, but no |
| 14:35:15 | Watusimoto | GridDatabase *newDB = new GridDatabase(); // Make a copy |
| 14:35:15 | Watusimoto | newDB->copyObjects(getDatabase()); |
| 14:35:15 | Watusimoto | mUndoItems[mLastUndoIndex % UNDO_STATES] = boost::shared_ptr<GridDatabase>(newDB); |
| 14:35:20 | Watusimoto | it is handed over to boos |
| 14:35:21 | Watusimoto | t |
| 14:40:33 | raptor | i wish i could get it to crash... |
| 14:42:50 | raptor | there were 383 loss records in the report |
| 14:52:28 | raptor | oh look, found a leak in my code.. |
| 14:53:23 | Watusimoto | :-) |
| 14:53:33 | Watusimoto | there are lots of small leaks, some of which we can fix, many not |
| 14:53:59 | raptor | loads in the sound libraries... none of which we really have control over |
| 14:55:40 | | BFLogBot Commit: 12dd575544d3 | Author: buckyballreaction | Message: Fix small memory leak in Linux |
| 14:58:08 | raptor | look at record 260 |
| 14:58:43 | raptor | (and 261) |
| 15:01:22 | Watusimoto | My notes on those: |
| 15:01:24 | Watusimoto | This "new" refers to a new WallSegment, which is added to a database during construction. All objects |
| 15:01:24 | Watusimoto | in databases are properly deleted when the database is deleted (if not before), and all databases are properly deleted when the program is shutdown. Therefore, I do not believe that this memory leak is real. |
| 15:02:01 | raptor | well, according to valgrind's "definitely lost" definition, it seems to me that they are not properly deleted |
| 15:02:51 | raptor | besides, i don't see where that 'WallSegment *newSegment' is actually added to anything that is deleted |
| 15:02:57 | Watusimoto | When I started looking for the error I'm still hunting, I logged every create and delete of wall segments and wall edges... all were accounted for |
| 15:03:19 | Watusimoto | wallSegment is added to a database in the constructor... see the initialize() function |
| 15:04:22 | raptor | ah ok, i see it |
| 15:04:37 | raptor | so i believe you, but i also believe valgrind... |
| 15:05:08 | Watusimoto | yes |
| 15:05:11 | Watusimoto | I understand |
| 15:05:23 | Watusimoto | one possibility is that a database isn't being deleted |
| 15:05:54 | Watusimoto | +but like I said... creates and deletes were balanced |
| 15:06:17 | raptor | valgrind keeps a database of every memory block, and for it to be considered 'definitely lost' it means that no pointer to the memory block exists at program exit |
| 15:08:20 | raptor | but we may be chasing a wild good anyways... |
| 15:08:23 | raptor | *goose |
| 15:08:27 | raptor | good goose |
| 15:08:35 | raptor | sick of turkey.. |
| 15:13:21 | Watusimoto | yes... but if I create 10 objects and delete 10, where is the leak? |
| 15:13:30 | Watusimoto | it's easy to test |
| 15:13:54 | Watusimoto | create a static counter, increment on create, decrement on delete, and logprintf on every delete |
| 15:14:47 | raptor | do you have notes on records 274/275? |
| 15:15:46 | Watusimoto | no |
| 15:15:55 | Watusimoto | but that one led me on a wild goose chase |
| 15:16:40 | Watusimoto | though not directly related to the report at hand |
| 15:19:19 | raptor | ha! |
| 15:19:25 | raptor | i did the static counter |
| 15:19:52 | raptor | Watusimoto: http://pastie.org/5427858 |
| 15:19:57 | Watusimoto | uh oh |
| 15:20:05 | raptor | i loaded a level with a U-shaped wall |
| 15:20:06 | Watusimoto | don't need a pastie to reoprt everything is fine |
| 15:20:27 | raptor | i put it in the constructor and destructor of WallEdge |
| 15:20:55 | Watusimoto | 42?!? |
| 15:20:59 | Watusimoto | that sounds familliar |
| 15:21:05 | raptor | after levwel load, i resized 5x, undo, redo, undo, redo |
| 15:21:15 | raptor | maybe undo,redo 2 or 3 times more.. |
| 15:21:18 | raptor | then exited |
| 15:22:40 | Watusimoto | ok, only one constructor and destructor... |
| 15:27:48 | raptor | i feel your disbelief... i think |
| 15:28:46 | Watusimoto | ok, well my guess is that a database isn't being deleted |
| 15:28:57 | Watusimoto | could you try the same thing with the databases? |
| 15:28:57 | raptor | maybe a problem is gridDB.cpp:689 |
| 15:29:10 | raptor | there's an if statement there |
| 15:29:21 | raptor | it should probably do a delete in an else block? |
| 15:29:22 | Watusimoto | void DatabaseObject::addToDatabase(GridDatabase *database) ?? |
| 15:29:37 | raptor | what happens when the if statement fails? |
| 15:29:38 | Watusimoto | no I don't think so |
| 15:29:55 | Watusimoto | item is not added to database |
| 15:30:03 | Watusimoto | but what is not databasable/ |
| 15:30:04 | Watusimoto | > |
| 15:30:06 | Watusimoto | ? |
| 15:30:08 | Watusimoto | there we go! |
| 15:30:18 | Watusimoto | mostly things like gameTypes and the like |
| 15:30:29 | Watusimoto | if we delete those... well kapow! |
| 15:30:57 | raptor | yes, i see your point |
| 15:31:14 | raptor | ok, counter in databases... |
| 15:31:24 | raptor | where would i put that? |
| 15:32:32 | raptor | hmm, already a counter in the constructor/destructor... |
| 15:32:38 | raptor | maybe i'll just logprint that.. |
| 15:34:31 | raptor | Watusimoto: results: http://pastie.org/5427912 |
| 15:35:15 | Watusimoto | ok, well, there is our problem |
| 15:35:32 | Watusimoto | do the databases have any sort of unique id we could print? figure out which are not being deleted? |
| 15:35:39 | raptor | hmmm |
| 15:35:45 | Watusimoto | 17 databases?!??!? |
| 15:35:58 | Watusimoto | when I started on bf, there was just 1 |
| 15:36:02 | raptor | yeah, so i put the logprint in the destructor |
| 15:36:06 | raptor | then |
| 15:36:10 | raptor | i loaded the level |
| 15:36:12 | raptor | no print yet |
| 15:36:19 | raptor | i did one resize, no print |
| 15:36:27 | raptor | undo: it printed 17, 16, 15 |
| 15:36:53 | raptor | then it didn't print any more no matter how may redo / undos i did |
| 15:37:10 | raptor | then it printed 14... 3 when i exited the game (not the editor) |
| 15:37:32 | Watusimoto | ok, well it's somthing to look into, but not really a serious problem, probably |
| 15:38:03 | Watusimoto | meanwhile, I may have fixed the crash |
| 15:38:09 | Watusimoto | but only via bad means |
| 15:38:14 | Watusimoto | but maybe its a clue |
| 15:41:47 | Watusimoto | ok, for my next test, I probably need to get the database issue sorted |
| 15:41:55 | Watusimoto | are you doing anything on that at the moment? |
| 15:48:32 | raptor | i'm trying to print a runtime stacktrace of each database construction.. |
| 15:49:23 | Watusimoto | ok, I'm trying a different approach |
| 15:49:42 | Watusimoto | I've assiegned each a unique id, so we can see which don't get destructed |
| 15:49:49 | raptor | ahh... |
| 15:54:04 | Watusimoto | first and second created are never deleted |
| 15:54:14 | Watusimoto | so which are those? |
| 15:55:13 | raptor | heh |
| 15:58:35 | Watusimoto | first 3, actually |
| 15:58:50 | Watusimoto | mWallSegmentDatabase = new GridDatabase(false); |
| 15:58:50 | Watusimoto | mWallEdgeDatabase = new GridDatabase(false); |
| 15:58:53 | Watusimoto | those are two |
| 15:59:06 | Watusimoto | even though I see them deleted down below |
| 15:59:57 | Watusimoto | and this oen |
| 15:59:58 | Watusimoto | static GridDatabase mBotZoneDatabase; |
| 16:00:09 | Watusimoto | which should be deleted automatically, as it is a reference |
| 16:01:24 | Watusimoto | odd |
| 16:01:41 | Watusimoto | delete mWallSegmentDatabase; gets called, but I can't step into it, and it looks like th destructor isn't being run |
| 16:05:42 | raptor | ha! it works! |
| 16:05:45 | raptor | want traces? |
| 16:06:55 | Watusimoto | ah, ok |
| 16:07:00 | Watusimoto | I got it figured out |
| 16:07:04 | Watusimoto | sorry :-) |
| 16:07:16 | raptor | rats |
| 16:07:17 | Watusimoto | ok, so it's the mBotZoneDatabase |
| 16:07:57 | Watusimoto | the constructor in there creates a wallsegmentmanager, which creates two further databases |
| 16:08:12 | Watusimoto | since mBotZoneDatabase isn't being deleted, neither are its children |
| 16:08:20 | Watusimoto | so this is an utter non-issue |
| 16:08:30 | Watusimoto | as the lifetime of that object is an entire game |
| 16:08:43 | raptor | ok, |
| 16:09:06 | raptor | if you've fixed it, i can run another valgrind against it just to compare |
| 16:09:10 | Watusimoto | the only question is... why or how are edges/segments getting in that database |
| 16:09:25 | Watusimoto | technically, I'm not sure it needs fiixing, but I probably should anyway |
| 16:09:37 | Watusimoto | as it's rathr easy |
| 16:14:47 | raptor | please do :) |
| 16:18:13 | Watusimoto | ok, I've added a slightly klunky pair of methods to create and delete the database from the game init code |
| 16:18:19 | Watusimoto | just testing to make sure it works |
| 16:18:26 | Watusimoto | then I'll check in for a valgrind run |
| 16:18:29 | raptor | ok |
| 16:26:18 | | koda has joined |
| 16:26:56 | koda | lo |
| 16:28:25 | raptor | hi |
| 16:28:36 | koda | hi raptor |
| 16:28:57 | raptor | Watusimoto: Linux and Mac packaging changes are pretty much complete as of yesterday |
| 16:29:00 | koda | hey Watusimoto in the did you submit any gci task? |
| 16:29:38 | Watusimoto | ah... no I didn't |
| 16:30:06 | Watusimoto | I asked Arc about it, and didn;t get a response, then I left for my trip |
| 16:30:13 | Watusimoto | and it completely dropped from my mind |
| 16:30:25 | koda | ack |
| 16:30:36 | koda | well you are still on time if you like |
| 16:30:44 | Watusimoto | so I do have a probably good task, which would be easy enough to write up |
| 16:31:27 | | koda nods |
| 16:32:07 | sam686 | I hate abbreviation, searching for GCI only gives be several things completely different. |
| 16:33:31 | Watusimoto | hi sam686 |
| 16:35:49 | raptor | hi sam686 |
| 16:37:06 | sam686 | Thousands of memory leaks: http://sam6.25u.com/upload/bitfighter_visual_leak_detector.log |
| 16:38:39 | raptor | that log is huge! |
| 16:39:03 | Watusimoto | ok, made the database be deleted |
| 16:40:15 | raptor | i can run valgrind as soon as you push.. |
| 16:41:48 | Watusimoto | mergng |
| 16:42:35 | | BFLogBot Commit: 44a2aced3cc5 | Author: watusimoto | Message: Test build, with all sorts of debugging code include. Checking in so raptor can test again with valgrind. |
| 16:42:37 | | BFLogBot Commit: a6286b687e71 | Author: watusimoto | Message: Merge |
| 16:43:46 | Watusimoto | ok, turning this machine over to the kids for a bit |
| 16:43:48 | Watusimoto | back later |
| 16:44:11 | Watusimoto | btw, this build does not crash |
| 16:44:25 | Watusimoto | I'd be very interested to see if my fix makes it leak |
| 16:44:29 | Watusimoto | as I suspect it will |
| 16:44:43 | Watusimoto | but if not, that will be an important clue, alsmost certainly signifying a double delete |
| 16:45:06 | Watusimoto | in fact, if you still have your edge/segment counting code in, it would be great if you wuold test with that again, too. |
| 16:45:08 | Watusimoto | ok, back later |
| 16:46:18 | raptor | okey ok |
| 16:46:25 | raptor | i'll do it all |
| 16:54:41 | | BFLogBot Commit: 53376128be15 | Author: buckyballreaction | Message: Add dummy checkHeap() to TNL for Linux/Mac |
| 16:58:39 | raptor | Watusimoto: new leak check: http://sam6.25u.com/upload/memcheck-018-after-database-cleanup.log.zip |
| 16:58:48 | raptor | now for the segment counting... |
| 17:03:06 | raptor | Watusimoto: interesting output: http://pastie.org/5428226 |
| 17:03:16 | raptor | my counter went back to zero, which is good |
| 17:03:24 | raptor | not sure how to interpret your debug stuff.. |
| 17:22:49 | | BFLogBot Commit: 86ef0c69975c | Author: buckyballreaction | Message: Initialize some buffers to quiet valgrind |
| 17:41:18 | | BFLogBot Commit: 629da5af033c | Author: buckyballreaction | Message: Fix another memory leak. Go valgrind! |
| 17:53:51 | raptor | here's the latest after my latest commits: http://sam6.25u.com/upload/memcheck-018-after-more-cleanup.log.zip |
| 17:57:16 | raptor | There are a few other SDL leaks that are specific to SDL 1.2 - so I'm going to ignore them.. |
| 17:58:44 | | Watusimoto Quit (Ping timeout: 264 seconds) |
| 18:06:45 | | BFLogBot Commit: 518f029e0f41 | Author: buckyballreaction | Message: Allow a '.standalone' file in the installed data directory specify that it is a standalone installation |
| 18:41:27 | | BFLogBot Commit: 759a78fe7e86 | Author: buckyballreaction | Message: Determine executable directory on each platform and change to that instead upon program launch. Should aid with detecting standalone a little better. |
| 18:48:46 | | BFLogBot Commit: 2025a1b175f0 | Author: buckyballreaction | Message: Forgot the Xcode pieces... |
| 19:00:50 | | Watusimoto has joined |
| 19:07:54 | Watusimoto | ok, reviewd the valgrind stuff |
| 19:08:00 | raptor | looks much better |
| 19:08:09 | Watusimoto | looks like we're in the clear memory leak wise |
| 19:08:14 | raptor | yes |
| 19:08:21 | Watusimoto | so now I ned to figure out why there isn;t a leak |
| 19:08:28 | Watusimoto | as I expected there to be one |
| 19:08:42 | Watusimoto | unless we were doing a double delete |
| 19:08:47 | Watusimoto | and I just removed one of them |
| 19:08:57 | Watusimoto | thanks for valgrinding away! |
| 19:08:59 | raptor | sure |
| 19:09:13 | raptor | actually i'm glad i did - made me more confident in memory debugging |
| 19:09:15 | Watusimoto | so what I was printing was the id of each database as it was deleted |
| 19:09:20 | raptor | ok |
| 19:09:32 | Watusimoto | so no gaps in the numbering suggests all being deleted |
| 19:20:26 | raptor | so did you basically revert the construction adding/removing? |
| 19:20:45 | raptor | back to the old method of manually calling it afterwards, it looks like |
| 19:22:51 | Watusimoto | what do you mean by the the construction adding/removing? |
| 19:22:59 | Watusimoto | you mean adding to the db during construction? |
| 19:23:17 | Watusimoto | I did that for wallEdges, at least, because I thought it was clearer what was happening |
| 19:23:38 | Watusimoto | for wallSegements, it would have produced a bit of repeated code, so I added comments instead |
| 19:24:43 | Watusimoto | odd |
| 19:25:01 | Watusimoto | I put a breakpoint in WallSegment::~WallSegment() and it never got called |
| 19:25:08 | Watusimoto | very odd |
| 19:25:13 | Watusimoto | but no memory leaks |
| 19:25:23 | raptor | oh, i didn't do wallsegments in my counter - just the edges... |
| 19:25:41 | Watusimoto | segments are the problem, I think |
| 19:26:04 | Watusimoto | search for this: |
| 19:26:05 | Watusimoto | for(U32 i = 0; i < mAllObjects.size(); i++) // Always crashes with type number 32, WallSegment |
| 19:26:17 | Watusimoto | in gridDb line 181 |
| 19:26:36 | Watusimoto | you'll see the crapola I used to fix the crash |
| 19:26:42 | Watusimoto | I added the if(xxx) bit |
| 19:26:47 | Watusimoto | and voila... no more crash |
| 19:27:49 | Watusimoto | so I just started the editor, added a U shaped wall, then quit |
| 19:28:00 | Watusimoto | 3 wall segments were creaetd, destructor was never called |
| 19:28:36 | Watusimoto | but why didn;t you see a memory leak? oh, probably because the memory wasn;t lost; it could have been deleted at any time |
| 19:28:43 | Watusimoto | no, that;s not true |
| 19:28:49 | Watusimoto | there was a memory leak |
| 19:28:51 | raptor | ok, my counter in the destructor never got called.. |
| 19:29:09 | Watusimoto | in gridDb, mAllObjects.clear(); is called for segments |
| 19:29:25 | Watusimoto | so the pointers are erased, but the objects themselves are never deleted |
| 19:29:27 | Watusimoto | wtf? |
| 19:29:36 | Watusimoto | you should haev seen memory leaks! |
| 19:29:46 | raptor | that's weird... |
| 19:29:49 | raptor | wait |
| 19:29:50 | Watusimoto | very |
| 19:29:59 | raptor | maybe that last report i didn't open up the editor... |
| 19:30:03 | raptor | let me redo it |
| 19:30:11 | Watusimoto | but when I delete those objects, I get a crash from funky memory issues |
| 19:30:24 | Watusimoto | create a wall then exit |
| 19:31:38 | raptor | that's all you want me to do? |
| 19:32:39 | Watusimoto | do at least that |
| 19:33:55 | Watusimoto | brb |
| 19:35:26 | raptor | ok Watusimoto, found a leak: http://sam6.25u.com/upload/memcheck-018-wallsegment-hunt.log.zip |
| 19:35:53 | raptor | i added a barrier, then resized everything, undo, redo, etc... , quit |
| 19:41:59 | sam686 | Looks like there is some memory leaks of DatabaseObject with type 32 (WallSegmentTypeNumber) |
| 19:44:25 | sam686 | http://sam6.25u.com/upload/visual_leak_editor_create_a_wall_then_exit2.txt - What I did is add a "TYPE" char[4] right before the type number, to easily identify some memory contents.. |
| 19:45:56 | sam686 | oh and one memory leak of type 30 (hex 0x1E) (WallItemTypeNumber)? |
| 19:51:24 | raptor | Watusimoto is working on it... |
| 19:52:43 | Watusimoto | I'm really trying to work on the memory corruption issue |
| 19:53:45 | raptor | what i think: if we're going to add stuff to the database from a constructor and delete it elsewhere, then if there is any if statement in the flow of adding it to the database, it should be properly cleaned up somehow |
| 19:53:57 | sam686 | does the memory corruption happen on non-debug compile too? |
| 19:55:32 | raptor | because when calling addToDatabase in WallSegment::init() we hit a number of if statements: if(mDatabase) return; |
| 19:55:38 | raptor | if(isDatabasable()) |
| 19:56:03 | raptor | if a new WallSegment is called, but mDatabase is NULL... memory leak! |
| 20:02:18 | sam686 | you know what? there is removeEverythingFromDatabase that DELETES objects, but there is also an individual removeFromDatabase that does not delete objects ... that may be part of memory leak |
| 20:05:04 | sam686 | before revision c000c91e9e3b, it was mostly fine, now it seem to delete when it shouldn't or don't delete when it should.. |
| 20:10:39 | sam686 | How about just don't delete from inside the "removeEverthingFromDatabase", but elsewhere? Client side of ghostable objects auto delete already.. |
| 20:13:20 | Watusimoto | sam, the question is where should those items be deleted? I can;t see how there is a double delete going on, and I can;t see what else would cause the current problems |
| 20:15:23 | Watusimoto | ok, well at least valgrind is more understandable now |
| 20:15:29 | Watusimoto | loss record 233 of 343 is what I expected |
| 20:15:38 | raptor | Watusimoto: WallSegmentManager.cpp:242 |
| 20:15:50 | raptor | that new WallSegment |
| 20:15:56 | Watusimoto | yes |
| 20:16:02 | raptor | have you tried tracking to see if they actually get added to a database? |
| 20:16:25 | Watusimoto | I'm pretty sure it does, but I haven;t done that; I can |
| 20:19:00 | Watusimoto | it does |
| 20:19:03 | Watusimoto | confirmed |
| 20:21:15 | raptor | hmm |
| 20:21:20 | raptor | well, now i'm out of ideas |
| 20:23:02 | Watusimoto | that's where I was last weekend ;-( |
| 20:24:00 | Watusimoto | my best theory is that there is something interacting with clipper |
| 20:24:06 | raptor | but hte crash is gone? |
| 20:24:17 | Watusimoto | yes, and the memory leak is in its place |
| 20:24:37 | Watusimoto | I think that clipper and something might be sharing a chunk of memory |
| 20:24:54 | sam686 | I stuck in a RtfPtr<GridDatabase> mDatabase in DatabaseObject, now I an getting "Object deleted with non-zero reference count" |
| 20:25:01 | Watusimoto | maybe a point is added somehow via pointer instead of via reference (and hence a copy) |
| 20:25:50 | sam686 | let me try SafePtr instead.. |
| 20:25:57 | raptor | looks like all clipper stuff was moved to GeomUtils |
| 20:25:59 | Watusimoto | because when I traced it earlier, it looked like it was dying on clearing a vector of points |
| 20:27:41 | raptor | mergePolys(const Vector<const Vector<Point> *> &inputPolygons |
| 20:27:43 | raptor | yuk |
| 20:28:17 | Watusimoto | I moved as much stuff as I could out of barrier to try to make it clearer what was going on. a lot ended up in mergePolys |
| 20:28:29 | Watusimoto | sorry... in geomutils |
| 20:30:44 | raptor | well, it looks like all the inputPolygons are passing through upscaleClipperPoints first |
| 20:30:51 | raptor | and everything is copied... |
| 20:31:47 | Watusimoto | now I think that theory is wrong |
| 20:32:02 | Watusimoto | argh!! |
| 20:32:44 | raptor | how did you verify that every wallsegment was being added to a database? |
| 20:35:33 | Watusimoto | it happens in the constructor |
| 20:35:38 | Watusimoto | I traced one through to verify |
| 20:36:11 | Watusimoto | plus, the crash happens when the database tries to delete the segments, and that only happens to segments in the db |
| 20:40:53 | raptor | question: if i load a level |
| 20:41:02 | raptor | are wallsegments supposed to be added to a database? |
| 20:42:41 | Watusimoto | yes |
| 20:42:45 | Watusimoto | well, sort of |
| 20:42:54 | Watusimoto | wall is added to the database |
| 20:43:01 | Watusimoto | but the database also has a wallsegmentmanagr |
| 20:43:06 | Watusimoto | that has the segments |
| 20:43:07 | Watusimoto | I think |
| 20:43:31 | Watusimoto | the idea was to keep junk like segments segregated from regular objects, keeping db access cleaner |
| 20:45:33 | Watusimoto | the WSM (wallsegmentmanager) has a database called mWallSegmentDatabase where it stores the segments |
| 20:46:14 | Watusimoto | it also has mWallEdgeDatabase for edges |
| 20:46:40 | Watusimoto | segments should only end up in mWallSegmentDatabase |
| 20:47:15 | Watusimoto | I wonder if I should enforce that somehow |
| 20:49:58 | raptor | ok i confirmed that *every* wallsegment is added to a database |
| 20:50:09 | Watusimoto | excellent! |
| 20:50:41 | raptor | so, can you give me a diff of what would remove the leak but create your crash? |
| 20:53:01 | Watusimoto | no need; one line only |
| 20:53:36 | Watusimoto | change: |
| 20:53:42 | Watusimoto | if(xxx) |
| 20:53:43 | Watusimoto | mAllObjects.deleteAndClear(); |
| 20:53:45 | Watusimoto | to |
| 20:53:47 | Watusimoto | if(true || xxx) |
| 20:53:47 | Watusimoto | mAllObjects.deleteAndClear(); |
| 20:53:51 | Watusimoto | boom |
| 20:54:02 | raptor | great! |
| 20:54:03 | raptor | thanks |
| 20:54:07 | Watusimoto | (griddb.cpp) |
| 20:55:26 | raptor | and to crash, i just resize a barrier, correct? |
| 20:57:08 | Watusimoto | I create a U shaped barrier, plunk a repair item in the U, then select the wall, ctrl-shift x to make wall 2x, then undo/redo a couple of times |
| 20:59:11 | raptor | huh |
| 20:59:23 | raptor | i found this: |
| 20:59:31 | raptor | ==13706== 424 (400 direct, 24 indirect) bytes in 1 blocks are definitely lost in loss record 248 of 338 |
| 20:59:33 | raptor | ==13706== at 0x4C2A6E7: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) |
| 20:59:34 | raptor | ==13706== by 0x644F28: Zap::RepairItem::clone() const (PickupItem.cpp:363) |
| 20:59:36 | raptor | ==13706== by 0x5F07F7: Zap::GridDatabase::copyObjects(Zap::GridDatabase const*) (gridDB.cpp:133) |
| 20:59:37 | raptor | ==13706== by 0x45EAD3: Zap::EditorUserInterface::saveUndoState(bool) (UIEditor.cpp:308) |
| 21:00:23 | Watusimoto | saw that before |
| 21:00:29 | raptor | notes? |
| 21:00:54 | Watusimoto | also crashes with asteroid/flag/resource/teleport/textitem/gofast |
| 21:01:25 | Watusimoto | but didn;t track it down further than than |
| 21:02:02 | Watusimoto | so clone does this: |
| 21:02:03 | Watusimoto | return new RepairItem(*this); |
| 21:02:11 | Watusimoto | so whatever calls clone needs to take care |
| 21:03:04 | Watusimoto | clone called when dragging item from dock |
| 21:03:20 | raptor | Zap::EditorUserInterface::scaleSelection |
| 21:03:27 | raptor | was the next line of that trace |
| 21:05:40 | Watusimoto | so the repair item created in the clone is added to a database |
| 21:08:35 | raptor | well the wallsegments still leak |
| 21:09:57 | raptor | so there are basically still two types of leaks: 1 with the clone() of each object, and one with the wall segments |
| 21:10:11 | raptor | and this since adding the true || xxx |
| 21:11:34 | Watusimoto | wall segments leak.... |
| 21:11:36 | Watusimoto | hmmm.... |
| 21:11:48 | Watusimoto | well, I left the database ids in place |
| 21:12:06 | Watusimoto | maybe you could print out which database a wallsegment is added to, and see if that db is deleted |
| 21:12:14 | Watusimoto | though we already know it is |
| 21:12:28 | Watusimoto | so i'm not sure what that would accomplish, actually |
| 21:12:37 | raptor | what do each of these mean: |
| 21:12:38 | raptor | gridDb: 2, 0xfe0dd60, 31 |
| 21:13:14 | Watusimoto | oh, those |
| 21:13:16 | Watusimoto | ok |
| 21:13:24 | Watusimoto | gridDb reminds me where to delete the line |
| 21:13:31 | Watusimoto | (which I've done on my own copy now) |
| 21:13:35 | | LordDVG Quit (Remote host closed the connection) |
| 21:13:53 | Watusimoto | 0x... is the address of teh segment |
| 21:14:14 | Watusimoto | I think I was dumping the addrs of all teh segments before deleting |
| 21:14:25 | Watusimoto | 2 would be the 2nd item in the database |
| 21:14:34 | Watusimoto | and 31 is the objecttypenumber of that obj |
| 21:14:40 | raptor | ahh |
| 21:14:43 | Watusimoto | 31 = wall edge, 32 = wall segment, I think |
| 21:15:12 | Watusimoto | I concluded it always crashed when deleting type 32, hence my xxx check |
| 21:15:42 | Watusimoto | with my U walls, there are always 3 segments |
| 21:16:06 | Watusimoto | it crashes inside this loop: |
| 21:16:07 | Watusimoto | for(U32 i = 0; i < this->innerVector.size(); i++) |
| 21:16:07 | Watusimoto | delete this->innerVector[i]; |
| 21:16:17 | Watusimoto | inside Vector<T>::deleteAndClear() |
| 21:16:25 | Watusimoto | and always when i == 2 |
| 21:17:32 | Watusimoto | and that called from here: |
| 21:17:33 | Watusimoto | if(true || xxx) |
| 21:17:33 | Watusimoto | mAllObjects.deleteAndClear(); |
| 21:18:05 | Watusimoto | that's where the idea of the xxx thing came from |
| 21:18:12 | Watusimoto | which seems to fix the crashes |
| 21:29:12 | raptor | here are the relevant leaks: http://pastie.org/5429090 |
| 21:29:24 | raptor | i think if we fix them (somehow) then things may work better... |
| 21:30:28 | raptor | so all the clone()'s are called from Zap::GridDatabase::copyObjects( |
| 21:31:32 | Watusimoto | void GridDatabase::copyObjects(const GridDatabase *source) |
| 21:31:32 | Watusimoto | { |
| 21:31:32 | Watusimoto | // Fill copy with objects from existing database |
| 21:31:32 | Watusimoto | mAllObjects.reserve(source->mAllObjects.size()); |
| 21:31:32 | Watusimoto | for(S32 i = 0; i < source->mAllObjects.size(); i++) |
| 21:31:34 | Watusimoto | addToDatabase(source->mAllObjects[i]->clone(), source->mAllObjects[i]->getExtent()); |
| 21:31:36 | Watusimoto | sortObjects(mAllObjects); |
| 21:31:38 | Watusimoto | } |
| 21:31:54 | Watusimoto | are they not all added to a database? |
| 21:32:07 | raptor | the for loop |
| 21:32:11 | raptor | added to the same database? |
| 21:33:08 | Watusimoto | added to the "this" database |
| 21:33:33 | Watusimoto | though it hardly matters -- databases take care of their objects, and all databases are accounted for |
| 21:34:27 | raptor | isn't clone() already exist for any c++ object? |
| 21:34:42 | Watusimoto | but if you doubted that, you could print the database' id, then dump ides of the destructors as the dbs are closed down |
| 21:35:01 | Watusimoto | clone()? no |
| 21:39:14 | Watusimoto | you know.. |
| 21:39:34 | Watusimoto | wallSegements seem to have null geometry |
| 21:39:41 | Watusimoto | I wonder if that is the problem |
| 21:42:40 | Watusimoto | I'll set the geom of a segment and see if that fixes anything |
| 21:46:55 | Watusimoto | nope |
| 21:49:21 | Watusimoto | trying an unrelated, random fix... hasn;t crashed 2x in a row |
| 21:49:47 | Watusimoto | 3x |
| 21:50:25 | Watusimoto | 4x |
| 21:51:03 | Watusimoto | 5x |
| 21:51:06 | Watusimoto | maybe this is it |
| 21:51:33 | Watusimoto | took out onMouseMoved(); in UIEditor redo() |
| 21:51:44 | raptor | what |
| 21:53:01 | Watusimoto | didn't crash 5x in a row |
| 21:53:10 | Watusimoto | that's all I've got right now |
| 21:53:39 | raptor | there was this in valgrind that i didn't paya ttention to: |
| 21:53:48 | raptor | ==13706== Conditional jump or move depends on uninitialised value(s) |
| 21:53:49 | raptor | ==13706== at 0x46851B: Zap::EditorUserInterface::onMouseMoved() (UIEditor.cpp:2779) |
| 21:54:50 | raptor | wait |
| 21:55:06 | raptor | that just comes from normal mouse movement in Event::onMouseMoved |
| 21:58:04 | Watusimoto | maybe that explains the random crash I saw in setCursor |
| 21:59:16 | raptor | now this is interesting (i've been tracking down the clone() leaks): http://pastie.org/5429196 |
| 21:59:35 | raptor | there is a copy to database 14, but no output from removeEverythingInDatabase() |
| 22:03:18 | Watusimoto | eh? |
| 22:03:30 | Watusimoto | I see copy to 14 |
| 22:03:35 | raptor | yes |
| 22:03:46 | raptor | but do you see debug output from it? |
| 22:03:53 | Watusimoto | ah, you've modified my debug code |
| 22:03:58 | Watusimoto | where would I see it? |
| 22:03:59 | raptor | i altered the dbeug... yes |
| 22:04:13 | Watusimoto | is that first param a db number? |
| 22:04:13 | raptor | seee copy from: 11 to: 17 |
| 22:04:26 | raptor | then lower down gridDb: 17, 0, 0x2ee04d0, 21 |
| 22:04:34 | raptor | the first number is the database ID |
| 22:04:50 | raptor | second is object count, last is type number |
| 22:04:54 | Watusimoto | ok |
| 22:05:01 | Watusimoto | yes, I see that |
| 22:05:11 | raptor | but it doesn't exist for database with id 14 |
| 22:05:20 | raptor | which would explain the leaks for the 4 objects... |
| 22:05:59 | Watusimoto | and yet db 14 is deleted |
| 22:06:03 | raptor | yes |
| 22:06:05 | raptor | so |
| 22:06:10 | raptor | it isn't being added? |
| 22:06:32 | Watusimoto | uh... I think it has to be |
| 22:06:39 | Watusimoto | what do you do to add it? |
| 22:06:42 | Watusimoto | drag item off dock? |
| 22:06:52 | raptor | i'm just rescaling, undo, redo, etc |
| 22:07:03 | raptor | and that method copyObjects is called |
| 22:07:10 | raptor | but it failed in one instance.. |
| 22:07:10 | Watusimoto | from saved level? |
| 22:07:12 | raptor | yes |
| 22:07:25 | Watusimoto | you know, all my crashes are when I start with blank canvas |
| 22:07:35 | raptor | what! |
| 22:07:45 | Watusimoto | haven't tried a saved level |
| 22:07:54 | raptor | i saved a u-shaped level with a repair item to test... |
| 22:07:59 | Watusimoto | ah |
| 22:08:06 | Watusimoto | I recreated every time |
| 22:08:24 | Watusimoto | try from scratch a few times |
| 22:09:01 | raptor | ok |
| 22:10:38 | raptor | hmm didn't crash once.. |
| 22:12:00 | raptor | still no crash... |
| 22:13:25 | raptor | and again, no crash |
| 22:13:33 | raptor | but same missing cleanup of a database.. |
| 22:20:59 | Watusimoto | maybe it's this line: |
| 22:20:59 | Watusimoto | findSnapVertex(); |
| 22:21:29 | raptor | ummm |
| 22:21:31 | raptor | hmmm |
| 22:21:39 | raptor | actually |
| 22:22:23 | raptor | it looks like items are being deleted from multiple databases, but i need to confirm somehow.. |
| 22:22:23 | Watusimoto | why? no idea. not even sure it's the problm. but it seems to not crash when that line is omitted from redo |
| 22:23:28 | Watusimoto | trying to home in further |
| 22:24:57 | raptor | question |
| 22:25:55 | raptor | can the same obejct be in more than one database at once? |
| 22:26:29 | raptor | because: http://pastie.org/5429310 |
| 22:26:36 | raptor | follow #14 |
| 22:26:38 | raptor | db 14 |
| 22:33:34 | raptor | time to track object pointers... |
| 22:43:28 | raptor | Watusimoto: found the leak for clone() objects |
| 22:43:35 | raptor | i'm not sure what to do about it |
| 22:44:21 | raptor | a different removeFromDatabase is being called on the objects: http://pastie.org/5429357 |
| 22:44:50 | raptor | and in that one there is no delete anywhere |
| 22:45:53 | raptor | would you understand why this is being called from cleanUp() in the UIEditor before the destructor can properly handle it? |
| 22:55:07 | Watusimoto | good! |
| 22:55:14 | Watusimoto | let me look |
| 22:57:53 | raptor | oh, and look at that, the same removeFromDatabase() with no delete is being called from the WallSegment destructor! |
| 22:58:06 | raptor | that must be our memory leak, too |
| 22:59:26 | raptor | oh wow, it's called from several spots |
| 23:01:33 | Watusimoto | would you understand why this is being called from cleanUp() in the UIEditor before the destructor can properly handle it? |
| 23:01:35 | Watusimoto | no |
| 23:01:55 | raptor | so that removeFromDatabase() method is called from many places |
| 23:02:03 | raptor | and there is no delete in it.. |
| 23:03:34 | Watusimoto | the clearDatabase(mLoadTarget); method must be trying to free up some memory, in case you are quitting to play or something |
| 23:04:28 | Watusimoto | probably that clearDatabase should become a removeEverythingFromDatabase like call |
| 23:05:31 | Watusimoto | removeFromDatabase() --> mAllObjects.erase(i) should probably be deleteAndErase |
| 23:05:39 | Watusimoto | that's likely the memory leak |
| 23:05:54 | raptor | well, that is what is being called in the destructor of wallsegment |
| 23:06:07 | Watusimoto | ok. |
| 23:06:24 | Watusimoto | change it to deleteAndErase and see if the leak goes awat |
| 23:06:26 | | amgine1234567890 has joined |
| 23:06:28 | raptor | ok |
| 23:06:37 | amgine1234567890 | hi |
| 23:06:45 | raptor | i'm worried though, that method is called from lots of places |
| 23:06:56 | amgine1234567890 | so hany luck on the recalse crash bug |
| 23:07:14 | Watusimoto | not much |
| 23:07:18 | Watusimoto | just lots of frsutration! |
| 23:07:20 | raptor | hi amgine1234567890, still working on it |
| 23:07:50 | raptor | also amgine1234567890, i deleted your post in announcements about upcoming 018 - i'd rather the actual announcement be made when it's really time |
| 23:11:22 | raptor | leak gone! |
| 23:11:32 | raptor | Watusimoto: try that simple change and see if it crashes... |
| 23:11:56 | Watusimoto | erase to deleteAndErase? |
| 23:12:05 | raptor | yes |
| 23:12:08 | Watusimoto | done |
| 23:12:08 | raptor | in that one method |
| 23:12:09 | Watusimoto | crash |
| 23:12:30 | raptor | yay wild goose found, now onto the real chase! |
| 23:12:47 | Watusimoto | but if the memory leak gets fixed, that;s progress |
| 23:12:52 | raptor | yes |
| 23:12:56 | raptor | want me to commit it? |
| 23:13:01 | Watusimoto | sure |
| 23:15:52 | | CrazyLinuxNerd Quit (Quit: Leaving) |
| 23:16:06 | | BFLogBot Commit: 3032471fd8ef | Author: buckyballreaction | Message: Finally fix the remaining memory leaks with the GridDatabase |
| 23:16:08 | raptor | ok done |
| 23:16:13 | | CrazyLinuxNerd has joined |
| 23:16:15 | amgine1234567890 | olnce you solve teh bug do you want me to do once last sweep for bugs or will we publish it soon |
| 23:16:42 | amgine1234567890 | lol i need to stop finding bugs or BF18 will never come out Xd |
| 23:19:01 | raptor | sam686: memory leaks are fixed now, but Watusimoto still gets the crash; do you? |
| 23:30:05 | amgine1234567890 | hmm the rescle worked in the ealer verison but couldnt unout numbers maybe backtrack to that one and try somthing different? |
| 23:41:24 | amgine1234567890 | btw would it be possilbe to add 2 new game play modes by verion 20 |
| 23:44:28 | Watusimoto | ok, I am having difficulty crashing when I load a level; only seems to work when I start a new one |
| 23:44:40 | Watusimoto | wonder if the act of dragging an item from the dock is related? |
| 23:45:55 | raptor | ok, let me try that.. |
| 23:46:46 | raptor | well, here is the full trace on that valgrind error: http://pastie.org/5429508 |
| 23:51:07 | raptor | oooo |
| 23:51:50 | raptor | Watusimoto: i did a bunch of various editor actions with valgrind, and i found these: http://pastie.org/5429525 |
| 23:53:41 | Watusimoto | those look bad |
| 23:53:57 | Watusimoto | is the text color yours, or just pastie? |
| 23:54:01 | raptor | pastie |
| 23:54:09 | raptor | i chose c++ highlighting |