[opensource-dev] (standalone/64-bit) build issues with Mesh viewer source code (and fixes for some of them. Yay!)
So ... I've been busy during the weeking poking the mesh viewer source
code with a stick g++ and can report some results. It seems quite some
of the issues were (re)introduced by mistakes in merge conflict
resolution. Some others are new. Here are the one's I've filed issues
for already:
CTS-314 https://jira.secondlife.com/browse/CTS-314: Fix of
VWR-20810 / SNOW-503 (Quote EXE_STAGING_DIR to prevent it failing
with some paths) lost in merge
* VWR-20810 https://jira.secondlife.com/browse/VWR-20810 was fixed
at b987077e9bbb
http://bitbucket.org/lindenlab/viewer-development/changeset/b987077e9bbb,
but it looks like the fix got lost in the merge at 538a49313042
http://bitbucket.org/lindenlab/mesh-development/changeset/538a49313042.
* Re-fixed
* Ready for review
CTS-315 https://jira.secondlife.com/browse/CTS-315:
-march=pentium4 may not be used for 64bit builds
* Started discussion
https://lists.secondlife.com/pipermail/opensource-dev/2010-October/thread.html#4338
on the mailing list about how to fix this correctly
* Until that's decided, work around with
sed '175 s/-march=pentium4 //' -i indra/cmake/00-Common.cmake
when building 64-bit.
CTS-318 https://jira.secondlife.com/browse/CTS-318: Fix of
VWR-20809 / SNOW-504 (Do not depend on stage_thirds_party_libs for
a standalone build.) lost in merge
* VWR-20809 https://jira.secondlife.com/browse/VWR-20809 was fixed
at c5ddd1e361ae
http://bitbucket.org/lindenlab/viewer-development/changeset/c5ddd1e361ae
, but it looks like the fix got lost in the merge at 538a49313042
http://bitbucket.org/lindenlab/mesh-development/changeset/538a49313042.
* Re-fixed
* Ready for review
CTS-319 https://jira.secondlife.com/browse/CTS-319: Fix of
VWR-20670 / SNOW-506 (Protection on LLInstanceTracker base in
LLEventTimer needs to be public for gcc 4.1) lost in merge
* VWR-20670 https://jira.secondlife.com/browse/VWR-20670 was fixed
at 20860bbd5cae
http://bitbucket.org/lindenlab/viewer-development/changeset/20860bbd5cae,
but it looks like the fix got lost in the merge at ad384ab52275
http://bitbucket.org/lindenlab/mesh-development/changeset/ad384ab52275.
* Re-fixed
* Ready for review
CTS-320 https://jira.secondlife.com/browse/CTS-320: use system
zlib for standalone
* Fixed, using the same pattern as already used elsewhere in the code
o Noticed some mistakes in the fix and corrected those
* Ready for review
CTS-323 https://jira.secondlife.com/browse/CTS-323: Don't cast
pointers to U32
* Fixed by using uintptr_t instead.
o This type isn't part of the current C++ standard (might
become part of the next), but it's already used elsewhere in
the code, so I assume all of our build platforms support it.
* Ready for review
Now I'm stuck at where it won't find the new libraries
https://lists.secondlife.com/pipermail/opensource-dev/2010-October/004337.html,
even when I build and install them. I guess some CMake glue for
standalone is still missing. (Or maybe I should just wait for auto-build?)
Also, when tests are enabled, one of them errors out. That's right, it's
*not even failing*. :-P
Running: /usr/bin/python
${SRC_DIR}/indra/llmessage/tests/test_llsdmessage_peer.py
${BUILD_DIR}/llmessage/INTEGRATION_TEST_llsdmessage
Unit test group_started name=llsdmessage
Failed to catch N11LLEventPump11DupPumpNameE
Failure running: /usr/bin/python
${SRC_DIR}/indra/llmessage/tests/test_llsdmessage_peer.py
${BUILD_DIR}/llmessage/INTEGRATION_TEST_llsdmessage
Error: 245
make[2]: *** [llmessage/INTEGRATION_TEST_llsdmessage] Error 245
make[1]: *** [llmessage/CMakeFiles/INTEGRATION_TEST_llsdmessage.dir/all]
Error 2
make: *** [all] Error 2
Wolfpup observed that INTEGRATION_TEST_llcapabilitylistener also has
runtime issues.
Cheers,
Boroondas
___
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] (standalone/64-bit) build issues with Mesh viewer source code (and fixes for some of them. Yay!)
Just so everyone knows I'm building on Windows 7 32-bit and both if the
tests that Boroondas mentions are actually memory leaking BADLY(test ballons
to nearly 1GB of mem usage) on my system just before crashing or I
terminated the process.
From: opensource-dev-boun...@lists.secondlife.com
[mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Boroondas
Gupte
Sent: Monday, October 25, 2010 10:02 AM
To: Nyx Linden
Cc: opensource-dev
Subject: [opensource-dev] (standalone/64-bit) build issues with Mesh viewer
source code (and fixes for some of them. Yay!)
So ... I've been busy during the weeking poking the mesh viewer source code
with a stick g++ and can report some results. It seems quite some of the
issues were (re)introduced by mistakes in merge conflict resolution. Some
others are new. Here are the one's I've filed issues for already:
CTS-314 https://jira.secondlife.com/browse/CTS-314 : Fix of VWR-20810 /
SNOW-503 (Quote EXE_STAGING_DIR to prevent it failing with some paths) lost
in merge
*https://jira.secondlife.com/browse/VWR-20810 VWR-20810 was fixed
at b987077e9bbb
http://bitbucket.org/lindenlab/viewer-development/changeset/b987077e9bbb ,
but it looks like the fix got lost in the merge at 538a49313042
http://bitbucket.org/lindenlab/mesh-development/changeset/538a49313042 .
* Re-fixed
* Ready for review
CTS-315 https://jira.secondlife.com/browse/CTS-315 : -march=pentium4 may
not be used for 64bit builds
* Started
https://lists.secondlife.com/pipermail/opensource-dev/2010-October/thread.h
tml#4338 discussion on the mailing list about how to fix this correctly
* Until that's decided, work around with
. sed '175 s/-march=pentium4 //' -i indra/cmake/00-Common.cmake
when building 64-bit.
CTS-318 https://jira.secondlife.com/browse/CTS-318 : Fix of VWR-20809 /
SNOW-504 (Do not depend on stage_thirds_party_libs for a standalone build.)
lost in merge
*https://jira.secondlife.com/browse/VWR-20809 VWR-20809 was fixed
at c5ddd1e361ae
http://bitbucket.org/lindenlab/viewer-development/changeset/c5ddd1e361ae
, but it looks like the fix got lost in the merge at 538a49313042
http://bitbucket.org/lindenlab/mesh-development/changeset/538a49313042 .
* Re-fixed
* Ready for review
CTS-319 https://jira.secondlife.com/browse/CTS-319 : Fix of VWR-20670 /
SNOW-506 (Protection on LLInstanceTracker base in LLEventTimer needs to be
public for gcc 4.1) lost in merge
*https://jira.secondlife.com/browse/VWR-20670 VWR-20670 was fixed
at 20860bbd5cae
http://bitbucket.org/lindenlab/viewer-development/changeset/20860bbd5cae ,
but it looks like the fix got lost in the merge at ad384ab52275
http://bitbucket.org/lindenlab/mesh-development/changeset/ad384ab52275 .
* Re-fixed
* Ready for review
CTS-320 https://jira.secondlife.com/browse/CTS-320 : use system zlib for
standalone
* Fixed, using the same pattern as already used elsewhere in the code
* Noticed some mistakes in the fix and corrected those
* Ready for review
CTS-323 https://jira.secondlife.com/browse/CTS-323 : Don't cast pointers
to U32
* Fixed by using uintptr_t instead.
* This type isn't part of the current C++ standard (might become part
of the next), but it's already used elsewhere in the code, so I assume all
of our build platforms support it.
* Ready for review
Now I'm stuck at where it won't find the new
https://lists.secondlife.com/pipermail/opensource-dev/2010-October/004337.h
tml libraries, even when I build and install them. I guess some CMake glue
for standalone is still missing. (Or maybe I should just wait for
auto-build?)
Also, when tests are enabled, one of them errors out. That's right, it's not
even failing. :-P
Running: /usr/bin/python
${SRC_DIR}/indra/llmessage/tests/test_llsdmessage_peer.py
${BUILD_DIR}/llmessage/INTEGRATION_TEST_llsdmessage
Unit test group_started name=llsdmessage
Failed to catch N11LLEventPump11DupPumpNameE
Failure running: /usr/bin/python
${SRC_DIR}/indra/llmessage/tests/test_llsdmessage_peer.py
${BUILD_DIR}/llmessage/INTEGRATION_TEST_llsdmessage
Error: 245
make[2]: *** [llmessage/INTEGRATION_TEST_llsdmessage] Error 245
make[1]: *** [llmessage/CMakeFiles/INTEGRATION_TEST_llsdmessage.dir/all]
Error 2
make: *** [all] Error 2
Wolfpup observed that INTEGRATION_TEST_llcapabilitylistener also has runtime
issues.
Cheers,
Boroondas
_
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1152 / Virus Database: 422/3218 - Release Date: 10/25/10
___
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] (standalone/64-bit) build issues with Mesh viewer source code (and fixes for some of them. Yay!)
I'm out of the office today and tomorrow, but will definitely be
looking into these patches and remaining issues on Wednesday. Thanks a
ton for helping us out!
Nyx
Sent from my iPhone
On Oct 25, 2010, at 10:27 AM, WolfPup Lowenhar wolfpu...@earthlink.net
wrote:
Just so everyone knows I’m building on Windows 7 32-bit and both if
the tests that Boroondas mentions are actually memory leaking BADLY(
test ballons to nearly 1GB of mem usage) on my system just before cr
ashing or I terminated the process.
From: opensource-dev-boun...@lists.secondlife.com [mailto:opensource-
dev-boun...@lists.secondlife.com] On Behalf Of Boroondas Gupte
Sent: Monday, October 25, 2010 10:02 AM
To: Nyx Linden
Cc: opensource-dev
Subject: [opensource-dev] (standalone/64-bit) build issues with Mesh
viewer source code (and fixes for some of them. Yay!)
So ... I've been busy during the weeking poking the mesh viewer
source code with a stick g++ and can report some results. It seems
quite some of the issues were (re)introduced by mistakes in merge
conflict resolution. Some others are new. Here are the one's I've
filed issues for already:
CTS-314: Fix of VWR-20810 / SNOW-503 (Quote EXE_STAGING_DIR to
prevent it failing with some paths) lost in merge
VWR-20810 was fixed at b987077e9bbb, but it looks like the fix got
lost in the merge at 538a49313042.
Re-fixed
Ready for review
CTS-315: -march=pentium4 may not be used for 64bit builds
Started discussion on the mailing list about how to fix this correctly
Until that's decided, work around with
· sed '175 s/-march=pentium4 //' -i indra/cmake/00-Common.cm
ake
when building 64-bit.
CTS-318: Fix of VWR-20809 / SNOW-504 (Do not depend on
stage_thirds_party_libs for a standalone build.) lost in merge
VWR-20809 was fixed at c5ddd1e361ae , but it looks like the fix got
lost in the merge at 538a49313042.
Re-fixed
Ready for review
CTS-319: Fix of VWR-20670 / SNOW-506 (Protection on
LLInstanceTracker base in LLEventTimer needs to be public for gcc
4.1) lost in merge
VWR-20670 was fixed at 20860bbd5cae, but it looks like the fix got
lost in the merge at ad384ab52275.
Re-fixed
Ready for review
CTS-320: use system zlib for standalone
Fixed, using the same pattern as already used elsewhere in the code
Noticed some mistakes in the fix and corrected those
Ready for review
CTS-323: Don't cast pointers to U32
Fixed by using uintptr_t instead.
This type isn't part of the current C++ standard (might become part
of the next), but it's already used elsewhere in the code, so I
assume all of our build platforms support it.
Ready for review
Now I'm stuck at where it won't find the new libraries, even when I
build and install them. I guess some CMake glue for standalone is
still missing. (Or maybe I should just wait for auto-build?)
Also, when tests are enabled, one of them errors out. That's right,
it's not even failing. :-P
Running: /usr/bin/python ${SRC_DIR}/indra/llmessage/tests/
test_llsdmessage_peer.py ${BUILD_DIR}/llmessage/
INTEGRATION_TEST_llsdmessage
Unit test group_started name=llsdmessage
Failed to catch N11LLEventPump11DupPumpNameE
Failure running: /usr/bin/python ${SRC_DIR}/indra/llmessage/tests/
test_llsdmessage_peer.py ${BUILD_DIR}/llmessage/
INTEGRATION_TEST_llsdmessage
Error: 245
make[2]: *** [llmessage/INTEGRATION_TEST_llsdmessage] Error 245
make[1]: *** [llmessage/CMakeFiles/INTEGRATION_TEST_llsdmessage.dir/
all] Error 2
make: *** [all] Error 2
Wolfpup observed that INTEGRATION_TEST_llcapabilitylistener also has
runtime issues.
Cheers,
Boroondas
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1152 / Virus Database: 422/3218 - Release Date: 10/25/10
___
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] Crashing integration tests (was: (standalone/64-bit) build issues with Mesh viewer source code (and fixes for some of them. Yay!))
On 10/25/2010 04:01 PM, Boroondas Gupte wrote:
Also, when tests are enabled, one of them errors out. That's right,
it's *not even failing*. :-P
Running: /usr/bin/python
${SRC_DIR}/indra/llmessage/tests/test_llsdmessage_peer.py
${BUILD_DIR}/llmessage/INTEGRATION_TEST_llsdmessage
Unit test group_started name=llsdmessage
Failed to catch N11LLEventPump11DupPumpNameE
Failure running: /usr/bin/python
${SRC_DIR}/indra/llmessage/tests/test_llsdmessage_peer.py
${BUILD_DIR}/llmessage/INTEGRATION_TEST_llsdmessage
Error: 245
make[2]: *** [llmessage/INTEGRATION_TEST_llsdmessage] Error 245
make[1]: *** [llmessage/CMakeFiles/INTEGRATION_TEST_llsdmessage.dir/all]
Error 2
make: *** [all] Error 2
Wolfpup observed that INTEGRATION_TEST_llcapabilitylistener also has
runtime issues.
What is interesting ---and honestly a bit frightening--- is that on
Linux with GNU make you don't have to disable the integration tests with
-DLL_TESTS=OFF or set them up to be skipped in the test's source with
skip(...) to work around these build-stoppers. If you just re-issue
make again (without cleaning first), it'll *continue the build without
re-trying the test* that just before not-even-failed.
While incremental builds are a great thing, and tests don't need to be
re-run when they've /previously succeeded/ and none of their
dependencies nor the test itself changed since, I guess this isn't how
tests are supposed to work. If a test /fails/ or even /causes a runtime
error/, it should not be skipped until explicitly disabled, either by
LL_TESTS or in the test's source. How else would you know whether you've
fixed the issue?
User story
As a developer, I want to be sure the build doesn't (seem to) succeed
when I've broken a test I didn't disable. (At least as long as I haven't
tampered with dependency declarations or the build system.)
Boroondas
___
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] Crashing integration tests
On 10/25/2010 10:56 PM, Nicky Perian wrote: I found the same thing about failed tests on 2d and subsequent builds. The build has an error the first time but passes the second. This was on VC++Express 2005 build. And, didn't matter about redoing develop.py. So this isn't GNU make or even Makefile specific. Either it's a CMake bug, or we make some mistake at using CMake, probably not declaring all dependencies correctly. Boroondas ___ 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] Crashing integration tests
It looks to be a problem with multiple tests running at the same time. Looking at the error gives a hint that its a collision with a globally shared named pipe of some type. Running the tests individually works just fine for me, running more than one at a time doesn't. On Mon, Oct 25, 2010 at 17:01, Boroondas Gupte slli...@boroon.dasgupta.ch wrote: On 10/25/2010 10:56 PM, Nicky Perian wrote: I found the same thing about failed tests on 2d and subsequent builds. The build has an error the first time but passes the second. This was on VC++Express 2005 build. And, didn't matter about redoing develop.py. So this isn't GNU make or even Makefile specific. Either it's a CMake bug, or we make some mistake at using CMake, probably not declaring all dependencies correctly. Boroondas ___ 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] Crashing integration tests
With my builds, if I rebuild the failed project individually the failure repeats. If I build the full project a second time no failures are reported. It appears that a run-once setting (if possible) is used for integration tests. From: Zabb65 zab...@gmail.com To: Boroondas Gupte slli...@boroon.dasgupta.ch Cc: Nicky Perian nickyper...@yahoo.com; Second Life Open Source Developer Mailing List opensource-dev@lists.secondlife.com Sent: Mon, October 25, 2010 6:48:12 PM Subject: Re: [opensource-dev] Crashing integration tests It looks to be a problem with multiple tests running at the same time. Looking at the error gives a hint that its a collision with a globally shared named pipe of some type. Running the tests individually works just fine for me, running more than one at a time doesn't. On Mon, Oct 25, 2010 at 17:01, Boroondas Gupte slli...@boroon.dasgupta.ch wrote: On 10/25/2010 10:56 PM, Nicky Perian wrote: I found the same thing about failed tests on 2d and subsequent builds. The build has an error the first time but passes the second. This was on VC++Express 2005 build. And, didn't matter about redoing develop.py. So this isn't GNU make or even Makefile specific. Either it's a CMake bug, or we make some mistake at using CMake, probably not declaring all dependencies correctly. Boroondas ___ 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
