#bitfighter IRC Log

IRC Log for 2013-06-23

Timestamps are in GMT/BST.

00:53:48 Watusimoto has joined
01:07:25 bobdaduck Quit (Remote host closed the connection)
05:39:25 Watusimoto funny... I updated and got a whole log of recompiling...
05:40:07 BFLogBot Commit: 57602b0acc91 | Author: watusimoto  | Message: Found the path forward for ClientGame in our test rig.  Needs further refinement, but we can now build tests using ClientGame. 
05:40:09 BFLogBot Commit: 81ca449a2591 | Author: watusimoto  | Message: Merge 
05:40:10 BFLogBot Commit: 91e94874948a | Author: watusimoto  | Message: Clean up our ClientGame-in-test solution a little 
06:38:19 ozbitfighter has joined
07:27:40 BFLogBot Commit: 15a144f8e2ad | Author: watusimoto  | Message: Comments 
07:27:42 BFLogBot Commit: a580ef1654e7 | Author: watusimoto  | Message: Add assert that identifies source of our editor crash 
07:27:43 BFLogBot Commit: 861d2e0905c0 | Author: watusimoto  | Message: Fix crash in editor.  Not sure why this worked at all in Linux... but hey, it's a magical operating system! 
07:27:45 BFLogBot Commit: 88a6775c2bf3 | Author: watusimoto  | Message: Rename kind of useless test, leaving a little nub in place to help guide the way for ClientGame testing 
08:13:02 Watusimoto Quit (Remote host closed the connection)
08:25:38 ozbitfighter Quit (Quit: Page closed)
09:19:35 Watusimoto has joined
09:42:20 BFLogBot Commit: 2b1589fe0da8 | Author: watusimoto  | Message: Totally unnecessary fix: manually delete menu items when we close a QuickMenu.  This does have the advantage of reclaiming a tiny amount of memory that would otherwise be tied up in some useless menu items until the next menu was created. 
09:42:22 BFLogBot Commit: ac9c2d224618 | Author: watusimoto  | Message: Whitespace 
09:45:59 BFLogBot Commit: 74b113ffea30 | Author: watusimoto  | Message: Whitespace 
09:51:44 SolumnMushroom has joined
10:03:27 Watusimoto Quit (Remote host closed the connection)
10:04:23 BFLogBot Commit: 58323acd2cd7 | Author: watusimoto  | Message: Show joystick control help when in joystick mode 
10:26:27 bobdaduck has joined
10:55:06 Watusimoto has joined
11:33:25 Watusimoto Quit (Ping timeout: 255 seconds)
12:07:08 bobdaduck Quit (Remote host closed the connection)
12:15:11 Watusimoto has joined
12:18:31 raptor has joined
12:18:31 ChanServ sets mode +o raptor
12:19:17 raptor hello!
12:19:55 raptor let it me known that the editor crash (according to your assert) was not my code...  :)
12:20:37 raptor but i'm sure my changes exacerbated the problem..
12:22:58 raptor there, i got my very intricate and important commit done for the day
12:23:49 BFLogBot Commit: 780e24055199 | Author: buckyballreaction | Message: Spelling 
12:35:53 raptor Watusimoto: I know this is crazy, but the memory leak is still there, even after your changes...
12:38:30 raptor here are our current memory leaks (and 1 error - the invalid write - ignore this for now):  http://pastie.org/pastes/8072733/text
12:41:38 Watusimoto hi
12:41:45 raptor hi
12:42:13 Watusimoto I don't think there is a memory leak
12:42:32 Watusimoto at least not in the menuitems code
12:42:35 raptor that report is from valgrind i just ran on a clean compile of latest
12:42:58 Watusimoto are you refering to the last section?
12:43:04 Watusimoto the ToggleMenuItems
12:43:15 raptor all three of the last that have LuaW in them
12:43:21 Watusimoto oh, there are teh CounterMenuItems as well
12:43:26 raptor the last 3 sections, i mean
12:43:36 Watusimoto I only tested using the curve tool; is that sufficient to reproduce?
12:43:39 raptor i think one is a subclass of the other...
12:43:41 raptor yes
12:43:47 raptor even jsut opening/closing the curve tool
12:43:47 Watusimoto ok
12:43:59 Watusimoto yes, that is enough to create the menu items
12:44:16 raptor that invalid write has something to do with LuaW...  which I'm tracking down..
12:44:20 Watusimoto but when I put a breakpoint in the CounterMenuitem destructor, I see them destructing just as I would expect
12:44:32 raptor maybe more than one is being created?
12:44:59 Watusimoto I have not done this, but I would assert that if you put a counter in during construction, and decremented it during desstruction, you would be at 0 after each menu close
12:45:23 raptor i can test that real fast...
12:45:55 Watusimoto go for it.  I have done it manually, so am confident of the result
12:46:04 Watusimoto I did it a while ago, and again today
12:46:11 Watusimoto both before and after my code modifications
12:46:21 Watusimoto and all those modifications changed was the timing
12:46:38 Watusimoto (admittedly for the better)
12:47:13 raptor putting the static counter in both constructors of CounterMenuItem
12:49:36 raptor ok, i have 11 constructor hits when i get to the editor...
12:49:48 raptor run plugin, up to 18
12:50:10 raptor close window...  back to 11
12:50:23 raptor huh
12:51:19 raptor maybe...  it has something else to do with the plugin system?
12:55:50 Watusimoto yeah, maybe
12:57:11 raptor that invalid write...
12:57:19 raptor hmm
12:59:44 raptor moral of the day - don't feed a brownie to a 1.8-year-old
13:03:45 raptor hmm...  the invalid write only happens when you 'undo' a created barrier with a plugin
13:03:55 raptor (or loadoutzone)
13:18:28 raptor i keep thinking we should work to get rid of our proxies somehow
13:18:36 raptor then I keep finding evidence that they're needed..
13:22:13 Watusimoto I don't think we can get rid fo them
13:26:37 Watusimoto that valgrind item seems to clearly show that the item at issue is the ToggleMenuItem.  It points to line 92, where the item is new'ed
13:28:01 Watusimoto I don't see any way for the constructor iteself to be leaking
13:29:00 raptor new clue:  no matter how many different plugins i run, or how many times i open them, i get those same 3 blocks only on exit
13:29:09 raptor in the valgrind report
13:29:24 Watusimoto I remain unconvinced it's an actual leak
13:29:47 raptor I'm starting to think that myself...
13:29:51 kaen I remember some wonkiness with toggle items when I was writing those plugins
13:30:13 Watusimoto try it in release mode?
13:30:16 kaen specifically the game would crash when opening a plugin menu with a toggle item multiple times
13:30:46 kaen but that was before all of this lua work so I don't know if it's relevant anymore
13:30:47 raptor oh yeah..  i remember that.  in fact, didn't i fix that?
13:30:56 kaen quite possible
13:31:07 Watusimoto from the valgrind docs
13:31:09 Watusimoto When fixing errors, it is a good idea to start at the top; fixing an error that occurs earlier is likely to eliminate a lot of later errors as well.
13:31:09 Watusimoto Once in a great while you may encounter a false positive -- an error even though there is nothing wrong with your program. However, in the vast majority of cases, any error reported is real and you should fix it. Be very wary about dismissing an error as a "false positive," since it is much more likely that you have made a mistake.
13:32:42 Watusimoto since we aer seeing reports in a number of different menu items, the problem (if it exists) is probably with a common anscestor
13:33:15 raptor so if i discover a bool has value of '48', something is wrong?
13:34:11 raptor that invalid write is occurring like so:  1.  run plugin  2. undo wall created 3. shutdown
13:34:40 raptor and on undo, the wall is removed from the database (and destructor hit), but on shutdown, it is being hit again
13:34:47 raptor anyone have an idea as to why?
13:36:53 Watusimoto where do you get the 48?
13:36:58 Watusimoto that's clearly a bug
13:37:02 Watusimoto it should be 42
13:39:42 raptor ha
13:40:04 raptor the WallItem (or LoadoutZone, whatever) is destructing twice
13:40:21 raptor once with the 'undo' after plugin run, once when closing the game
13:46:29 raptor there is a bug somewhere between these two traces:  http://pastie.org/pastes/8072867/text
13:46:38 raptor the destructor should only be called once, right?
13:53:02 raptor oops, i meant these:  http://pastie.org/pastes/8072884/text
13:56:37 raptor Watusimoto: in UIEditor.cpp:169, do you know why this boost::dynamic_pointer_cast class was used?:   mEditorDatabase = boost::dynamic_pointer_cast<GridDatabase>(database);
13:57:42 Watusimoto no, I don't know
13:58:03 raptor because that line is calling the destructor for the objects..
13:59:11 raptor whihc makes sense, but there is still a pointer to the object when we close the editor
14:02:47 raptor we have multiple GridDatabases with the undo system, each wrapped in a shared_ptr..  ohhhh
14:02:59 Watusimoto I can't even find any docs about what dynamic_pointer_cast is suppsed to do
14:03:09 Watusimoto yes
14:03:13 raptor the GridDatabases themselves hold pointers to objects, yes?
14:03:15 Watusimoto it was a very lazy way to do undo
14:03:21 Watusimoto yes
14:03:41 raptor what happens if two GridDB hold the same pointer to an object?  and they both are destructed?
14:03:54 Watusimoto I do have a design for a much more compact and efficient undo system
14:04:02 Watusimoto they don't
14:04:12 Watusimoto they hold pointers to copies of objects
14:04:21 raptor well...  in this case they don't
14:04:21 Watusimoto when you copy a database, everything inside gets copied as well
14:04:25 raptor heh
14:04:28 raptor not happening!
14:04:41 Watusimoto no?
14:04:46 raptor the *exact* same object is being deleted from two databases
14:05:10 Watusimoto well, that could be a problem
14:05:54 raptor yes - granted the second delete is only happening when we shut down
14:06:37 raptor were is this database copy supposedly happening?
14:08:32 Watusimoto probably in the undo sectino of the editor
14:08:44 Watusimoto that's the only reason we copy databases, to give us an undo capacity
14:09:08 raptor oh interesting...   i just got the menu item leaks without running a plugin
14:10:23 raptor twinkies are coming back!
14:16:52 raptor i think menu items are leaking when running plugin.runGetArgsMenu  to fill up kaen's plugin dock
14:21:02 raptor maybe it's a bad plugin of mine?
14:23:17 Watusimoto plugins shouldn't be able to be bad... unless they create a menu item they never add to a menu
14:23:24 Watusimoto in which case... naughty!
14:23:37 raptor yes...  i just checked that and all of mine are added in a menu..
14:23:54 Watusimoto try removing all your plugins and see if that fixes the problem
14:24:38 raptor i'm bisecting it
14:24:40 raptor ha
14:24:41 raptor ok
14:24:43 raptor so
14:24:58 raptor any menuitem you instantiate in a plugin
14:25:09 raptor leave behind *one* of its kind as a leak
14:25:26 raptor so if i have 2 plugins, each with 5 ToggleMenuItems
14:25:32 raptor one TMI is leaking
14:26:08 raptor but if I have  5,4,3,  of Toggle, Counter, YesNo;  it leaves behind 1 of each as a leak
14:26:17 raptor across all scripts
14:27:08 Watusimoto off-by-one bug?
14:27:33 raptor perhaps...   looking deeper - all these are being called in EditorUserInterface::findPlugins()
14:27:35 Watusimoto or maybe it creates an extra item somehow that never gets added anywhere?
14:27:42 raptor that could be, too..
14:29:09 raptor uh oh... we're using a Vector<MenuItem*> menu;
14:29:47 raptor let me convert that to a shared_ptr...
14:29:56 Watusimoto ah, maybe that's it
14:30:07 Watusimoto good catch -- I read right past that
14:31:02 raptor yep..  i see it being created, but not cleaned up..
14:32:39 raptor ah...  ok, when a plugin is run, it is actually added to a menu which keeps track of them with a shared_ptr
14:33:10 raptor but on start up, when the plugin is run to grab information, the menuitems are not added anywhere...
14:33:58 Watusimoto ah, interesting
14:34:05 Watusimoto so those ones are never cleaned up
14:34:10 raptor correct
14:34:17 Watusimoto maybe create them as shared_ptrs from the outset?
14:34:47 raptor i'm thinking that, too
14:35:02 Watusimoto we might as well... then we don't need to worry about them
14:45:58 raptor is there a difference between shared_ptr<MenuItem*> and shared_ptr<MenuItem> ?
14:46:05 raptor i mean at the implementation level?
14:46:29 Watusimoto Quit (Read error: Connection reset by peer)
14:48:09 Watusimoto has joined
14:50:35 raptor testing fix..
14:51:52 raptor ladies and gentlemen, the leak is fixed!
14:55:00 BFLogBot Commit: c86f18f1d2c0 | Author: buckyballreaction | Message: Fix memory leak with editor plugin menus when being scanned for inclusion into the plugin dock 
15:01:54 Watusimoto excellent!!
15:05:58 raptor ok
15:06:13 raptor the invalid write only occurs if undoing from a plugin created item
15:12:44 raptor probably an issue with copying from mLevelGenDatabase
15:25:53 raptor Watusimoto: anything in here seem odd to you that would indicate a double addition to databases in this methog?:  void EditorUserInterface::copyScriptItemsToEditor()
15:26:04 raptor I'm asking because I'm not sure (not because I think there is..)
15:26:18 raptor *method
15:27:28 Watusimoto the only real possibility is the saveUndoState line
15:29:07 raptor Quit ()
15:29:17 raptor has joined
15:29:18 ChanServ sets mode +o raptor
15:29:30 raptor as in, you think it is unneeded?
15:30:39 Watusimoto I think it's needed, but it's the only place I can see extra objects being creaetd
15:30:59 raptor oh..  maybe I move it below the loop..
15:31:11 raptor no, that would be bad..
15:32:00 Watusimoto comment out the saveUndoState and see if that fixes things
15:32:10 raptor ok
15:32:48 Watusimoto but actually, if it doesn't cause a problem elsewhere, it won't here, either
15:33:26 raptor still invalid write..
15:33:40 raptor oh
15:33:42 raptor what about
15:33:45 raptor hmm
15:33:46 Watusimoto so no, actually, I don't see anything in this method
15:34:03 raptor we're adding the object to the editor database in addToEditor()
15:34:04 Watusimoto but I could be missing something
15:34:10 Watusimoto yes
15:34:21 raptor but we call the mLevelGenDatabase.removeEverythingFromDatabase()
15:34:31 Watusimoto yes
15:34:47 Watusimoto we're moving objects from the lvelgen database to the main editor database
15:34:54 raptor but that does delete the items from the GridDB despite the comment...
15:35:51 raptor huh..  but it seems to work..
15:36:30 Watusimoto as in mAllObjects.deleteAndClear();
15:37:14 raptor for whatever reason the line on UIEditor.cpp:169 triggers the object clean-up
15:39:00 Watusimoto well... this should be a problem... we add an object to the main database, then delete it
15:40:06 Watusimoto so what does boost::dynamic_pointer_cast do?
15:40:09 Watusimoto do you know?
15:40:15 raptor it basically just calls dynamic_cast
15:40:20 raptor in a platform-agnostic way...
15:41:27 Watusimoto well, now I'm confused about how that code could work
15:42:33 raptor this has the best info about dynamic_pointer_cast I could find:  http://stackoverflow.com/questions/9391863/difference-between-shared-dynamic-cast-and-dynamic-pointer-cast
15:43:00 raptor if only the docs could provide info like that..
15:44:28 raptor is it not a real copy from the levelgen database to the editor database?
15:49:16 Watusimoto where do you see the copy happening?
15:49:51 raptor actually it's not a copy...  just making the object point to the new database?
15:50:10 raptor in that copyScriptItemsToEditor...
15:50:45 Watusimoto I think so
15:50:46 Watusimoto yes
15:52:23 raptor ok, i think that mehtod is working OK...
15:53:38 raptor so I'm now in undo(), right before the setDatabase call that makes the single WallItem (created from the lua script) destruct
15:57:54 raptor I have one WallItem in the current mEditorDatabase
15:58:13 raptor nothing in the mUndoItem[1] database that is going to be set..
16:03:47 raptor Watusimoto: I think the undo system is working fine...
16:04:41 Watusimoto that's good, I think :-)
16:05:30 raptor ok yes, it's working as expected
16:05:37 raptor i think...   hmmm
16:05:58 raptor there's a pointer to the WallItem in some other object that is left around..
16:09:59 raptor i have an idea!
16:46:43 raptor i mistakenly thought that items created via plugins were added to the mLevelgenDatabase
16:47:03 raptor and since they are not, that means they are added elsewhere..
16:47:13 raptor now to determine this 'elsewhere'
17:00:04 raptor found it lurking in mUndoItems
17:05:25 Watusimoto ???
17:05:28 Watusimoto really??
17:05:41 raptor actually..  give em a few...  i'm onto something
17:05:49 raptor i think the duplicate objects are sharing proxies
17:07:23 Watusimoto really??
17:08:27 Watusimoto I'm slipping off to sleep... trying to hang on...
17:11:19 BFLogBot Commit: 463d7c7f05bf | Author: watusimoto  | Message: Improvements to inline help system 
17:11:20 BFLogBot Commit: 800c4b048092 | Author: watusimoto  | Message: Merge 
17:23:31 raptor hi
17:23:35 raptor sorry had dinner
17:24:04 raptor you can go to sleep, but yes, the copied objects in the undo databases share the same LuaW proxy
17:45:03 raptor i'm not sure how to resolve that..
17:56:38 raptor so it looks like cloning will keep the same memory address
17:57:05 raptor so mLuaProxy will point to the same proxy when saving an undo state
17:57:12 raptor is there a way to prevent this?
17:57:54 raptor or some other model of how to handle?
18:08:46 Watusimoto we'll have to discuss tomorrow
18:08:49 Watusimoto when I can think
18:08:53 raptor hi
18:08:54 raptor ok
18:08:57 raptor to bed!
18:08:58 Watusimoto sorry!
18:09:01 Watusimoto to bed!
18:09:05 Watusimoto and beyond!
18:09:10 raptor night
18:13:07 raptor i'm deep into learning the scary inner workings of c++ again...   I do not wish to be here
18:13:47 Watusimoto Quit (Ping timeout: 256 seconds)
18:16:08 raptor 'dangling pointer'  <-- that's the term
18:17:44 raptor looks the the solution is to create a deep-copy copy constructor for each item OR use a smart pointer
18:18:17 raptor or even just reference counting..
18:39:39 bobdaduck has joined
18:42:31 raptor ok, well, i'm not getting anywhere else on this tonight...
19:04:24 bobdaduck Quit (Remote host closed the connection)
21:54:12 Nothing_Much Quit (Quit: l8r)
23:16:19 SolumnMushroom Quit (Ping timeout: 255 seconds)
23:21:52 raptor Quit ()

