shibsp/ServiceProvider.cpp on line 443: while (matches.first != matches.second) { const vector<string>& vals = matches.first->second->getSerializedValues(); if (!vals.empty()) { request.setRemoteUser(vals.front().c_str()); remoteUserSet = true; break; } }
> That code is pretty obviously broken, though I'd have to analyze it a little > > to figure out when it actually spins.
To spin, it appears you'd have to have an Attribute used as REMOTE_USER that ends up with no values after filtering. That's not meant to be possible, so there's probably a bug somewhere else too, but the code wasn't written properly anyway.
Description of consequences of the problem: After some time all apache's processes cycle in this while loop. We hadn't find a way how to reproduce this problem. We found some users which cause the loop, but another login of the same user didn't cause the loop.
From Scott's mail:
shibsp/ServiceProvider.cpp on line 443:
while (matches.first != matches.second) {
const vector<string>& vals =
matches.first->second->getSerializedValues();
if (!vals.empty()) {
request.setRemoteUser(vals.front().c_str());
remoteUserSet = true;
break;
}
}
> That code is pretty obviously broken, though I'd have to analyze it a
little
> > to figure out when it actually spins.
To spin, it appears you'd have to have an Attribute used as REMOTE_USER that
ends up with no values after filtering. That's not meant to be possible, so
there's probably a bug somewhere else too, but the code wasn't written
properly anyway.
Description of consequences of the problem:
After some time all apache's processes cycle in this while loop. We hadn't
find a way how to reproduce this problem. We found some users which cause the
loop, but another login of the same user didn't cause the loop.