[opensource-dev] how to read minidumps
hi, I'm pretty sure noone at LL is interested in the minidumps from my TPV, so I'll have to read them myself... how do i do that? bye, LC ___ 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] how to read minidumps
On Tuesday 04 October 2011 09:31:00 Lance Corrimal wrote: > hi, > > I'm pretty sure noone at LL is interested in the minidumps from my > TPV, so I'll have to read them myself... how do i do that? > At least on the Linux side, breakpad provides minidump_stackwalk, which takes a minidump file and a symbols file and produces a stack trace. That executable is not provided with the linden-packaged breakpad though. You will also need to make sure the symbols file you are using is from the same build that produced the minidump. See http://code.google.com/p/google- breakpad/wiki/LinuxStarterGuide#Processing_the_minidump_to_produce_a_stack_trace -- Thickbrick ___ 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: Texture Picker: Making the preview "widget" a little more flexible.
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/474/ --- (Updated Oct. 4, 2011, 7:26 a.m.) Review request for Viewer and Richard Nelson. Summary --- Update: would appreciate a LL yes or no to this, as it's one of the issues that's holding back STORM-64. Texture picker's preview box was never a real widget. It had no XUI presence so the XUI designers had no control over it. Also, it's height depended on the it's parent floater's min size which meant that increasing the min size distorted the preview box, which must be at a 1:1 ratio. I have modified the code in a way that a) makes the preview box no longer reliant on any of the floater's own parameters. b) gives the XUI designers three parameters that affect the preview box specifically: left, top, and size. (size is both the size from left to right, and from top to bottom, keeping it locked to 1:1) The changes are only noticeable to coders and xui designers, not the users. note: It is still not a real widget and it still lacks a follow, layout, delta and any other widget specific abilities. Diffs - indra/newview/lltexturectrl.cpp d36e49ee2651 indra/newview/skins/default/xui/en/floater_texture_ctrl.xml d36e49ee2651 Diff: http://codereview.secondlife.com/r/474/diff Testing --- The box seems to behave exactly as it did before. Changing the indicated left, top, and size values in the appropriate xml file does affect the relevant properties. Thanks, Vaalith ___ 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] how to read minidumps
On Tue, 4 Oct 2011 12:23:51 +0200, Thickbrick Sleaford wrote:
> On Tuesday 04 October 2011 09:31:00 Lance Corrimal wrote:
> > hi,
> >
> > I'm pretty sure noone at LL is interested in the minidumps from my
> > TPV, so I'll have to read them myself... how do i do that?
>
> At least on the Linux side, breakpad provides minidump_stackwalk,
> which takes a minidump file and a symbols file and produces a stack
> trace. That executable is not provided with the linden-packaged
> breakpad though. You will also need to make sure the symbols file
> you are using is from the same build that produced the minidump.
We've got a saying for this kind of silliness, in France:
"Pourquoi faire simple quand on peut faire compliqué ?"
("Why doing it the simple way when you can find a complex way to
do it ?")
I guess the stack_trace.log file what just too simple in LL's view...
* rolls eyes and shakes head, sighing deeply *
Henri.
___
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] Mesh viewers and tcmalloc issues
On 10/02/2011 12:45 PM, Henri Beauchamp wrote: > On Sun, 02 Oct 2011 10:20:58 -0400, Mike Chase wrote: > >> One more note. I have 16gb of memory on this system so the large heap >> really isnt a problem per-se. > It is, because you will not be able to get more than 3Gb of virtual > memory per process, and when this virtual space gets fragmented (which > *does* happen during "long" sessions with tcmalloc and its default > release rate), your viewer will crash trying to allocate the next > unfragmented space that won't fit its currently allocated but > fragmented pool. Is there a JIRA filed for this somewhere I can follow? In the meantime I may try running the heap profiler. I beginning to suspect not so much the allocator and more so a memory leak somewhere. Mike ___ 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] how to read minidumps
The Shadok is strong in this one...
On 04/10/2011, Henri Beauchamp wrote:
> On Tue, 4 Oct 2011 12:23:51 +0200, Thickbrick Sleaford wrote:
>
>> On Tuesday 04 October 2011 09:31:00 Lance Corrimal wrote:
>> > hi,
>> >
>> > I'm pretty sure noone at LL is interested in the minidumps from my
>> > TPV, so I'll have to read them myself... how do i do that?
>>
>> At least on the Linux side, breakpad provides minidump_stackwalk,
>> which takes a minidump file and a symbols file and produces a stack
>> trace. That executable is not provided with the linden-packaged
>> breakpad though. You will also need to make sure the symbols file
>> you are using is from the same build that produced the minidump.
>
> We've got a saying for this kind of silliness, in France:
> "Pourquoi faire simple quand on peut faire compliqué ?"
> ("Why doing it the simple way when you can find a complex way to
> do it ?")
>
> I guess the stack_trace.log file what just too simple in LL's view...
> * rolls eyes and shakes head, sighing deeply *
>
> Henri.
> ___
> 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] Mesh viewers and tcmalloc issues
On 2011-10-03 16:17, Moriz Gupte wrote: > Am wondering if anyone from Linden Lab can comment on this thread. > This is such an important issue regarding mesh viewers and mesh based > economy. Many mesh builders are reverting products back to sculpty > versions because the majority of clients refuse to use the latest > viewers that support mesh because of the significant fps drops. I'm just getting caught up on the list after a few days spent firefighting will bring it to the attention of the mesh team. ___ 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
[opensource-dev] Open Development User Group schedule change
I've moved my Wednesday afternoon UG meeting to Tuesday, and a half hour later See https://wiki.secondlife.com/wiki/Project_Snowstorm/Calendar ___ 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: Enable legacy viewer C++ tests in indra/test.
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/479/ --- (Updated Oct. 4, 2011, 10:23 a.m.) Review request for Viewer and Nat Goodspeed. Changes --- Added JIRA and repo containing the changes. Summary --- As part of the Linden Lab automation hackathon, I finally had time to re-enable the tests located in the indra/test directory. These tests are currently not being built or run as part of a standard viewer build and haven't at least since we switched over from subversion. I copied over a few tests from the corresponding server test repository and also fixed some tests that had been rendered unbuildable by various code changes to the viewer. These tests can be disabled from running (but not building) by disabling the standard LL_TESTS cmake configuration variable. llevents_tut.cpp proved to be an interesting challenge to get to pass on our Linux build servers. With the Debian Lenny version of the gcc build toolchain, if an exception is located in a different dynamic library (.so) file as the code that is causing the exception, the exception will not be caught. My workaround was borrowed from the llmessage unit tests and expanded upon to allow the monitoring of the string from the caught exception. This addresses bug STORM-1634. http://jira.secondlife.com/browse/STORM-1634 Diffs - indra/test/llevents_tut.cpp 656d988266e8 indra/test/llapp_tut.cpp PRE-CREATION indra/CMakeLists.txt 656d988266e8 indra/test/CMakeLists.txt 656d988266e8 indra/test/io.cpp 656d988266e8 indra/test/llhttpclient_tut.cpp 656d988266e8 indra/test/lliohttpserver_tut.cpp 656d988266e8 indra/test/llsd_new_tut.cpp 656d988266e8 indra/test/llsdmessagebuilder_tut.cpp 656d988266e8 indra/test/lltemplatemessagebuilder_tut.cpp 656d988266e8 Diff: http://codereview.secondlife.com/r/479/diff Testing --- I built and ran this code on recent versions of all three platforms with no error. When it failed to build in teamcity, I also built it on a lenny system by hand until I had fixed the exception handling issue, then ran all of the tests 100 times in a row on the same lenny machine with no test failures. The tests have run successfully in Teamcity for each revision since the fix for the exception handling code. Thanks, Log ___ 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: Texture Picker: Making the preview "widget" a little more flexible.
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/474/#review1041 --- Please do not use localization strings to parameterize a widget. Better to use a place holder and then call getChildView on it and use the rect of that view for displaying the texture preview. - Richard On Oct. 4, 2011, 7:26 a.m., Vaalith Jinn wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/474/ > --- > > (Updated Oct. 4, 2011, 7:26 a.m.) > > > Review request for Viewer and Richard Nelson. > > > Summary > --- > > Update: would appreciate a LL yes or no to this, as it's one of the issues > that's holding back STORM-64. > > > Texture picker's preview box was never a real widget. It had no XUI presence > so the XUI designers had no control over it. > Also, it's height depended on the it's parent floater's min size which meant > that increasing the min size distorted the preview box, > which must be at a 1:1 ratio. > > I have modified the code in a way that > a) makes the preview box no longer reliant on any of the floater's own > parameters. > b) gives the XUI designers three parameters that affect the preview box > specifically: left, top, and size. > (size is both the size from left to right, and from top to bottom, keeping it > locked to 1:1) > > The changes are only noticeable to coders and xui designers, not the users. > note: It is still not a real widget and it still lacks a follow, layout, > delta and any other widget specific abilities. > > > Diffs > - > > indra/newview/lltexturectrl.cpp d36e49ee2651 > indra/newview/skins/default/xui/en/floater_texture_ctrl.xml d36e49ee2651 > > Diff: http://codereview.secondlife.com/r/474/diff > > > Testing > --- > > The box seems to behave exactly as it did before. > Changing the indicated left, top, and size values in the appropriate xml file > does affect the relevant properties. > > > Thanks, > > Vaalith > > ___ 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] how to read minidumps
You can read the google breakpad generated dumps straight into visual
studio. I wasted so much time trying to get minidump_stackwalk and all that
on windows and they don't tell you that you can just use visual studio.
I got crash logging working on my own TPV, I send the reports to my own
crash logging server which accumulates them and provides me an interface to
check out minidumps and logs.
- Nexii Malthus
On Tue, Oct 4, 2011 at 4:55 PM, Marine Kelley wrote:
> The Shadok is strong in this one...
>
> On 04/10/2011, Henri Beauchamp wrote:
> > On Tue, 4 Oct 2011 12:23:51 +0200, Thickbrick Sleaford wrote:
> >
> >> On Tuesday 04 October 2011 09:31:00 Lance Corrimal wrote:
> >> > hi,
> >> >
> >> > I'm pretty sure noone at LL is interested in the minidumps from my
> >> > TPV, so I'll have to read them myself... how do i do that?
> >>
> >> At least on the Linux side, breakpad provides minidump_stackwalk,
> >> which takes a minidump file and a symbols file and produces a stack
> >> trace. That executable is not provided with the linden-packaged
> >> breakpad though. You will also need to make sure the symbols file
> >> you are using is from the same build that produced the minidump.
> >
> > We've got a saying for this kind of silliness, in France:
> > "Pourquoi faire simple quand on peut faire compliqué ?"
> > ("Why doing it the simple way when you can find a complex way to
> > do it ?")
> >
> > I guess the stack_trace.log file what just too simple in LL's view...
> > * rolls eyes and shakes head, sighing deeply *
> >
> > Henri.
> > ___
> > 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
>
___
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] how to read minidumps
omgwtf i want.
we gotta talk and soon.
bye,
LC
Am Dienstag, 4. Oktober 2011 schrieb Nexii Malthus:
> You can read the google breakpad generated dumps straight into
> visual studio. I wasted so much time trying to get
> minidump_stackwalk and all that on windows and they don't tell you
> that you can just use visual studio.
>
> I got crash logging working on my own TPV, I send the reports to my
> own crash logging server which accumulates them and provides me an
> interface to check out minidumps and logs.
>
> - Nexii Malthus
>
> On Tue, Oct 4, 2011 at 4:55 PM, Marine Kelley
wrote:
> > The Shadok is strong in this one...
> >
> > On 04/10/2011, Henri Beauchamp wrote:
> > > On Tue, 4 Oct 2011 12:23:51 +0200, Thickbrick Sleaford wrote:
> > >> On Tuesday 04 October 2011 09:31:00 Lance Corrimal wrote:
> > >> > hi,
> > >> >
> > >> > I'm pretty sure noone at LL is interested in the minidumps
> > >> > from my TPV, so I'll have to read them myself... how do i
> > >> > do that?
> > >>
> > >> At least on the Linux side, breakpad provides
> > >> minidump_stackwalk, which takes a minidump file and a symbols
> > >> file and produces a stack trace. That executable is not
> > >> provided with the linden-packaged breakpad though. You will
> > >> also need to make sure the symbols file you are using is from
> > >> the same build that produced the minidump.
> > >
> > > We've got a saying for this kind of silliness, in France:
> > > "Pourquoi faire simple quand on peut faire compliqué ?"
> > > ("Why doing it the simple way when you can find a complex way
> > > to do it ?")
> > >
> > > I guess the stack_trace.log file what just too simple in LL's
> > > view... * rolls eyes and shakes head, sighing deeply *
> > >
> > > Henri.
> > > ___
> > > 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
___
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
[opensource-dev] Review Request: VWR-27090 Allow Calling Cards to carry the "(link)" suffix in the Inventory pane
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/487/ --- Review request for Viewer. Summary --- Move the test for whether an item is a link outside of the test for whether an item is a calling card. This allows calling card links to carry the "(link)" suffix, but continues to deny them the "(nomod) (nocopy)" suffixes. This addresses bug VWR-27090. http://jira.secondlife.com/browse/VWR-27090 Diffs - indra/newview/llinventorybridge.cpp 88cf7d9a9d31 Diff: http://codereview.secondlife.com/r/487/diff Testing --- Compiles cleanly. Shows Calling Card links with "(link)" suffix. Thanks, Stone ___ 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] how to read minidumps
On Tue, 4 Oct 2011 21:40:49 +0100, Nexii Malthus wrote: > You can read the google breakpad generated dumps straight into visual > studio. Excepted that I develop under Linux and that the stack_trace.log file doesn't need any thrid party program neither any symbols table to tell you excatly what went wrong at the first glance... ___ 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: Texture Picker: Making the preview "widget" a little more flexible.
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/474/ --- (Updated Oct. 4, 2011, 8:11 p.m.) Review request for Viewer and Richard Nelson. Changes --- I've also considered hijacking an actual widget's rect but was not aware i could just use "view", that simplifies things! Just tested this new diff, seems to work and even seems to follow. Summary --- Update: would appreciate a LL yes or no to this, as it's one of the issues that's holding back STORM-64. Texture picker's preview box was never a real widget. It had no XUI presence so the XUI designers had no control over it. Also, it's height depended on the it's parent floater's min size which meant that increasing the min size distorted the preview box, which must be at a 1:1 ratio. I have modified the code in a way that a) makes the preview box no longer reliant on any of the floater's own parameters. b) gives the XUI designers three parameters that affect the preview box specifically: left, top, and size. (size is both the size from left to right, and from top to bottom, keeping it locked to 1:1) The changes are only noticeable to coders and xui designers, not the users. note: It is still not a real widget and it still lacks a follow, layout, delta and any other widget specific abilities. Diffs (updated) - indra/newview/lltexturectrl.cpp d36e49ee2651 indra/newview/skins/default/xui/en/floater_texture_ctrl.xml d36e49ee2651 Diff: http://codereview.secondlife.com/r/474/diff Testing --- The box seems to behave exactly as it did before. Changing the indicated left, top, and size values in the appropriate xml file does affect the relevant properties. Thanks, Vaalith ___ 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
