The total length of the fields in an index exceeds max key size. Index typ of table (TEMP-TABLE)ttXref (129) #135
Comments
|
HOST & OS info: coli49:92 /users/dr2 $ cat /etc/redhat\-release
Red Hat Enterprise Linux Server release 5.11 (Tikanga)
coli49:92 /users/dr2 $ uname -a
Linux coli49 2.6.18-410.el5 #1 SMP Fri Apr 8 05:48:52 EDT 2016 x86_64 x86_64 x86_64 GNU/Linux |
|
Hi, You're using a custom version of PCT as shown by the PCT Version string, so that will be difficult to reproduce the issue. |
|
There is a recent error occurs with the message. There is an email that gives the possible resolution to this,
The file attched is the log file, but is not very friendly. Any other information needed please contact me. I'm currently creating environment to reproduce the issue. |
|
Does a rebuild of the same exact version in Bamboo triggers again the issue ? |
|
Is a ant -v enough or also should include verbose="true" in the PCTCompile statement? But the latter would be difficult to configure in our bamboo job. I'm currently run the build in verbose to see if this intermittent error occurs. I copied the pct.jar from the bamboo work area and shows: Name: common |
|
Build 176 is quite old, you also should consider upgrading to the latest version. |
Today got the verbose log of the error:_build 06-Jun-2016 12:14:48 compile-impl: and the bl.build.xml line 434 is running the following target: |
|
Would this error 06-Jun-2016 12:15:53 Caused by: java.io.FileNotFoundException: /tmp/PCTResult18301.out (No such file or directory) caused by pct problem or the system problem? Because we have scripts to cleanup the files under /tmp if there is little space, but we have check that it didn't trigger when the bamboo has this error, so not sure the exact reason. |
|
If you still have a PCTXREF file in the root folder of your workspace build (that should be /dr01/bamboo/xml-data/build-dir/BAMTST-IBST-BL/tmp/wc556105753/bl/ or something close), please attach it to this ticket. |
|
Hi Gilles: Another question is that: ` |
|
PCTXREF is a regular file in the filesystem ; it's created on the fly by PCT during compilation to extract XREF data. |
|
No i can not find it, I have a backup of the work area during the build that is the /dr01/bamboo/xml-data/build-dir/BAMTST-IBST-BL/, but no finding. I guess just after the compile is done the file will be removed? |
|
If you can give me a basic content or what the file is like may help me to do the search. |
|
Are you able to trigger a command line directly in this build directory ? If so, please add verbose="true" keepXref="true" to the PCTCompile node and restart the build process directly. |
|
Got it, but this PCTXREF is not from that fail build, is from a currently running build. |
|
That won't be the right one |
|
Btw, I find a interesting thing. As I find the /tmp folder is another work area in additional to dr01/bamboo/xml-data/build-dir/BAMTST-IBST-BL/ and is for every build. I got the PCTXREF from /tmp and the PCTResultxxx.out is also under that. There is two agent that can run build at the same time on our bamboo server. So my guess is, what's your naming rule for PCTResultxxx.out ? Would that possible that two bamboo run PCTCompile at the same time using same PCTResult or wrongly remove other build's PCTResult? Those fail do occur at the same time: So should a set the PCT output location different a potential solution? Compared to get the PCTXREF of a fail build, test this may be more easier because all PCTXREF is under /tmp PCTXREF and may be overwrite by other build before I get it. |
|
Is there some parameter to specify the PCT tmp folder same as -Djava.io.tmpdir=/tmp/BAMTST-IBST-BL when running the ant build? |
|
Numbers are randomly generated in PCT. I'd say it's really unlikely that a conflict could occur. |
|
you can still try using java.io.tmpdir |
|
But if this specific build always crash, then it's not random conflict ; the error message is about an index size problem when reading XREF file. |
|
There are several builds intermittently fails, they both fail in PCT compile. |
|
The version you're using is several years old, and I don't remember where the PCTXREF was generated (and don't have time to do it now). |
|
Hi, Is there some parameter to specify the PCT tmp folder or to pass the java.io.tmpdir in the pct target? |
|
I've search the website that there is a not sure if it works. |
|
For the Java part, it's using java.io.tmpdir : https://github.com/jakejustus/pct/blob/master/src/java/com/phenix/pct/PCTRun.java#L94 |
|
Thanks for your code information, yes, I've checked |
|
Add a line in your build file to verify the value. |
|
I do an echo in the compile-impl target and get this
and the according build.xml is echo message="${java.io.tmpdir}/${user.name}"/> PCTCompile destDir="work/rcode" dlcHome="${DLC}" cpInternal="utf-8" inputChars="32000" stackSize="128" verbose="true" keepXref="true"> It seems that the java.io.tmpdir is not passed into the PCTCompile target. |
|
Yes, that's what I wrote in the previous comment. You have to add tempDir attribute in PCTCompile, otherwise you fall back to the default directory specified during the installation |
|
PCTCompile destDir="work/rcode" dlcHome="${DLC}" cpInternal="utf-8" |
|
Yes, that should work |
|
build 15-Jun-2016 01:04:28 [PCTCompile] '-param' So the -T means the java.tmp.dir is set? But why the parameter file still under /tmp? |
|
Ok, I got PCTXREF under the desired place! So currently I think there shouldn't be PCTXREF conflict during bamboo build. I'll keep them running to see if it works. Thanks for your help |
|
Please also note that your PCT version is quite old and that you should upgrade as soon as possible ! |
Currently there is intermittent issues when using PCT to compile code.
The error looks like this:
This error occurs in our several QRA related bamboo builds as you can refer to
QRA base integrate bamboo build
QRA bamboo build
PCT - version : qra-pct-0.19.0.176
DLC - version : dlc11464 ( OpenEdge 11.4 64-bit)
Reference ticket: https://projects.qad.com/browse/DVS-10940
Any other information needed? Due to its intermittency, find it hard to create a verbose log.
The text was updated successfully, but these errors were encountered: