Open Source Meeting/2010-08-10

== Agenda Tuesday, 10 August 2010 ==
# Weekly Snowglobe update - (without Merov Linden, he's on vacation)
# Branch desync?
#* Some commits from 2009/trunk are missing from the RC (2009/1.4) (which is normal), but there are also commits in the RC not present in trunk:
#** For we know that fixing this on trunk, too, is on Aleric's TODO list
#** What about the other RC-only commits?
#*** (workaround for a crash)
#*** ("Emergency patch" for an already fixed issue that popped up again) (This is actually --TB)
# Porting http-textures fixes from 1.5 to 1.4 (see jiras linked from ). This seem to work very well, except for:
#* - An assert when going back from 1.5 to 1.4. Is this a bug or expected behavior? i.e. do we fix it, or just increment LLTextureCache::sHeaderCacheVersion to force a cache purge?
=== Jira Issues ===
# (Robin Cornelius)
# Make libllcommon shared for SLPlugin + plugins on 1.4
# Ready to commit (Aleric Inglewood)
# idem
# Unscheduled SNOW issues triage: would be good to go with the community through those and decide for some what we should take immediately (2.0 or 1.4) or later.
== Transcript ==
[13:57]	:	I have to go to dinnor now. So will be unable to responc to questions.
[13:59]	:	ok
[13:59]	:	hope im able to stick around with not net issues knock on wood
[14:00]	:	knock on prims
[14:00]	:	actualy i have a wood desk RL
[14:02]	:	hey robin
[14:03]	:	Hi
[14:03]	:	hi all
[14:03]	:	Are we expecting lindens?
[14:04]	:	they're late
[14:04]	:	Merov's still on vacation, I think.
[14:04]	:	Dunno about Oz
[14:04]	:	kk, thats a pretty graph on the screen
[14:05]	:	newest revisions at the bottom. confusing for a gitk user like me :-P
[14:06]	:	let's get started, shall we?
[14:06]	:	Still no Merov?
[14:06]	:	no
[14:06]	:	he still on vac
[14:06]	:	next week?
[14:06]	:	Hi's gone on vacation for two weeks, this here is the second.
[14:06]	:	(If I counted correctly)
[14:07]	:	good time to be on vacation, i would have avoided this week as wekk ;-)
[14:07]	:	*well
[14:07]	:	OMG a branch desync!!!
[14:07]	 	does a Merov impersonation: so let's get started? https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda
[14:07]	:	But it's not really desynced... the patch is in the queue somewhere.
[14:08]	:	Aleric, sorry. I got confused.
[14:08]	:	que queue?
[14:08]	:	the queue in my head :p
[14:08]	:	ah
[14:08]	:	apply your head to trunk ASAP, then :-P
[14:09]	:	Oh well... only SNOW-800 is in my queue ;) ... so maybe it's worse than I think :). Please tell
[14:09]	:	http://jira.secondlife.com/browse/SNOW-800 [#SNOW-800] Massively duplicated objects
[14:09]	:	expected behavior NMI
[14:10]	:	what?
[14:10]	:	lol
[14:10]	:	SNOW-710 and SNOW-196 both got emergency patches/workarounds on 1.4
[14:10]	:	http://jira.secondlife.com/browse/SNOW-710 [#SNOW-710] ERROR: onBakedTextureMasksLoaded: No auxiliary source data for onBakedTextureMasksLoaded
[14:10]	:	http://jira.secondlife.com/browse/SNOW-196 [#SNOW-196] Deadlock in LLTextureFetchWorker::lockWorkMutex / LLThread::lockData / LLTextureFetch::lockQueue
[14:10]	:	I guess we don't want these in trunk, but the real fixes instead
[14:10]	:	Yes, those the emergency patches were deliberatly not committed to trunk
[14:11]	:	s/196/169/
[14:12]	:	SNOW-169 yes, is wrong on agenda too?
[14:12]	:	http://jira.secondlife.com/browse/SNOW-169 [#SNOW-169] Viewer crash: LLViewerImage::doLoadedCallbacks: ASSERT (mRawImage.notNull())
[14:13]	:	I mean the emergency fix was for SNOW-169, no -196
[14:13]	:	or am I wrong?
[14:13]	:	Yes, and 169 was committed to 1.4 and not 1.5. But I see a 196 on the agenda too
[14:13]	:	yep, SNOW-169
[14:14]	:	I got it wrong from the picture, it seems.
[14:14]	 	blames Ardy
[14:14]	:	Sorry. Dyslexia strikes again.
[14:14]	:	:-P
[14:14]	:	I did edit the image.
[14:15]	:	SNOW-796 is gone too now from the Agenda?
[14:15]	:	http://jira.secondlife.com/browse/SNOW-796 [#SNOW-796] Clicking 'Reset to default' in the Debug Settings floater doesn't update cached control values.
[14:15]	:	anyway the commits in question are http://svn.secondlife.com/trac/linden/changeset/3611 and http://svn.secondlife.com/trac/linden/changeset/3604
[14:15]	:	Everything looks fine to me thus.
[14:16]	:	-796 is both in 1.5 and 1.4, so that's good.
[14:16]	:	SNOW-796 has a commit in both 1.4 and trunk
[14:16]	:	ok, let's move on, then
[14:17]	:	Porting http-textures fixes from 1.5 to 1.4 (see jiras linked from SNOW-782[c]). This seem to work very well, except for:* SNOW-799[c] - An assert when going back from 1.5 to 1.4. Is this a bug or expected behavior? i.e. do we fix it, or just increment LLTextureCache::sHeaderCacheVersion to force a cache purge?
[14:17]	:	http://jira.secondlife.com/browse/SNOW-782 [#SNOW-782] Snowglobe 1.4 / 1.5 http texture related issues
[14:17]	:	http://jira.secondlife.com/browse/SNOW-799 [#SNOW-799] Assertion failure ASSERT (entry.mImageSize == 0 || entry.mImageSize == -1 || entry.mImageSize > entry.mBodySize)
[14:18]	:	aleric, do you know which part of the assert was false?
[14:18]	:	no, sorry
[14:18]	:	I suspect (entry.mImageSize > entry.mBodySize)
[14:19]	:	yes
[14:19]	:	but I haven't seen this crash.
[14:19]	:	i've seen it assert
[14:20]	:	this is from 2.1: if(entry.mImageSize <= entry.mBodySize)//it happens on 64-bit systems, do not know why
[14:20]	:	I didn't notice any deliberate changes to the texture cache structure. Did I miss that?
[14:21]	:	1.5 should resemble 2.1 now
[14:21]	:	I don't think that increasing the cache version can be wrong... if not for 1.4, then at least for 1.3, cause apparently the two cache formats are not compatible. My only question is: is what 1.5 (with HTTP textures) does to the cache really intended? Or can we just fix it so that 1.4 can read the cache too again?
[14:21]	:	Robin, the difference being?
[14:22]	:	Thickbrick: that "I don't know why" and only on 64-bit systems look like a BUG thus... Maybe we should fix 1.5 so it doesn't happen.
[14:22]	:	i've still got to add the mCanUseHTTP stuff in that fixes bakes 100%
[14:22]	:	and the are changes to mutex handling and i'm just not going near that
[14:23]	:	yeah, that's not something to do in a RC
[14:23]	:	Seems to me we should just disable HTTP textures completely in 1.4.
[14:23]	:	i'm working on 1,.5 now, but any other differences in texturefetch are probably worth checking
[14:23]	:	by default they are disabled
[14:24]	:	Not if you just ran 1.5
[14:24]	:	ah good point
[14:24]	:	It should FORCE it to off.
[14:24]	:	releasing 1.4 without http textures would be pretty useless IMHO
[14:24]	:	And then when Oz is fired we willl.. Oh there he is!
[14:24]	:	heheh
[14:24]	:	lol
[14:25]	:	You're late :)
[14:25]	:	since this causes problem to other viewers, I think we need to either change the cache version (so other viewres would clear cache) or make sure it doesn't happen
[14:25]	:	sorry - prior meeting ran long
[14:25]	:	Robin, do you know the specifics of what causes this?
[14:25]	:	Latif Khalifa: releasing 1.4 without http textures would be pretty useless IMHO <--- why?
[14:26]	:	Thickbrick, no not really
[14:26]	:	I think 1.4 is different enough from 1.3 to warrant a release, even without the recent stuff.
[14:26]	:	people want the performance improvement that http textures bring. they enable it in totally broken viewers like emerald. 1.4 without http textures will add very little to 1.3
[14:27]	:	gazillion of biild tweaks, but nothing really substantial for a regular user
[14:27]	:	Excuse me, but 1.4 is the first with the water fixes! :p
[14:27]	:	you asked for my opinion, i gave it to you :P
[14:28]	:	I think that people *will* enable http texture in 1.4, whatever we do. So we should make sure it work reasonably well.
[14:28]	:	so all i get when i upgrade from 1.23.5 to 1.4 are the freezes
[14:29]	:	:-
[14:29]	:	ok... if it doesn't cause crashes and seems to work fine then why not... still seems a big change for a RC.. so can we keep the default to off?
[14:30]	:	I'm not advocating changing the deailt to on
[14:30]	:	*the default
[14:30]	:	We either have to apply Robin's fixes to 1.4, or make it impossible to enable HTTP textures in 1.4 imho (ie, remove it from the advanced menu)
[14:30]	:	vote 1 2 3, assigned to Robin: apply patches to 1.4. Next!
[14:31]	:	no argument there, but what do we do with SNOW-799?
[14:31]	:	can we make it default off on 1.4 and not inherit the setting from previously run 1.5?
[14:32]	:	(e.g. by naming the setting differently)
[14:32]	:	I don't see a problem with purging the cache when going from 1.5 to 1.4.
[14:32]	:	Boroondas, releases (and release candidate?) use a different setting file than "test builds"
[14:32]	:	Boroondas: The setting for HTTP textures?
[14:33]	:	so what's the issue, then?
[14:33]	:	Aleric, yes.
[14:33]	:	I don't see an issue
[14:34]	:	Not sure what happens then... probably that it will turn off after running 1.5, even when it's persistent.
[14:34]	:	Might as well share the setting name then (assuming we fix it, no?)
[14:34]	:	~/.secondlife/user_settings/settings_snowgloberelease.xml
[14:35]	:	~/.secondlife/user_settings/settings_snowglobetestbuild2.xml
[14:35]	:	umm, ignore that "2" there, I added that by hand.
[14:36]	:	... I vote for you doing as you please :p
[14:36]	:	heh
[14:37]	:	It's much easier for me to complain afterwards :)
[14:37]	:	heheh
[14:37]	:	why not change the assert (backport from 2.1)?
[14:38]	:	is it already part of http fixes+
[14:38]	:	?
[14:38]	:	ok just done the bake/http avoidance backport SNOW-802
[14:38]	:	http://jira.secondlife.com/browse/SNOW-802 [#SNOW-802] Baked textures should not even be attempted to be downloaded by http
[14:38]	:	because it includes a "we don't know why this happens" comment.
[14:39]	:	ok so we need to find out WTF is going on and why it asserts
[14:39]	:	i'm probably good to do that
[14:40]	:	my question on the agenda was orginally more of a "should this block moving the other patches to 1.4 for now"?
[14:40]	:	probably not
[14:40]	:	well, I gues we did cover that.
[14:42]	 	spend the last full four days trying to find all the global objects and their type... :(
[14:42]	:	ok, we're through with topics, then, aren't we? Shall we get to https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda #Jira_Issues
[14:43]	:	I removed the two jiras there that were remnants from the first attempt of merging 2.1 - they both seem to not happen in 2.1 now.
[14:43]	:	yeah
[14:44]	:	now that many people use sg test builds i have heard many reports of http://jira.secondlife.com/browse/SNOW-467 or some varient there off
[14:44]	:	[#SNOW-467] remove:region() can stall for long periods of time leading to a viewer disconnect, esp after teleport
[14:44]	:	and it has propagated to emerald and imprudence which both use 1.x sg as upsteam
[14:45]	:	This is my result: all the different TYPES of the global/static variables in secondlife-bin: http://codepad.org/awIp6sex
[14:45]	:	I got that a couple times, but then I do a LOT of tps on gridhunts.
[14:45]	:	(conclusion: a LLLOOOOOTTTTT... and no way to "clean up" before the end of main())
[14:45]	:	for me personally, it makes SG unusable
[14:46]	:	Aleric, doesn't stuff like that belong in trunk, not the branch?
[14:46]	:	I never got the SNOW-596 patch to apply on windows
[14:46]	:	http://jira.secondlife.com/browse/SNOW-596 [#SNOW-596] APR memory pool used in an error prone way
[14:47]	:	Thickbrick: this is research for memory leaks, so 596
[14:47]	:	can we focus on one issue at a time, please? (If yes, which one? ;-))
[14:47]	:	(Sorry...)
[14:48]	:	I stubornly wanted to release all libapr pools at the end of the program, but it appears impossible. We'll just have to exit the application without cleaning up. Too many global variables.
[14:49]	:	I don't want to look at a new bug, until I have 596, 593 and 707 committed :/
[14:49]	:	SNOW-707
[14:49]	:	http://jira.secondlife.com/browse/SNOW-707 [#SNOW-707] Start up crash of LLErrorThread due to corrupt map in CheckLevelMap
[14:49]	:	oh well
[14:50]	:	why release a viewer that people can actually use :P
[14:51]	:	Did anyone besides Boroondas test SNOW-596 yet?
[14:51]	:	NickyP tries, but he can't seem to get the patch to apply.
[14:51]	:	I'd like someone to try it on windows though.
[14:52]	:	Aleric ping me tomorrow, i'll try it then when you are around
[14:52]	:	okies
[14:52]	:	BRB
[14:52]	:	Aleric, I built it, but haven't had a chance to really test running it yet.
[14:52]	:	I see you finally put your clothes in the washing machine Robin?
[14:53]	:	thickbrick: that is on linux right?
[14:53]	:	yes, 32 bit, non-standalone build.
[14:53]	:	ok kewl
[14:54]	:	So you are using a viewer with the patch applied, constantly?
[14:54]	:	no
[14:54]	:	(I'm running 1.4.1 Release now... needed to have a feeling for how it performs)
[14:54]	:	SNOW-802 appears to be working
[14:54]	:	o/
[14:54]	:	Thickbrick: why not?
[14:54]	:	You don't use quilt?
[14:55]	:	because my system is messy and and I have a ton of different viewer builds
[14:55]	:	Thickbrick: https://wiki.secondlife.com/wiki/Development_Environment_for_Multiple_Viewers
[14:55]	:	I'll test it more seriously
[14:55]	:	How can the viewer 1 then 2 then back to 1 best be handled
[14:56]	:	Very clean! :)
[14:57]	:	v2 royally screwed over my avatar setting
[14:57]	:	i know one thing with a lot of difficult work was finaly able to just about to completely build useing vs 2008
[14:57]	:	hikaru:/usr/src/secondlife/viewers/snowglobe>lsdiff-archive/ gdbinit.in jira-archive/ snowglobe-1.4.1/ snowglobe-1.x-i686-svn/ snowglobe-1.x-svn/ snowglobe-2.x-i686-svn/ snowglobe-2.x-svn/
[14:57]	:	every viewer: just 'cd theviewerdir; configure; make'
[14:58]	:	Nicky, SNOW-595 and SNOW-790, I guess
[14:58]	:	http://jira.secondlife.com/browse/SNOW-595 [#SNOW-595] I tire of Viewer 2 and Snowglobe 2 chewing up Snowglobe 1.4 setting files so I propose making Snowglobe 1.4 use a different directory for settings.
[14:58]	:	http://jira.secondlife.com/browse/SNOW-790 [#SNOW-790] Snowglobe 1.x and 2.x installers should use different installation directories
[14:58]	:	that i can handle it the operations
[14:58]	:	anybody have any clue why deletijg objects can be 10 orders of magnitute slower? was some common type destructor changes, something about heap that got "fixed"?
[14:58]	:	hmm ... can it have to do with the fixed static object cache, maybe?
[14:59]	:	(I don't think so, though)
[14:59]	:	Latif: it can happen when a linear search is done in a list of to-be-freed objects, for every object... so a double loop over many objects and then doing something stupid in the center of the loops.
[14:59]	:	robin you had a chance to get your head around the maze of python scripts used for packaging the viewer?
[14:59]	:	no, seems de-allocating stuff in sg.1x can get be 10^6 slower
[14:59]	:	umm
[15:00]	:	Aleric, that doesn't explain why snowglobe has this, but not 1.23.5
[15:00]	:	Ok.... help me to reprocude it. I'm using 1.4.1 now. What to do?
[15:00]	:	deleting objects is inherently expensive
[15:00]	:	it might be that some parenting safety check that got introduced upstream at some point is slowing it down, though
[15:01]	:	why not limit the number of deletes per frame?
[15:01]	:	what got introduced upstream? this problem *only* happens in SG
[15:01]	:	I got a stable FPS of 32 now
[15:01]	:	(there are one-way pointers to parents, so when removing an object you have to iterate over all other objects to make sure you're not breaking any links)
[15:02]	:	Latif, I don't think thouched that part in SG.
[15:02]	:	ew. Sounds like two way pointers could pay off here quickly?
[15:02]	:	yes
[15:02]	:	(possibly, I looked at it about 4 months ago, and I am clueless regardless)
[15:03]	:	Thickbrick, there is something wrong in sg 1.x that does not happen in 1.23.5 official, i'm asking if anyone has an idea about what my cause this, something about changing allocation / deallocaition of stuff. I have no idea what might be causing it
[15:03]	:	Latif: reading SNOW-467 .. that is in the middle of a teleport, not after it(?)
[15:03]	:	well tc folks im going to be diving in to some python scripts used for packaging the viewer :/
[15:03]	:	I guess that calls for some diffing
[15:04]	:	Aleric, i can repro it during the teleport, or after it, or just teleporting from one side of the sim to the next
[15:04]	:	tc WolfPup
[15:04]	:	since when does snowglobe have that issue, Latif? maybe we can do some bisecting to see what changed
[15:04]	:	ok i'm running as well, but yea some diffs against 1.23 may be helpful
[15:04]	:	or sometimes even just rotating avatar around while stuff is loading after the tp
[15:04]	:	Latif, how long is the freeze when you tp inside an island sim?
[15:05]	:	take care robin
[15:05]	:	more like hope i survive the dive ;)
[15:05]	:	TB, i get 0.05 fps so like 3 frames per minute
[15:05]	:	eventually i get "too many messages to processs in a frame"
[15:05]	:	TP me somewhere
[15:05]	:	ask me to look is certain directions whatever
[15:05]	:	(i think it says 400 msgs max per frame)
[15:06]	:	look in*
[15:06]	:	the problems with SNOW-467 is that it's doing all the kills in a single frame
[15:06]	:	TBB no that is not the problem
[15:06]	:	........
[15:07]	:	Are you going to show me how to reprocude it or not?
[15:07]	:	the problem is that the kills take like gazillion times more to execute in sg than in 1.23.5 or 2.x
[15:07]	:	Aleric, there is no 100% repro
[15:07]	:	it would have been eaiser if there was ;)
[15:07]	:	lol
[15:07]	:	I NEVER saw it before
[15:07]	:	if i sneeze you will braek your leg
[15:07]	:	so... lets do something
[15:07]	:	Latif, did you see that in fast timers?
[15:07]	:	Aleric, you never run release build
[15:07]	:	meeting is over anyway it's 3:07
 
Generated with SLog Wikifier