Ticket #2409: credd crashes when there are many entries in the map file

Michael reported on condor-users:

A problem was occurring in 7.4 and 7.5 with the CREDD Service where the mapfile with more than 73 or some odd entries causes the service to crash and the pool password cannot be set. This was briefly mentioned during the Condor week conference and based on the version revision notes, I thought a lot of work on the CREDD service was done.

I spent some time switching over our condor nodes so each machine in the Condor pool used a unique SSL paired key. However, the CREDD service crashes and throws a core file. I reverted back such that I am now only using two keys (one for the server/CM and a second for all nodes). This fixed the problem, but I am curious if the condor development team is aware that the problem still exists. There is a work around, which I stated here, but I was curious if any efforts are being made to resolve this problem.

[Append remarks]


2011-Dec-14 13:59:26 by johnkn:
From my debugging of the code, it appears that it's > 0x80 entries that triggers the crash, since that is the point where the ExtArray containing the entries resizes. -tj
[Append remarks]


Type: defect           Last Change: 2012-Dec-17 12:38
Status: resolved          Created: 2011-Aug-23 10:57
Fixed Version: v070605           Broken Version: v070400 
Priority:          Subsystem: Win32 
Assigned To: zmiller           Derived From:  
Creator: odonnellm  Rust:  
Customer Group: chtc  Visibility: public 
Notify: odonnellm@usgs.gov, tannenba@cs.wisc.edu, tstclair@redhat.com  Due Date: 20111212 

Related Check-ins:

2011-Dec-14 10:12   Check-in [28762]: version history for bug #2409 (By John (TJ) Knoeller )
2011-Dec-07 16:49   Check-in [28658]: fix crash using security map files on windows when file contained more than 128 entries. #2409 The problem was the Regex::Clone was using malloc rather than pcre_malloc. Also changed MapFile code to wait and compile the regexes only after it finished reading the whole file. This avoids unnessary clones [...] (By John (TJ) Knoeller )