shibd segfault when checking configuration
Guillaume Rousse
guillaume.rousse at renater.fr
Mon Nov 28 13:38:06 UTC 2022
On a CentOS Stream 8, using packages provided by the Shibboleth foundation:
$ sudo -u shibd shibd -tc /etc/shibboleth/shibboleth2.xml
overall configuration is loadable, check console or log for non-fatal
problems
Erreur de segmentation
gdb shows the error happens while checking cached individual metadata
entries:
t#0 0x00007fcef48ed67e in
shibsp::DynamicMetadataProvider::FolderCallback (pathname=0x7fcec80c65e0
"/var/cache/shibboleth/fer/292ddbd82228f13831c6526e003f0d07e171e80b.xml",
stat_buf=..., data=0x55b6a98c7a70)
at metadata/DynamicMetadataProvider.cpp:481
481 me->doFilters(&bc, *entity);
[Current thread is 1 (Thread 0x7fcedb7fe700 (LWP 438747))]
...
(gdb) bt full
#0 0x00007fcef48ed67e in
shibsp::DynamicMetadataProvider::FolderCallback (pathname=0x7fcec80c65e0
"/var/cache/shibboleth/fer/292ddbd82228f13831c6526e003f0d07e171e80b.xml",
stat_buf=..., data=0x55b6a98c7a70)
at metadata/DynamicMetadataProvider.cpp:481
bc = <incomplete type>
entity = {_M_ptr = 0x7fcec8046290}
thisFileEntry = <incomplete type>
me = <optimized out>
#1 0x00007fcef25a1e11 in xmltooling::DirectoryWalker::_walk(char
const*, void (* const&)(char const*, stat&, void*), void*, char const*,
char const*) const () from /usr/lib64/libxmltooling.so.10
No symbol table info available.
#2 0x00007fcef48ed37f in xmltooling::DirectoryWalker::walk
(endsWith=0x0, startsWith=0x0, callback_data=0x55b6a98c7a70,
callback_fn=@0x7fcedb7fdc58: 0x7fcef48ed4d0
<shibsp::DynamicMetadataProvider::FolderCallback(char const*, stat&,
void*)>, this=0x7fcedb7fdc60) at /usr/include/c++/8/bits/basic_string.h:2294
No locals.
#3 shibsp::DynamicMetadataProvider::init_fn (pv=0x55b6a98c7a70) at
metadata/DynamicMetadataProvider.cpp:463
walker = <incomplete type>
me = 0x55b6a98c7a70
#4 0x00007fcef3d571ca in start_thread () from /usr/lib64/libpthread.so.0
No symbol table info available.
#5 0x00007fcef1721e73 in clone () from /usr/lib64/libc.so.6
No symbol table info available.
Here is the corresponding configuration for this metadata provider,
using MDQ, but not any filter:
<MetadataProvider type="MDQ" cacheDirectory="fer"
baseUrl="https://mdq.federation.renater.fr/fer">
<TrustEngine type="StaticPKIX"
certificate="/etc/pki/tls/certs/usertrust_rsa_certification_authority.crt"/>
</MetadataProvider>
It's reproductible systematically on our production cluster (with many
cached entries), but absolutly not in other environments (with less
cached entries). The XML file in the backtrace is different everytime,
but the cache directory is the same. I checked implied files for XML
syntax problems, or permission issues, without any result.
Fortunatly, there is no problem when restarting shibd, but that's a bit
painful. And I have no clue how to investigate further.
Regards.
--
Guillaume Rousse
Direction des Services Applicatifs
RENATER - Paris
Tel: +33 1 53 94 20 45
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2258 bytes
Desc: Signature cryptographique S/MIME
URL: <http://shibboleth.net/pipermail/users/attachments/20221128/cfcdf62c/attachment.p7s>
More information about the users
mailing list