Index Search ←Prev date Next date→

These logs were automatically created by BFLogBot on irc.freenode.net.

00:53:48		Watusimoto has joined
01:07:25		bobdaduck Quit (Remote host closed the connection)
05:39:25	Watusimoto	funny... I updated and got a whole log of recompiling...
05:40:07		BFLogBot Commit: 57602b0acc91 \| Author: watusimoto \| Message: Found the path forward for ClientGame in our test rig. Needs further refinement, but we can now build tests using ClientGame.
05:40:09		BFLogBot Commit: 81ca449a2591 \| Author: watusimoto \| Message: Merge
05:40:10		BFLogBot Commit: 91e94874948a \| Author: watusimoto \| Message: Clean up our ClientGame-in-test solution a little
06:38:19		ozbitfighter has joined
07:27:40		BFLogBot Commit: 15a144f8e2ad \| Author: watusimoto \| Message: Comments
07:27:42		BFLogBot Commit: a580ef1654e7 \| Author: watusimoto \| Message: Add assert that identifies source of our editor crash
07:27:43		BFLogBot Commit: 861d2e0905c0 \| Author: watusimoto \| Message: Fix crash in editor. Not sure why this worked at all in Linux... but hey, it's a magical operating system!
07:27:45		BFLogBot Commit: 88a6775c2bf3 \| Author: watusimoto \| Message: Rename kind of useless test, leaving a little nub in place to help guide the way for ClientGame testing
08:13:02		Watusimoto Quit (Remote host closed the connection)
08:25:38		ozbitfighter Quit (Quit: Page closed)
09:19:35		Watusimoto has joined
09:42:20		BFLogBot Commit: 2b1589fe0da8 \| Author: watusimoto \| Message: Totally unnecessary fix: manually delete menu items when we close a QuickMenu. This does have the advantage of reclaiming a tiny amount of memory that would otherwise be tied up in some useless menu items until the next menu was created.
09:42:22		BFLogBot Commit: ac9c2d224618 \| Author: watusimoto \| Message: Whitespace
09:45:59		BFLogBot Commit: 74b113ffea30 \| Author: watusimoto \| Message: Whitespace
09:51:44		SolumnMushroom has joined
10:03:27		Watusimoto Quit (Remote host closed the connection)
10:04:23		BFLogBot Commit: 58323acd2cd7 \| Author: watusimoto \| Message: Show joystick control help when in joystick mode
10:26:27		bobdaduck has joined
10:55:06		Watusimoto has joined
11:33:25		Watusimoto Quit (Ping timeout: 255 seconds)
12:07:08		bobdaduck Quit (Remote host closed the connection)
12:15:11		Watusimoto has joined
12:18:31		raptor has joined
12:18:31		ChanServ sets mode +o raptor
12:19:17	raptor	hello!
12:19:55	raptor	let it me known that the editor crash (according to your assert) was not my code... :)
12:20:37	raptor	but i'm sure my changes exacerbated the problem..
12:22:58	raptor	there, i got my very intricate and important commit done for the day
12:23:49		BFLogBot Commit: 780e24055199 \| Author: buckyballreaction \| Message: Spelling
12:35:53	raptor	Watusimoto: I know this is crazy, but the memory leak is still there, even after your changes...
12:38:30	raptor	here are our current memory leaks (and 1 error - the invalid write - ignore this for now): http://pastie.org/pastes/8072733/text
12:41:38	Watusimoto	hi
12:41:45	raptor	hi
12:42:13	Watusimoto	I don't think there is a memory leak
12:42:32	Watusimoto	at least not in the menuitems code
12:42:35	raptor	that report is from valgrind i just ran on a clean compile of latest
12:42:58	Watusimoto	are you refering to the last section?
12:43:04	Watusimoto	the ToggleMenuItems
12:43:15	raptor	all three of the last that have LuaW in them
12:43:21	Watusimoto	oh, there are teh CounterMenuItems as well
12:43:26	raptor	the last 3 sections, i mean
12:43:36	Watusimoto	I only tested using the curve tool; is that sufficient to reproduce?
12:43:39	raptor	i think one is a subclass of the other...
12:43:41	raptor	yes
12:43:47	raptor	even jsut opening/closing the curve tool
12:43:47	Watusimoto	ok
12:43:59	Watusimoto	yes, that is enough to create the menu items
12:44:16	raptor	that invalid write has something to do with LuaW... which I'm tracking down..
12:44:20	Watusimoto	but when I put a breakpoint in the CounterMenuitem destructor, I see them destructing just as I would expect
12:44:32	raptor	maybe more than one is being created?
12:44:59	Watusimoto	I have not done this, but I would assert that if you put a counter in during construction, and decremented it during desstruction, you would be at 0 after each menu close
12:45:23	raptor	i can test that real fast...
12:45:55	Watusimoto	go for it. I have done it manually, so am confident of the result
12:46:04	Watusimoto	I did it a while ago, and again today
12:46:11	Watusimoto	both before and after my code modifications
12:46:21	Watusimoto	and all those modifications changed was the timing
12:46:38	Watusimoto	(admittedly for the better)
12:47:13	raptor	putting the static counter in both constructors of CounterMenuItem
12:49:36	raptor	ok, i have 11 constructor hits when i get to the editor...
12:49:48	raptor	run plugin, up to 18
12:50:10	raptor	close window... back to 11
12:50:23	raptor	huh
12:51:19	raptor	maybe... it has something else to do with the plugin system?
12:55:50	Watusimoto	yeah, maybe
12:57:11	raptor	that invalid write...
12:57:19	raptor	hmm
12:59:44	raptor	moral of the day - don't feed a brownie to a 1.8-year-old
13:03:45	raptor	hmm... the invalid write only happens when you 'undo' a created barrier with a plugin
13:03:55	raptor	(or loadoutzone)
13:18:28	raptor	i keep thinking we should work to get rid of our proxies somehow
13:18:36	raptor	then I keep finding evidence that they're needed..
13:22:13	Watusimoto	I don't think we can get rid fo them
13:26:37	Watusimoto	that valgrind item seems to clearly show that the item at issue is the ToggleMenuItem. It points to line 92, where the item is new'ed
13:28:01	Watusimoto	I don't see any way for the constructor iteself to be leaking
13:29:00	raptor	new clue: no matter how many different plugins i run, or how many times i open them, i get those same 3 blocks only on exit
13:29:09	raptor	in the valgrind report
13:29:24	Watusimoto	I remain unconvinced it's an actual leak
13:29:47	raptor	I'm starting to think that myself...
13:29:51	kaen	I remember some wonkiness with toggle items when I was writing those plugins
13:30:13	Watusimoto	try it in release mode?
13:30:16	kaen	specifically the game would crash when opening a plugin menu with a toggle item multiple times
13:30:46	kaen	but that was before all of this lua work so I don't know if it's relevant anymore
13:30:47	raptor	oh yeah.. i remember that. in fact, didn't i fix that?
13:30:56	kaen	quite possible
13:31:07	Watusimoto	from the valgrind docs
13:31:09	Watusimoto	When fixing errors, it is a good idea to start at the top; fixing an error that occurs earlier is likely to eliminate a lot of later errors as well.
13:31:09	Watusimoto	Once in a great while you may encounter a false positive -- an error even though there is nothing wrong with your program. However, in the vast majority of cases, any error reported is real and you should fix it. Be very wary about dismissing an error as a "false positive," since it is much more likely that you have made a mistake.
13:32:42	Watusimoto	since we aer seeing reports in a number of different menu items, the problem (if it exists) is probably with a common anscestor
13:33:15	raptor	so if i discover a bool has value of '48', something is wrong?
13:34:11	raptor	that invalid write is occurring like so: 1. run plugin 2. undo wall created 3. shutdown
13:34:40	raptor	and on undo, the wall is removed from the database (and destructor hit), but on shutdown, it is being hit again
13:34:47	raptor	anyone have an idea as to why?
13:36:53	Watusimoto	where do you get the 48?
13:36:58	Watusimoto	that's clearly a bug
13:37:02	Watusimoto	it should be 42
13:39:42	raptor	ha
13:40:04	raptor	the WallItem (or LoadoutZone, whatever) is destructing twice
13:40:21	raptor	once with the 'undo' after plugin run, once when closing the game
13:46:29	raptor	there is a bug somewhere between these two traces: http://pastie.org/pastes/8072867/text
13:46:38	raptor	the destructor should only be called once, right?
13:53:02	raptor	oops, i meant these: http://pastie.org/pastes/8072884/text
13:56:37	raptor	Watusimoto: in UIEditor.cpp:169, do you know why this boost::dynamic_pointer_cast class was used?: mEditorDatabase = boost::dynamic_pointer_cast<GridDatabase>(database);
13:57:42	Watusimoto	no, I don't know
13:58:03	raptor	because that line is calling the destructor for the objects..
13:59:11	raptor	whihc makes sense, but there is still a pointer to the object when we close the editor
14:02:47	raptor	we have multiple GridDatabases with the undo system, each wrapped in a shared_ptr.. ohhhh
14:02:59	Watusimoto	I can't even find any docs about what dynamic_pointer_cast is suppsed to do
14:03:09	Watusimoto	yes
14:03:13	raptor	the GridDatabases themselves hold pointers to objects, yes?
14:03:15	Watusimoto	it was a very lazy way to do undo
14:03:21	Watusimoto	yes
14:03:41	raptor	what happens if two GridDB hold the same pointer to an object? and they both are destructed?
14:03:54	Watusimoto	I do have a design for a much more compact and efficient undo system
14:04:02	Watusimoto	they don't
14:04:12	Watusimoto	they hold pointers to copies of objects
14:04:21	raptor	well... in this case they don't
14:04:21	Watusimoto	when you copy a database, everything inside gets copied as well
14:04:25	raptor	heh
14:04:28	raptor	not happening!
14:04:41	Watusimoto	no?
14:04:46	raptor	the exact same object is being deleted from two databases
14:05:10	Watusimoto	well, that could be a problem
14:05:54	raptor	yes - granted the second delete is only happening when we shut down
14:06:37	raptor	were is this database copy supposedly happening?
14:08:32	Watusimoto	probably in the undo sectino of the editor
14:08:44	Watusimoto	that's the only reason we copy databases, to give us an undo capacity
14:09:08	raptor	oh interesting... i just got the menu item leaks without running a plugin
14:10:23	raptor	twinkies are coming back!
14:16:52	raptor	i think menu items are leaking when running plugin.runGetArgsMenu to fill up kaen's plugin dock
14:21:02	raptor	maybe it's a bad plugin of mine?
14:23:17	Watusimoto	plugins shouldn't be able to be bad... unless they create a menu item they never add to a menu
14:23:24	Watusimoto	in which case... naughty!
14:23:37	raptor	yes... i just checked that and all of mine are added in a menu..
14:23:54	Watusimoto	try removing all your plugins and see if that fixes the problem
14:24:38	raptor	i'm bisecting it
14:24:40	raptor	ha
14:24:41	raptor	ok
14:24:43	raptor	so
14:24:58	raptor	any menuitem you instantiate in a plugin
14:25:09	raptor	leave behind one of its kind as a leak
14:25:26	raptor	so if i have 2 plugins, each with 5 ToggleMenuItems
14:25:32	raptor	one TMI is leaking
14:26:08	raptor	but if I have 5,4,3, of Toggle, Counter, YesNo; it leaves behind 1 of each as a leak
14:26:17	raptor	across all scripts
14:27:08	Watusimoto	off-by-one bug?
14:27:33	raptor	perhaps... looking deeper - all these are being called in EditorUserInterface::findPlugins()
14:27:35	Watusimoto	or maybe it creates an extra item somehow that never gets added anywhere?
14:27:42	raptor	that could be, too..
14:29:09	raptor	uh oh... we're using a Vector<MenuItem*> menu;
14:29:47	raptor	let me convert that to a shared_ptr...
14:29:56	Watusimoto	ah, maybe that's it
14:30:07	Watusimoto	good catch -- I read right past that
14:31:02	raptor	yep.. i see it being created, but not cleaned up..
14:32:39	raptor	ah... ok, when a plugin is run, it is actually added to a menu which keeps track of them with a shared_ptr
14:33:10	raptor	but on start up, when the plugin is run to grab information, the menuitems are not added anywhere...
14:33:58	Watusimoto	ah, interesting
14:34:05	Watusimoto	so those ones are never cleaned up
14:34:10	raptor	correct
14:34:17	Watusimoto	maybe create them as shared_ptrs from the outset?
14:34:47	raptor	i'm thinking that, too
14:35:02	Watusimoto	we might as well... then we don't need to worry about them
14:45:58	raptor	is there a difference between shared_ptr<MenuItem*> and shared_ptr<MenuItem> ?
14:46:05	raptor	i mean at the implementation level?
14:46:29		Watusimoto Quit (Read error: Connection reset by peer)
14:48:09		Watusimoto has joined
14:50:35	raptor	testing fix..
14:51:52	raptor	ladies and gentlemen, the leak is fixed!
14:55:00		BFLogBot Commit: c86f18f1d2c0 \| Author: buckyballreaction \| Message: Fix memory leak with editor plugin menus when being scanned for inclusion into the plugin dock
15:01:54	Watusimoto	excellent!!
15:05:58	raptor	ok
15:06:13	raptor	the invalid write only occurs if undoing from a plugin created item
15:12:44	raptor	probably an issue with copying from mLevelGenDatabase
15:25:53	raptor	Watusimoto: anything in here seem odd to you that would indicate a double addition to databases in this methog?: void EditorUserInterface::copyScriptItemsToEditor()
15:26:04	raptor	I'm asking because I'm not sure (not because I think there is..)
15:26:18	raptor	*method
15:27:28	Watusimoto	the only real possibility is the saveUndoState line
15:29:07		raptor Quit ()
15:29:17		raptor has joined
15:29:18		ChanServ sets mode +o raptor
15:29:30	raptor	as in, you think it is unneeded?
15:30:39	Watusimoto	I think it's needed, but it's the only place I can see extra objects being creaetd
15:30:59	raptor	oh.. maybe I move it below the loop..
15:31:11	raptor	no, that would be bad..
15:32:00	Watusimoto	comment out the saveUndoState and see if that fixes things
15:32:10	raptor	ok
15:32:48	Watusimoto	but actually, if it doesn't cause a problem elsewhere, it won't here, either
15:33:26	raptor	still invalid write..
15:33:40	raptor	oh
15:33:42	raptor	what about
15:33:45	raptor	hmm
15:33:46	Watusimoto	so no, actually, I don't see anything in this method
15:34:03	raptor	we're adding the object to the editor database in addToEditor()
15:34:04	Watusimoto	but I could be missing something
15:34:10	Watusimoto	yes
15:34:21	raptor	but we call the mLevelGenDatabase.removeEverythingFromDatabase()
15:34:31	Watusimoto	yes
15:34:47	Watusimoto	we're moving objects from the lvelgen database to the main editor database
15:34:54	raptor	but that does delete the items from the GridDB despite the comment...
15:35:51	raptor	huh.. but it seems to work..
15:36:30	Watusimoto	as in mAllObjects.deleteAndClear();
15:37:14	raptor	for whatever reason the line on UIEditor.cpp:169 triggers the object clean-up
15:39:00	Watusimoto	well... this should be a problem... we add an object to the main database, then delete it
15:40:06	Watusimoto	so what does boost::dynamic_pointer_cast do?
15:40:09	Watusimoto	do you know?
15:40:15	raptor	it basically just calls dynamic_cast
15:40:20	raptor	in a platform-agnostic way...
15:41:27	Watusimoto	well, now I'm confused about how that code could work
15:42:33	raptor	this has the best info about dynamic_pointer_cast I could find: http://stackoverflow.com/questions/9391863/difference-between-shared-dynamic-cast-and-dynamic-pointer-cast
15:43:00	raptor	if only the docs could provide info like that..
15:44:28	raptor	is it not a real copy from the levelgen database to the editor database?
15:49:16	Watusimoto	where do you see the copy happening?
15:49:51	raptor	actually it's not a copy... just making the object point to the new database?
15:50:10	raptor	in that copyScriptItemsToEditor...
15:50:45	Watusimoto	I think so
15:50:46	Watusimoto	yes
15:52:23	raptor	ok, i think that mehtod is working OK...
15:53:38	raptor	so I'm now in undo(), right before the setDatabase call that makes the single WallItem (created from the lua script) destruct
15:57:54	raptor	I have one WallItem in the current mEditorDatabase
15:58:13	raptor	nothing in the mUndoItem[1] database that is going to be set..
16:03:47	raptor	Watusimoto: I think the undo system is working fine...
16:04:41	Watusimoto	that's good, I think :-)
16:05:30	raptor	ok yes, it's working as expected
16:05:37	raptor	i think... hmmm
16:05:58	raptor	there's a pointer to the WallItem in some other object that is left around..
16:09:59	raptor	i have an idea!
16:46:43	raptor	i mistakenly thought that items created via plugins were added to the mLevelgenDatabase
16:47:03	raptor	and since they are not, that means they are added elsewhere..
16:47:13	raptor	now to determine this 'elsewhere'
17:00:04	raptor	found it lurking in mUndoItems
17:05:25	Watusimoto	???
17:05:28	Watusimoto	really??
17:05:41	raptor	actually.. give em a few... i'm onto something
17:05:49	raptor	i think the duplicate objects are sharing proxies
17:07:23	Watusimoto	really??
17:08:27	Watusimoto	I'm slipping off to sleep... trying to hang on...
17:11:19		BFLogBot Commit: 463d7c7f05bf \| Author: watusimoto \| Message: Improvements to inline help system
17:11:20		BFLogBot Commit: 800c4b048092 \| Author: watusimoto \| Message: Merge
17:23:31	raptor	hi
17:23:35	raptor	sorry had dinner
17:24:04	raptor	you can go to sleep, but yes, the copied objects in the undo databases share the same LuaW proxy
17:45:03	raptor	i'm not sure how to resolve that..
17:56:38	raptor	so it looks like cloning will keep the same memory address
17:57:05	raptor	so mLuaProxy will point to the same proxy when saving an undo state
17:57:12	raptor	is there a way to prevent this?
17:57:54	raptor	or some other model of how to handle?
18:08:46	Watusimoto	we'll have to discuss tomorrow
18:08:49	Watusimoto	when I can think
18:08:53	raptor	hi
18:08:54	raptor	ok
18:08:57	raptor	to bed!
18:08:58	Watusimoto	sorry!
18:09:01	Watusimoto	to bed!
18:09:05	Watusimoto	and beyond!
18:09:10	raptor	night
18:13:07	raptor	i'm deep into learning the scary inner workings of c++ again... I do not wish to be here
18:13:47		Watusimoto Quit (Ping timeout: 256 seconds)
18:16:08	raptor	'dangling pointer' <-- that's the term
18:17:44	raptor	looks the the solution is to create a deep-copy copy constructor for each item OR use a smart pointer
18:18:17	raptor	or even just reference counting..
18:39:39		bobdaduck has joined
18:42:31	raptor	ok, well, i'm not getting anywhere else on this tonight...
19:04:24		bobdaduck Quit (Remote host closed the connection)
21:54:12		Nothing_Much Quit (Quit: l8r)
23:16:19		SolumnMushroom Quit (Ping timeout: 255 seconds)
23:21:52		raptor Quit ()