IRC log for #brlcad on 20190326

00:20.47 starseeker confound it...
00:26.45 starseeker getting an erratic and not reproducible recurrance of the nil free problem
00:41.56 starseeker ah, got gdb on it: https://paste.ubuntu.com/p/hd9xYxkXTp/
00:47.17 starseeker brlcad: hmm... the db_close at cache.c:635... how could another thread get to that dbip before closure?
00:48.58 starseeker It shouldn't be in the cache at all, if I'm reading this right - cache_read_dbip will create a new one with db_open...
00:53.12 starseeker could another thread generate the same temp file name if it hits the same object at the same time? I don't know how robust uuid is...
00:55.18 starseeker brlcad: in some ways, I almost wish we could do a tree walk, build the set of all unique objects, and then process that list so we could be sure none of the threads were trying to prep the same object at the same time...
00:58.39 brlcad gah
00:59.21 starseeker brlcad: here's what's in the dbip: https://paste.ubuntu.com/p/shN5vDMhtB/
00:59.39 starseeker I've still got gdb on it if there's anything else to be gleaned
00:59.46 brlcad per original question, don't think the unit tests should actually do shot validation
01:00.00 starseeker nods - works
01:00.17 brlcad i'm still looking at the changes you made to see if I understand them correctly
01:00.39 starseeker nods
01:01.26 starseeker to see the behavior I was seeing, just revert my changes and run any of the rt_cache tests (e.g. rt_cache 1)
01:02.12 starseeker it was trying to re-populate the mapped_file list after calling free on it that caused the blow-up
01:02.44 *** join/#brlcad LordOfBikes (~armin@dslb-088-066-140-085.088.066.pools.vodafone-ip.de)
01:05.50 brlcad at a quick glance, db_close() looks like it may not be entirely threadsafe
01:14.41 *** join/#brlcad kintel (~textual@unaffiliated/kintel)
01:21.53 *** join/#brlcad teepee_ (~teepee@unaffiliated/teepee)
01:23.44 starseeker brlcad: I was considering trying to use subprocesses to hit test caches with multiple processes simultaneously, over and above threads... is that worth doing, or does the multithread testing provide all the benefits we might see there?
01:25.01 brlcad separate concerns
01:27.27 brlcad in theory the rename construct made it fully multiprocess-safe now barring maybe some obscure moments when the cache directory is first constructed when the version file is created
01:27.34 brlcad the cache files themselves should be golden and my manual hammering seems to confirm that
01:27.55 brlcad that said, can't hurt so long as the tests are bugfree ;)
01:28.46 starseeker heh. OK, I'll see what I can cook up
02:08.42 starseeker finishes round one of test code consolidation
02:09.13 starseeker I'll try the subprocess stuff tomorrow
02:09.17 starseeker must get trash
02:23.51 *** join/#brlcad kintel (~textual@unaffiliated/kintel)
02:39.54 *** join/#brlcad kintel (~textual@unaffiliated/kintel)
05:58.20 brlcad that does it for now
06:59.32 *** join/#brlcad merzo (~merzo@48-10-132-95.pool.ukrtel.net)
07:53.12 *** join/#brlcad merzo (~merzo@48-10-132-95.pool.ukrtel.net)
09:21.24 *** join/#brlcad merzo (~merzo@195.20.130.10)
09:46.23 *** join/#brlcad teepee_ (~teepee@unaffiliated/teepee)
10:37.56 *** join/#brlcad teepee (~teepee@unaffiliated/teepee)
10:49.24 *** join/#brlcad Caterpillar (~caterpill@unaffiliated/caterpillar)
10:51.25 *** join/#brlcad teepee (~teepee@unaffiliated/teepee)
10:56.42 starseeker brlcad: with trunk I'm getting "(nil) free ERROR free mapped file pointers
10:56.50 starseeker building the sample .g files
10:59.58 starseeker stack smash is back with rt_cache 1, follows the "free ERROR" message.
11:00.10 starseeker however, all bu_mappedfile tests pass
11:02.04 *** join/#brlcad Caterpillar (~caterpill@unaffiliated/caterpillar)
11:04.38 *** join/#brlcad Caterpillar (~caterpill@unaffiliated/caterpillar)
11:23.59 starseeker reflects and thinks he needs to add another mappedfile test...
11:35.03 *** join/#brlcad teepee (~teepee@unaffiliated/teepee)
11:37.42 *** join/#brlcad merzo (~merzo@195.20.130.10)
12:12.29 *** join/#brlcad raingloom (~raingloom@catv-178-48-182-39.catv.broadband.hu)
12:30.05 *** join/#brlcad teepee (~teepee@unaffiliated/teepee)
12:38.20 *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51)
13:01.57 *** join/#brlcad kintel (~textual@unaffiliated/kintel)
13:13.13 *** join/#brlcad yorik (~yorik@2804:431:f721:ee35:290:f5ff:fedc:3bb2)
14:27.17 *** join/#brlcad kintel (~textual@unaffiliated/kintel)
15:23.59 *** join/#brlcad yorik (~yorik@2804:431:f721:ee35:290:f5ff:fedc:3bb2)
19:06.08 *** join/#brlcad raingloom (~raingloom@catv-178-48-182-40.catv.broadband.hu)
19:15.16 *** join/#brlcad teepee (~teepee@unaffiliated/teepee)
20:27.49 *** join/#brlcad merzo (~merzo@168-38-132-95.pool.ukrtel.net)
21:29.26 *** join/#brlcad kintel (~textual@unaffiliated/kintel)
22:29.05 *** join/#brlcad kintel (~textual@unaffiliated/kintel)
23:53.40 *** join/#brlcad raingloom (~raingloom@catv-178-48-182-38.catv.broadband.hu)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.