[opensource-dev] Review Request: STORM-1546 Crash in LLSecAPIBasicHandler::getCertificateStore
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/435/ --- Review request for Viewer and David Parks. Summary --- Fixed a crash caused by a race condition in LLRefCount. Reason: secapiSSLCertVerifyCallback() seems to be called simultaneously by multiple threads, which causes a race condition in LLRefCount::ref/unref() methods. The reference counter in LLSecAPIBasicHandler::mStore goes to zero, and the object gets destroyed. Fix: Derive LLCertificateStore from LLThreadSafeRefCount instead of LLRefCount, which should fix the race condition. Note: The LLThreadSafeRefCount constructor is private, so we have to wrap instances of the class with LLPointer. This addresses bug STORM-1546. http://jira.secondlife.com/browse/STORM-1546 Diffs - indra/newview/llsecapi.h 8f15e5a13e8f indra/newview/llsechandler_basic.cpp 8f15e5a13e8f Diff: http://codereview.secondlife.com/r/435/diff Testing --- Thanks, Vadim ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Collecting DIDN'T CRASH data
It's not a daft idea. It's good science. On 9/08/2011 2:24 AM, Lee ponzu wrote: > I just had a sort of strange idea, but maybe this is alrady common > practice. Just thought I would ask. > > Collect data about viewers that didn't crash. After some time cutoff, > send the didn't crash data (with permission of the user, of course) to > a repository. > > Then, when you have a bunch of Crash Reports, you could compare them > to the didn't crash reports from similar hardware/OS/Version, and > maybe some pattern would pop out. Such as VBO *and* AA crashes, or > whatever. > > Just a thought. Cannot stop my brain. Best I can do is to not > inflict it on everyone else too often. You all owe me more than you > know. 8-) > > ponzu > > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Collecting DIDN'T CRASH data
On Mon, Aug 8, 2011 at 9:24 AM, Lee ponzu wrote: > I just had a sort of strange idea, but maybe this is alrady common > practice. Just thought I would ask. > > Collect data about viewers that didn't crash. After some time cutoff, send > the didn't crash data (with permission of the user, of course) to a > repository. > > Then, when you have a bunch of Crash Reports, you could compare them to the > didn't crash reports from similar hardware/OS/Version, and maybe some > pattern would pop out. Such as VBO *and* AA crashes, or whatever. > > Just a thought. Cannot stop my brain. Best I can do is to not inflict it > on everyone else too often. You all owe me more than you know. 8-) > Data is collected about viewer sessions that end in a successful logout, and it's examined in much the manner you propose. I believe the aggregate data is shared with Third Party Viewer teams and/or at the Open Source office hours. I'm not sure if the lab has shared a recent breakdown against different OSes and graphic chipsets, but that could be a good thing to ask for if anyone's focussing on graphics or stability. -- Brian McGroarty | Linden Lab Sent from my Newton MP2100 via acoustic coupler ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: STORM-1546 Crash in LLSecAPIBasicHandler::getCertificateStore
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/435/#review960 --- Ship it! Looks good -- make sure to ask QA to do a performance A/B test to make sure this doesn't introduce frame stalls. - David On Aug. 9, 2011, 12:55 p.m., Vadim ProductEngine wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/435/ > --- > > (Updated Aug. 9, 2011, 12:55 p.m.) > > > Review request for Viewer and David Parks. > > > Summary > --- > > Fixed a crash caused by a race condition in LLRefCount. > > Reason: > secapiSSLCertVerifyCallback() seems to be called simultaneously by multiple > threads, > which causes a race condition in LLRefCount::ref/unref() methods. > The reference counter in LLSecAPIBasicHandler::mStore goes to zero, and the > object gets destroyed. > > Fix: > Derive LLCertificateStore from LLThreadSafeRefCount instead of LLRefCount, > which should fix the race condition. > > Note: > The LLThreadSafeRefCount constructor is private, so we have to wrap instances > of the class with LLPointer. > > > This addresses bug STORM-1546. > http://jira.secondlife.com/browse/STORM-1546 > > > Diffs > - > > indra/newview/llsecapi.h 8f15e5a13e8f > indra/newview/llsechandler_basic.cpp 8f15e5a13e8f > > Diff: http://codereview.secondlife.com/r/435/diff > > > Testing > --- > > > Thanks, > > Vadim > > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Collecting DIDN'T CRASH data
Good to hear. But I was also thinking of the graphics settings. There are all those proven and unproven theories about VBO on, but not with AA, and only on alternate TuesdaysI know I have some of them myself. I have convinced myself that VBO is bad on my ATI 2600Pro iMac. On Tue, Aug 9, 2011 at 4:29 PM, Brian McGroarty wrote: > > Data is collected about viewer sessions that end in a successful logout, > and it's examined in much the manner you propose. I believe the aggregate > data is shared with Third Party Viewer teams and/or at the Open Source > office hours. I'm not sure if the lab has shared a recent breakdown against > different OSes and graphic chipsets, but that could be a good thing to ask > for if anyone's focussing on graphics or stability. > > -- > Brian McGroarty | Linden Lab > Sent from my Newton MP2100 via acoustic coupler > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Collecting DIDN'T CRASH data
Not that I have allot of standing to voice my thoughts in the matter, but I would like to see some detailed stats and some analysis on other things besides crashes. Freezes, disconnects, stalls, and memory usage come to mind. In fact more then just analysis, I would love to see some cutting and pasting of differant versions of relevant codes from different viewers that had wildly different behaviors doing the same tasks For those that need an example to illustrate my point or understand my reasoning I include an example below. For the rest, I will simply say that I think it would be both enlightening and productive to play Frankenstein's Creator with the various viewer codes... example: Lets say for some reason a particular build of firestorm is more stable then the snowstorm build it was based off of, but that it tends to both freeze up more and use more memory. (This actually happens to have been true for some builds.) Now lets say that a mythological viewer we will call Bluestorm comes along built of that same snowstorm build which uses less memory then either firestorm or snowstorm, has slightly lower freezing then firestorm but more then snowstorm, and crashes more then both but almost never stalls or disconnects. Lets go on to say hypothetically, a study showed that bluestorm maybe had less stalls or disconnects because it had a lower rate of failure because of how the viewer side code handled some part of group or inventory calls or something but that a small bug in this same code was responsible for the higher crash rates but firestorm already had the fix for that. Maybe this study also could show that the memory usage of Snowstorm and Firestorm revealed that some of the insane memory usage tended to happen when people maximized the fifth group or individual im window after receiving 100+ new lines to minimized conversations and something in Bluestorm was changed so that didn't happen. I think some real valuable data could come from taking a month or two and looking at what causes the differences in all of these areas of performance and possibly doing some swapouts of the various versions of the relevant code chunks and seeing what works best. I bet a lot of wildly different things come about because of little corrections people don't even think about as well as just as a result of preparing code for integration of other features. Maybe those features might not need to be actually integrated for some of those changes to be helpful. Date: Tue, 9 Aug 2011 17:10:54 -0400 From: lee.po...@gmail.com To: s...@lindenlab.com CC: opensource-dev@lists.secondlife.com Subject: Re: [opensource-dev] Collecting DIDN'T CRASH data Good to hear. But I was also thinking of the graphics settings. There are all those proven and unproven theories about VBO on, but not with AA, and only on alternate TuesdaysI know I have some of them myself. I have convinced myself that VBO is bad on my ATI 2600Pro iMac. On Tue, Aug 9, 2011 at 4:29 PM, Brian McGroarty wrote: Data is collected about viewer sessions that end in a successful logout, and it's examined in much the manner you propose. I believe the aggregate data is shared with Third Party Viewer teams and/or at the Open Source office hours. I'm not sure if the lab has shared a recent breakdown against different OSes and graphic chipsets, but that could be a good thing to ask for if anyone's focussing on graphics or stability. -- Brian McGroarty | Linden Lab Sent from my Newton MP2100 via acoustic coupler ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Collecting DIDN'T CRASH data
> Data is collected about viewer sessions that end in a successful logout, and > it's examined in much the manner you propose. I believe the aggregate data > is shared with Third Party Viewer teams and/or at the Open Source office > hours. I'm not sure if the lab has shared a recent breakdown against > different OSes and graphic chipsets, but that could be a good thing to ask > for if anyone's focussing on graphics or stability. I think I've tooted this horn on this list before, but since the subject has come up again, I'd like to bring up a Jira I created that requests information like this be made available to the public. https://jira.secondlife.com/browse/WEB-2596 It would greatly aid content developers, as well as open source developers, by letting them know what people's computers are capable of, what features they have turned on, and what things people can and can't actually use. I recently built a tool that requires Media on a Prim, only to find out (by a third party source, since LL doesn't make this information publicly available that I'm aware of) that only around 50% of users have a viewer capable of even using MOAP. Some day I hope to have time to work up a solution to this myself. But I'm not going to cry if someone beats me to it. Stickman ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
