Difference between revisions of "SLDev-Traffic 13"

From Second Life Wiki
Jump to navigation Jump to search
m (Link to Nicholaz Beresford's page in user space)
Line 7: Line 7:


== Memory Leak Patches, Leak in libcurl ==
== Memory Leak Patches, Leak in libcurl ==
Nicholaz Beresford (corrent the name if it's wrong and combining two people! - I believe I'm uniting a RL and SL name being used interchangeably in several postings -- Soft) posted patches dealing with memory leaks, and requested peer review. The patches are found attached to {{JIRA|VWR-364}}. There was no follow-up on the list.
[[User:Nicholaz Beresford|Nicholaz Beresford]] (correct the name if it's wrong and combining two people! - I believe I'm uniting a RL and SL name being used interchangeably in several postings -- Soft) posted patches dealing with memory leaks, and requested peer review. The patches are found attached to {{JIRA|VWR-364}}. There was no follow-up on the list.


Subsequently, Nicholaz also identified a leak that may be fixed in newer versions of libcurl. Nicholaz tested with 7.16.2. It's not clear from contet whether this usurps the patch for llcurl.h in {{JIRA|VWR-805}}.
Subsequently, Nicholaz also identified a leak that may be fixed in newer versions of libcurl. Nicholaz tested with 7.16.2. It's not clear from contet whether this usurps the patch for llcurl.h in {{JIRA|VWR-805}}.

Revision as of 00:13, 28 May 2007

SLDev Traffic

sldev-traffic no 13

sldev discussions through May 25, 2007


Memory Leak Patches, Leak in libcurl

Nicholaz Beresford (correct the name if it's wrong and combining two people! - I believe I'm uniting a RL and SL name being used interchangeably in several postings -- Soft) posted patches dealing with memory leaks, and requested peer review. The patches are found attached to VWR-364. There was no follow-up on the list.

Subsequently, Nicholaz also identified a leak that may be fixed in newer versions of libcurl. Nicholaz tested with 7.16.2. It's not clear from contet whether this usurps the patch for llcurl.h in VWR-805.

More leak finds followed from Nicholaz, each without further discussion on-list:

VWR-802 fix a leak in llmessageconfig
VWR-803 fix a leak in llcallingcard
VWR-804 fix a leak in llviewerwindow
VWR-807 fix a leak in lltoolmgr.cpp
VWR-808 fix a leak in message.cpp
VWR-809 fix a leak in llviewermenu.cpp
VWR-810 fix a leak in llview.cpp
VWR-794 fix a leak in llviewerpartsource.cpp, which paralleled the problem at VWR-364

System Memory Use Spiked by High End Graphic Boards

Nicholaz also discovered that the viewer allocates system memory matching the size of the video card's texture memory, plus a small multiple. This is problematic for low memory systems with high end graphics cards. Nicholaz posted a proposed patch, attached to VWR-733 and Steve Linden took the patch up for examination. After a revision and discussion, a fix may go into the next viewer.

Nicholaz posts a related patch at VWR-778, which tackles the problem in the opposite direction, where texture buffers are too small on low-end cards. This one didn't receive attention. Callum Lerwick noted that this was related to VWR-207, and Nicholaz updated the patch to address this issue as well.

Texture Debug Console Fixes

Nicholaz again! Nicholaz posted changes that unclutter the texture-mem part of the Shift-Ctrl-3 texture debug console. The change also fixes a couple uninitialized variables. This, at VWR-779

Possible Particle Patch

Nicholaz (time for a macro!) also posted a patch, attached to VWR-418, which attempts to solve the problem of new particles not showing up when lots of infinite-life (lifespan of zero) particles are emitted. As part of the patch, Nicholaz also fixes a particle memory leak associated with region crossings/changes. There is some ambiguous discussion on the list, and it's not clear whether this patch overlaps the patch on VWR-794, also from Nicholaz.

Nicholaz is one busy Second Lifer!

Tateru Nino offered Nicholaz a kiss. :)

SL Viewer Stats Requested

LL loves keeping stats. Jason Giglio inquired as to whether SLDev could learn the breakdown on platforms in use, video cards, CPUs, average framerates, or any other information that might help the list.

To date there hasn't been a response.

Dead Code

Ben Byer notes that there seems to be a lot of dead code in the SL Viewer. Callum Lerwick points out that some of the code is common to the viewer and to server code, with Jason Giglio pointing out that shared code should exist in llcommon... the rest is fair game.

Ben made a first attempt at identifying dead code, however he was bitten by inlining making some functions appear to be unreferenced when linking. Nobody has yet tried again with inlining disabled. Meanwhile, Jacek Antonelli points to llanimalcontrols.cpp, llcape.cpp, llgenepool.cpp and llhippo.cpp as likely candidates for removal.

Bridie Holds Bug Triage

Rob Lanphier (Linden) was out this week. Bridie Saccocio (Linden) stepped in to take over Monday's session. Notes are at Bug_triage/2007-05-21. Thanks, Bridie!

Survey Contest

A.C.Vandergraaf posted a survey link to the list, stating that there was a L$ prize for answering the questions. I'm not linking the survey directly; instead read the message and judge whether you think it's appropriate to the list. (I honestly couldn't decide, so I'm erring on the side of reproducing this -- Soft) Vandergraaf also posts a link, promising the results of the survey will appear there.

Texture Cache Update

Steve Linden posts a heads up that the texture cache is changing dramatically, specifically in the code pertaining to the entry lists. Check with Steve if you've got open patches against this system and want to know if they'll still apply. Steve indicates that the interface to LLTextureCache hasn't changed, so anyone working on a complete replacement - something Steve encourages - will be unaffected.

Sculpted Prims Patch

Dirk Moerenhout posts a patch to the list, stating that it speeds up patch generation and fixes problems with 32x32 textures. There was no JIRA created, and no discussion followed. The patch is attached to the original message.