Use correct name for key and value

[wmtan]

This pull request is a fix for a fatal problem for about half of the relval tests in the ROOT6 IB.
The conditions code uses a complicated code to determine the names "key_type" and "value_type",
(typedefs of data members of STL collections), which never change. Unfortunately, the new framework code returns the name of the underlying type rather than the name of the typedef. Since the names returned never change, the easiest way to fix this is simply to hard code the the strings "key_type" and "value_type".
Also in this pull request is a fix for multidimensioned C arrays. All but the first index were dropped due to s simple bug in MemberWithDict, which is fixed in this request.
Please merge this promptly unless there are issues.

[cmsbuild]

A new Pull Request was created by @wmtan for CMSSW_7_1_ROOT6_X.

Use correct name for key and value

It involves the following packages:

CondCore/ORA

@ggovi, @cmsbuild, @apfeiffer1, @Degano, @nclopezo can you please review it and eventually sign? Thanks.
@ghellwig this is something you requested to watch as well.
You can sign-off by replying to this message having '+1' in the first line of your reply.
You can reject by replying to this message having '-1' in the first line of your reply.

[cmsbuild]

Pull request #2738 was updated. @apfeiffer1, @Dr15Jones, @cmsbuild, @nclopezo, @ggovi, @Degano, @ktf can you please check and sign again.

[ktf]

Merged. @davidlt looks like the ROOT6 IB validation gets stuck since a few days. Can you please look into it? Thanks.

[davidlt]

@ktf looks like they are timing out (12hr limit). Let's see which workflows keeps RelVals hanged in a several hours as Jenkins just started ROOT6 validation job.

[ktf]

No, they are not timing out because the "validation–" step for ROOT6 does not have the timeout enabled @nclopezo should be looking into it. If you can understand the problem it would be great.

[davidlt]

From all recent validation jobs:

Took 12 hr on cmsbuildXX
[snip]
Build timed out (after 720 minutes). Marking the build as failed.

[ktf]

http://vocms117.cern.ch:8080/jenkins/job/validation-CMSSW_7_1_ROOT6_X-slc5_amd64_gcc481/68/

Started 4 days 2 hr ago
Build has been executing for 4 days 2 hr on lxbuild049

what are you looking at?

On 6 Mar 2014, at 9:51, davidlt wrote:

From all recent validation jobs:

Took 12 hr on cmsbuildXX
[snip]
Build timed out (after 720 minutes). Marking the build as failed.

---

Reply to this email directly or view it on GitHub:
#2738 (comment)

[nclopezo]

Hi,

In the configuration for slc6 the timeout is set:

https://cmssdt.cern.ch/jenkins/job/validation-CMSSW_7_1_ROOT6_X-slc6_amd64_gcc481/configure

https://cmssdt.cern.ch/jenkins/job/validation-CMSSW_7_1_ROOT6_X-slc6_amd64_gcc481/32/console

I will look at the logs for slc5 in lxbuild049

On Thu, Mar 6, 2014 at 10:15 AM, Giulio Eulisse notifications@github.comwrote:

http://vocms117.cern.ch:8080/jenkins/job/validation-CMSSW_7_1_ROOT6_X-slc5_amd64_gcc481/68/

Started 4 days 2 hr ago
Build has been executing for 4 days 2 hr on lxbuild049

what are you looking at?

On 6 Mar 2014, at 9:51, davidlt wrote:

From all recent validation jobs:

Took 12 hr on cmsbuildXX
[snip]
Build timed out (after 720 minutes). Marking the build as failed.

---

Reply to this email directly or view it on GitHub:
#2738 (comment)

Reply to this email directly or view it on GitHubhttps://github.com//pull/2738#issuecomment-36837285
.

David Mendez

[wmtan]

David and Giulio,
After this fix, most of the problems causing early failures have been fixed.
Now, most of the relvals run forever and accumulate memory. The problem is most likely in the conditions code. My next ROOT6 task is to find the problem.
So, the timing out is not an IB issue. It is a code issue that I need to fix.
The problem was not seen until recently because the tests formerly failed for other reasons.
Bill

[davidlt]

@wmtan I looked into running RelVals and I agree. Currently I don't see any workflows being stuck and I see them running, usually sampling workflows I see that they are usually in Cling (e.g., compiling).

Some errors still exist:

140.51: Item for "SiPixelFedCablingMap::Key" not found in the mapping element from STLContainerReader::build 
4.72: Item for "int" not found in the mapping element from STLContainerReader::build 
32.0: Item for "unsigned int" not found in the mapping element from STLContainerReader::build 

Some grep magic on currently running RelVals:

Item for "int" not found in the mapping element from STLContainerReader::build
Item for "SiPixelFedCablingMap::Key" not found in the mapping element from STLContainerReader::build
Item for "std::string" not found in the mapping element from STLContainerReader::build
Item for "unsigned int" not found in the mapping element from STLContainerReader::build 

90 such fatal exceptions so far. You can find such exceptions in:

140.52
4.73
15.0
4.74
27.0
4.45
34.0
1311.0
1324.0
8.0
140.51
19.0
4.29
4.75
4.61
4.51
13.0
2.0
6.0
1.0
31.0
43.0
35.0
33.0
4.52
44.0
1315.0
30.0
1323.0
1316.0
1308.0
4.71
1317.0
29.0
4.41
140.0
12.0
4.62
26.0
24.0
280.0
10.0
4.42
20.0
11.0
38.0
1322.0
1318.0
140.53
3.0
4.65
45.0
17.0
4.54
36.0
21.0
4.43
28.0
141.0
9.0
1325.0
4.4
1319.0
4.63
4.64
39.0
7.0
1313.0
1302.0
143.0
1321.0
25.0
1314.0
1306.0
14.0
4.55
4.17
18.0
4.22
4.44
1310.0
32.0
37.0
22.0
1309.0
16.0
23.0
1301.0
1312.0
4.72
1320.0

[wmtan]

David,
Yes, but most, if not all of the
'Item for "whatever" not found in the mapping element from STLContainerReader::build'
errors are fixed by the latest merged pull request. That is most of the fatal exceptions (over 130 of them).