[kokua-dev] Kokua Linux64 debug build

Nicky Perian nickyperian at yahoo.com
Wed Jun 6 05:29:23 PDT 2012


hi,

I finally got over my first time use and fumbling with Valgrind. I have some concerns about the warning in the manual about using highly optimized code resulting in false reports. Every report I saw related to library code of which I have no knowledge of how it was compiled however, I would think a libraries could be complied with very tight optimization.

So, I am thinking that if the memory corruptions is so bad that Valrind cannot even proceed to the point of being fully in world that the viewer would crash or report unreleased memory over time.

Last night I logged to SL and with an anti idle script running stayed sitting in my sky box.
The System Monitor at boot showed 363.5 MiB.
With the login page showing 514.5 to 514.9 MiB. 
While in world sitting 756.4 to 757.5 MiB.
Nine hours after 760.0-760.5 MiB. About a 3MiB gain.
At log out 328.1 MiB.
A drop of ~30MiB.


My thoughts are that from a login and main loop perspective the memory handling is in pretty good shape.

If there are other tools that can be linked into the viewer for additional checking I'll be glad to try.



Nicky





 






  



>________________________________
> From: Emily Björk <bjoerk.emily at gmail.com>
>To: Nicky Perian <nickyperian at yahoo.com> 
>Sent: Tuesday, June 5, 2012 6:01 PM
>Subject: Re: Kokua Linux64 debug build
> 
>Hmmm no, that can not be correct. According to your log:
>
>==17117== HEAP SUMMARY:
>==17117==     in use at exit: 0 bytes in 0 blocks
>==17117==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
>
>So you never allocated any memory... that can't be right :) And
>calling it like you did:
>
>> valgrind -v --leak-check=yes ./kokua
>
>Runs much too fast, valgrind has a performance penalty of 10x -1000x
>depending on what you're doing. I'm pretty sure you only ran it on the
>bash script, and not on the do-not-run-directly binary.
>
>I believe you should use
>LL_WRAPPER="valgrind --log-file=valgrindLog-%p.log" ./kokua
>
>/Emily
>
>On Jun 6, 2012 12:42 AM, "Nicky Perian" <nickyperian at yahoo.com> wrote:
>>
>> Attached is a valgrind log from my system using the current tip. As noted in the log there are no errors, Just a couple substitutions. I think the difference is in the way it is called.
>> I  cd into in may case it is the packaged directory then:
>>
>> valgrind -v --leak-check=yes ./kokua
>>
>> kokua is the startup wrapper script.
>>
>>
>> ________________________________
>> From: Emily Björk <bjoerk.emily at gmail.com>
>> To: Nicky Perian <nickyperian at yahoo.com>
>> Sent: Tuesday, June 5, 2012 3:13 PM
>> Subject: Re: Kokua Linux64 debug build
>>
>> Here is the valgrind output from 3.3.1-22581. Most things were working
>> and didn't crash but the output from Valgrind is indicative of
>> something not being right in respect to memory handling.
>>
>> Thanks for your hard work :)
>>
>> 2012/6/5 Nicky Perian <nickyperian at yahoo.com>:
>> > no rebuild was needed forgot I hadn't taken this down.
>> >
>> > https://bitbucket.org/NickyP/kokua/downloads/Kokua-3.3.1-22581-97ca4c6e0e4fExperimental-Linux64.tar.bz2
>> >
>> > ________________________________
>> > From: Emily Björk <bjoerk.emily at gmail.com>
>> > To: Nicky Perian <nickyperian at yahoo.com>
>> > Sent: Tuesday, June 5, 2012 1:30 PM
>> >
>> > Subject: Re: Kokua Linux64 debug build
>> >
>> > Sure I'll test  :-)
>> > On Jun 5, 2012 8:29 PM, "Nicky Perian" <nickyperian at yahoo.com> wrote:
>> >
>> >  a good bit of llviewerdisplay and llappviewer.cpp where touched with Grid
>> > manger changesets. I'll update back before those and link you another
>> > install if you are willing to test.
>> >
>> >
>> > ________________________________
>> > From: Emily Björk <bjoerk.emily at gmail.com>
>> > To: Nicky Perian <nickyperian at yahoo.com>
>> > Sent: Tuesday, June 5, 2012 1:17 PM
>> > Subject: Re: Kokua Linux64 debug build
>> >
>> > Oh! I forgot to say, when running through valgrind, despite all the
>> > errors, I did succeed at logging in which is another sign at memory
>> > corruption.
>> >
>> > 2012/6/5 Emily Björk <bjoerk.emily at gmail.com>:
>> >> Okay, I've gone over the valgrind logs. Among the more interesting
>> >> ones are this:
>> >>
>> >> ==6715== Invalid read of size 4
>> >> ==6715==    at 0xB0E69F5: ??? (in /usr/lib/libGLcore.so.195.36.31)
>> >> ==6715==    by 0x1001562: LLGLDisable::LLGLDisable(unsigned int)
>> >> (llgl.h:298)
>> >> ==6715==    by 0x1C7E247: LLGLSDefault::LLGLSDefault() (llglstates.h:83)
>> >> ==6715==    by 0x1C75459: display(int, float, int, int)
>> >> (llviewerdisplay.cpp:251)
>> >> ==6715==    by 0xDF32EC: LLAppViewer::mainLoop() (llappviewer.cpp:1292)
>> >> ==6715==    by 0x20AE477: main (llappviewerlinux.cpp:100)
>> >> ==6715==  Address 0x178bc8dc is not stack'd, malloc'd or (recently) free'd
>> >>
>> >> That address, 0x178bc8dc and nearby addresses, occurs frequently in
>> >> the logs. I'm guessing since the address is not inside of a allocated
>> >> or stacked memory region, it is the result of some pointer arithmetic
>> >> gone wrong (or that you've at some point accidentally written over
>> >> your stack frame pointer, there are some odd changes to the stack
>> >> pointer in the log as well). Further, said pointer is then passed to
>> >> OpenGL where the following 10 thousand or so errors come from.
>> >>
>> >> Here is another one that I think might be related:
>> >>
>> >> ==6715== Invalid read of size 4
>> >> ==6715==    at 0xB1951FD: ??? (in /usr/lib/libGLcore.so.195.36.31)
>> >> ==6715==    by 0x100C590:
>> >> LLTexUnit::setTextureColorBlend(LLTexUnit::eTextureBlendOp,
>> >> LLTexUnit::eTextureBlendSrc, LLTexUnit::eTextureBlendSrc)
>> >> (llrender.h:186)
>> >> ==6715==    by 0x25BDD17: gl_draw_scaled_image_with_border(int, int,
>> >> int, int, LLTexture*, LLColor4 const&, int, LLRectBase<float> const&,
>> >> LLRectBase<float> const&) (llui.cpp:535)
>> >> ==6715==    by 0x25FF3BC: LLUIImage::drawSolid(int, int, int, int,
>> >> LLColor4 const&) const (lluiimage.cpp:104)
>> >> ==6715==    by 0x24DF064: LLUIImage::drawSolid(LLRectBase<int> const&,
>> >> LLColor4 const&) const (lluiimage.h:61)
>> >> ==6715==    by 0x25FF437: LLUIImage::drawBorder(int, int, int, int,
>> >> LLColor4 const&, int) const (lluiimage.cpp:112)
>> >> ==6715==    by 0x2383E9F: LLUIImage::drawBorder(LLRectBase<int>
>> >> const&, LLColor4 const&, int) const (lluiimage.h:65)
>> >> ==6715==    by 0x23825B8: LLButton::drawBorder(LLUIImage*, LLColor4
>> >> const&, int) (llbutton.cpp:928)
>> >> ==6715==    by 0x238193C: LLButton::draw() (llbutton.cpp:753)
>> >> ==6715==    by 0x262C116: LLView::drawChildren() (llview.cpp:1112)
>> >> ==6715==    by 0x262BF5F: LLView::draw() (llview.cpp:1082)
>> >> ==6715==    by 0x23D0D79: LLFloater::draw() (llfloater.cpp:1837)
>> >> ==6715==  Address 0x178bc8e0 is not stack'd, malloc'd or (recently) free'd
>> >>
>> >> There are also a lot of references to:
>> >> /usr/share/fonts/truetype/ttf-liberation/LiberationSerif-Regular.ttf.
>> >> Maybe there is some problem with the font rendering? If the font
>> >> you're loading isn't what you're expecting it to be?
>> >> More references to other fonts...
>> >> /usr/share/fonts/truetype/kiloji/kiloji_p.ttf
>> >>
>> >> I'm attaching the full log (it got truncated, too many errors)
>> >>
>> >> /Emily
>> >>
>> >> 2012/6/5 Emily Björk <bjoerk.emily at gmail.com>:
>> >>> Hi again!
>> >>>
>> >>> I just checked with LDD, all dynamic link libraries are found.
>> >>>
>> >>> I'm running a test with valgrind, it seems you have some memory
>> >>> issues. I believe it's more of a fluke it's working on your end. I'll
>> >>> get back to you with details.
>> >>>
>> >>> 2012/6/5 Emily Björk <bjoerk.emily at gmail.com>:
>> >>>> Yes, it appears it is the same base system. And I checked, it is squeezy
>> >>>> that I'm running.
>> >>>>
>> >>>> Oh well, I guess it wouldn't have helped that much. I'm not a big fan of
>> >>>> autobuild by the way ><
>> >>>>
>> >>>> I'll send you more data after I'm done with work for today.
>> >>>>
>> >>>> On Jun 5, 2012 5:27 PM, "Nicky Perian" <nickyperian at yahoo.com> wrote:
>> >>>>>
>> >>>>> bill at Bill-HP:~$ uname -a
>> >>>>> Linux Bill-HP 2.6.32-5-amd64 #1 SMP Sun May 6 04:00:17 UTC 2012 x86_64
>> >>>>> GNU/Linux
>> >>>>>
>> >>>>> Can you check if we are on the same base system. I think we are and
>> >>>>> this
>> >>>>> may be a case where the my build environment has a different library
>> >>>>> that
>> >>>>> may need included in the install.
>> >>>>>
>> >>>>> I can't seem to get -ggdb3 flag to pass through cmake. I replace it in
>> >>>>> add_definitions but it is set as -g in CMakeCache.txt. If I pass it on
>> >>>>> the
>> >>>>> the autobuild build -c RelWithDebInfoOS -- -j 4 -ggdb3 as an over
>> >>>>> ridding
>> >>>>> switch it bombs on everthing past the first g.
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> ________________________________
>> >>>>> From: Emily Björk <bjoerk.emily at gmail.com>
>> >>>>> To: Nicky Perian <nickyperian at yahoo.com>
>> >>>>> Sent: Monday, June 4, 2012 8:05 PM
>> >>>>> Subject: Re: Kokua Linux64 debug build
>> >>>>>
>> >>>>> Hi!
>> >>>>> I'm using debian stable (I don't keep up with the code names). I
>> >>>>> believe
>> >>>>> that a DNS problem is highly unlikely seeing as all other viewers
>> >>>>> (firestorm, imprudence) worked flawlessly during the same time period.
>> >>>>> I
>> >>>>> will investigate further tomorrow tough.
>> >>>>> There is no VMs involved. It's pretty much your standard 64 bit debian
>> >>>>> stable instal. I tried to get a dump of the stack variables but gdb
>> >>>>> wouldn't
>> >>>>> find anything... I wonder what is up with that... What flags did you
>> >>>>> build
>> >>>>> with? I usually build with -ggdb3 when I want to debug a segmentation
>> >>>>> problem.
>> >>>>> Looking at the trace, it wasn't a null pointer dereference so this
>> >>>>> leads
>> >>>>> me to suspect memory corruption (dangling pointer or premature free),
>> >>>>> I'll
>> >>>>> see if I can run it in valgrind and get back to you tomorrow.
>> >>>>> /Emily
>> >>>>> On Jun 5, 2012 2:03 AM, "Nicky Perian" <nickyperian at yahoo.com> wrote:
>> >>>>>
>> >>>>> hi,
>> >>>>> thanks for testing and the feedback.
>> >>>>> What linux distro are you using?
>> >>>>> Did you recently install it? The reason I ask is I recently installed
>> >>>>> Debian squeeze and repeatedly received output along the lines of your
>> >>>>> first
>> >>>>> case. Evidently Debian's installer  left my router with a corrupted DNS
>> >>>>> Cache that only showed problems with SL/Opensim login.
>> >>>>> Do a web search on flush DNS Cache. It can't hurt to go ahead and flush
>> >>>>> it.
>> >>>>>
>> >>>>> Next time you bring viewer up try to Help->About Kokua and use copy to
>> >>>>> clipboard and then email the clipboard contents.
>> >>>>>
>> >>>>> Now to the second problem.
>> >>>>>
>> >>>>> Are you running inside a Virtual Machine? I use a virtual machine for
>> >>>>> linux32 bit and get similar errors. Sometimes I log on and sometimes
>> >>>>> not.
>> >>>>>
>> >>>>> I hope you do not take offense at some of the ground work
>> >>>>> questions. Obviously you are well versed in linux or I would not have
>> >>>>> received the stack trace output.
>> >>>>>
>> >>>>> Thanks again,
>> >>>>>
>> >>>>> Nicky
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> ________________________________
>> >>>>> From: Emily Björk <bjoerk.emily at gmail.com>
>> >>>>> To: Nicky Perian <nickyperian at yahoo.com>
>> >>>>> Sent: Monday, June 4, 2012 4:30 PM
>> >>>>> Subject: Re: Kokua Linux64 debug build
>> >>>>>
>> >>>>> I had two scenarios happen.
>> >>>>>
>> >>>>> 1) Login failed with a time-out then I got a segmentation fault.
>> >>>>>
>> >>>>> 2) Login succeeded and then segmentation fault.
>> >>>>>
>> >>>>> The login didn't succeed until I edited preferences to set network
>> >>>>> speed to max and graphics to lowest, don't know which parameter
>> >>>>> exactly affected the login (I changed all at once, could also have
>> >>>>> been a network fluke). I'm guessing the debug build was too slow on
>> >>>>> login so it timed out if I had things turned up. But that's just
>> >>>>> speculations on my part.
>> >>>>>
>> >>>>> I'm attaching the stack traces for both cases.
>> >>>>>
>> >>>>> /Emily
>> >>>>>
>> >>>>> 2012/6/4 Emily Björk <bjoerk.emily at gmail.com>:
>> >>>>> > Thank you, I will get back to you with results later today (worst
>> >>>>> > case, tomorrow evening). I'm running some scientific simulations and
>> >>>>> > can't test at the moment.
>> >>>>> >
>> >>>>> > /Emily
>> >>>>> >
>> >>>>> > 2012/6/4 Nicky Perian <nickyperian at yahoo.com>
>> >>>>> >>
>> >>>>> >>
>> >>>>> >>
>> >>>>> >> https://bitbucket.org/NickyP/kokua-gm/downloads/Kokua-3.3.1-98818c9b7fb5-ExpRelWithDebInfo-Linux64.tar.bz2
>> >>>>> >>
>> >>>>> >> upload is slow today.
>> >>>>> >>
>> >>>>> >> You likely will need to erase your settings as the print line number
>> >>>>> >> setting may carry over from the release version. $(HOME)/.kokua is
>> >>>>> >> where
>> >>>>> >> settings reside.
>> >>>>> >>
>> >>>>> >> Thanks for testing.
>> >>>>> >>
>> >>>>> >> Nicky
>> >>>>> >>
>> >>>>> >> ________________________________
>> >>>>> >> From: Emily Björk <bjoerk.emily at gmail.com>
>> >>>>> >> To: nickyperian at yahoo.com
>> >>>>> >> Sent: Sunday, June 3, 2012 3:23 PM
>> >>>>> >> Subject: Kokua Linux64 debug build
>> >>>>> >>
>> >>>>> >> Here's an email :)
>> >>>>> >>
>> >>>>> >>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>
>> >
>> >
>> >
>> >
>>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kokuaviewer.org/pipermail/kokua-dev-kokuaviewer.org/attachments/20120606/c60a0141/attachment-0001.htm>


More information about the kokua-dev mailing list