Details
-
Type:
Story
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: qa_explorer
-
Labels:None
-
Story Points:1
-
Epic Link:
-
Sprint:AP S19-3
-
Team:Alert Production
Description
When I try to run writeObjectTable.py on lsst-dev, it fails with a segfault & long backtrace, starting like:
[tmorton@lsst-dev01 DM-14289]$ bash writeTables_test.sh
|
Caught signal 11, backtrace follows:
|
/ssd/lsstsw/stack3_20171021/stack/miniconda3-4.3.21-10a4fa6/Linux64/utils/16.0-6-g3610b4f/lib/libutils.so(+0x15214) [0x7f078a865214]
|
/usr/lib64/libc.so.6(+0x362f0) [0x7f080a5892f0]
|
/ssd/lsstsw/stack3_20171021/python/miniconda3-4.3.21/bin/../lib/libstdc++.so.6(std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::string const&)+0xb) [0x7f08032b640b]
|
/ssd/lsstsw/stack3_20171021/python/miniconda3-4.3.21/lib/python3.6/site-packages/pyarrow/../../../libparquet.so.1(+0x177ddc) [0x7f071bcb6ddc]
|
/ssd/lsstsw/stack3_20171021/python/miniconda3-4.3.21/lib/python3.6/site-packages/pyarrow/../../../libparquet.so.1(+0x1696c3) [0x7f071bca86c3]
|
/ssd/lsstsw/stack3_20171021/python/miniconda3-4.3.21/lib/python3.6/site-packages/pyarrow/../../../libparquet.so.1(+0x175e8b) [0x7f071bcb4e8b]
|
/ssd/lsstsw/stack3_20171021/python/miniconda3-4.3.21/lib/python3.6/site-packages/pyarrow/../../../libparquet.so.1(parquet::ApplicationVersion::ApplicationVersion(std::string const&)+0x6d) [0x7f071bc4aa5d]
|
/ssd/lsstsw/stack3_20171021/python/miniconda3-4.3.21/lib/python3.6/site-packages/pyarrow/../../../libparquet.so.1(+0x83590) [0x7f071bbc2590]
|
/lib64/ld-linux-x86-64.so.2(+0xfb03) [0x7f080b964b03]
|
/lib64/ld-linux-x86-64.so.2(+0x146de) [0x7f080b9696de]
|
/lib64/ld-linux-x86-64.so.2(+0xf914) [0x7f080b964914]
|
/lib64/ld-linux-x86-64.so.2(+0x13ccb) [0x7f080b968ccb]
|
/usr/lib64/libdl.so.2(+0xfbb) [0x7f080b02dfbb]
|
...etc
|
The script I am running is the following:
RERUN1=/datasets/hsc/repo/rerun/RC/w_2018_28/DM-14988/
|
OUTPUT1=/project/tmorton/DM-14289/w28
|
RERUN2=/datasets/hsc/repo/rerun/RC/w_2018_26/DM-14689/
|
OUTPUT2=/project/tmorton/DM-14289/w26
|
|
TRACT=9615
|
PATCH=4,4
|
FILTERS=HSC-G^HSC-R^HSC-I
|
|
writeObjectTable.py $RERUN1 --output $OUTPUT1 --id tract=$TRACT patch=$PATCH filter=$FILTERS --no-versions -j 20
|
writeObjectTable.py $RERUN2 --output $OUTPUT2 --id tract=$TRACT patch=$PATCH filter=$FILTERS --no-versions -j 20
|
writeQATable.py $OUTPUT1 --output $OUTPUT1 --id tract=$TRACT patch=$PATCH --no-versions -j 20 --clobber-config
|
writeQATable.py $OUTPUT2 --output $OUTPUT2 --id tract=$TRACT patch=$PATCH --no-versions -j 20 --clobber-config
|
I can run the identical script in the jupyterlab environment container and everything is great.
I think this is related to the fact that I can run the qa_explorer tests on the JL env but not lsst-dev, where it hangs with a segfault as well (DM-14224). It is making testing of DM-14289 difficult, since I can't do it on lsst-dev.
Simon Krughoff and Adam Thornton: there's probably a better place to suggest this, but it's probably better to have the JLab environment (and by extension, the shared stack) to install pyviz rather than the individual components (bokeh/holoviews/datashader/etc.) individually from the bleeding edge.