Bugzilla – Full Text Bug Listing
| Summary: | An internal error occurred during: "FetchJob". | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Mikael Steen <mikael.steen> | ||||
| Component: | cdt-core | Assignee: | Marc-André Laperle <malaperle> | ||||
| Status: | RESOLVED FIXED | QA Contact: | Doug Schaefer <cdtdoug> | ||||
| Severity: | critical | ||||||
| Priority: | P3 | CC: | aegges, elaskavaia.cdt, malaperle, mikael.steen, oyvind.harboe, pawel.1.piech, salvatore.culcasi, yevshif | ||||
| Version: | 8.0 | ||||||
| Target Milestone: | 8.0.3 | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Mikael Steen
It comes from refresh workspace. It stumbles on some binary you have. Can you attach it? I'm not shure if I understand? What binary? Is it something I have compiled as part of a project in the workspace? Is this the binary you want me to attach? I have a lot of projects in the workspace, most of them (if not all) are makefile projects. This makes it hard to determine which binary that might be the problem. I'll try to clear the workspace from all the projects and import and work with one project at a time and see if that can pinpoint the binary in question. Assuming you mean a binary that I compile as part of a CDT project in my workspace I might have isolated the problem to a specific binary. I deleted all my projects from the workspace and imported and worked with one project at a time. Importing and compiling one specific project immediately produced the error mentioned above. It is a unit test binary compiled using CppUnit. A number of libraries are linked into the project directory as part of running the make and executing the unit test program/binary. But I assume that with binary you do not mean a library. I tried to attach the binary but it is to big (37M), Bugzilla won't accept it. Any suggestions? If I try to expand the binary under "Binaries" in the C/C++ Projects tab nothing happens, it just says "Pending" instead of showing any contents in the binary. Without the binary we can maybe add some to skip parsing if it has exceptions, with implications that it would not look like any other binary and some stuff won't work on it. You can upload it some some free file sharing server and give us a link. I just came to think of something... The binaries in this project (there are two binaries, one being a unit test suite) are compiled using a locally installed gcc version (4.4.2). We have another gcc locally installed (3.3.6) used to compile other projects. There is also a system wide installed gcc version (4.5.0) which comes with openSUSE 11.3 that is not used when compiling this project. We select which compiler to use in the makefile. After compiling the unit test binary the makefile proceeds with executing the unit test binary. To be able to do so we have to symbolically link in the version of libstdc++.so.6 that is included in the locally installed gcc (4.4.2) so that it is reachable in the directory where the unit test binary is executed. Using the system wide version of libstdc++.so.6 doesn't work, we get errors like "version `GLIBCXX_3.4.14' not found", the two versions of libstdc++.so.6 seem to differ in some way. To "see" the local version of libstdc++.so.6 we have "./" first in our LD_LIBRARY_PATH. When the local version of libstdc++.so.6 is symbolically linked in to the directory where the unit test binary is compiled and executed (by the way, this directory is also part of the Eclipse workspace), it is sometimes not possible to execute other commands from this directory. I accidentally tried using zypper, the command line package manager in openSUSE. This produced the following error message; "zypper: ./libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by zypper)". Executing the clean make target removes all soft links, after this zypper (of course) works again in this directory. Could this be the cause of the problems? (In newer branches of this project, we instead setup the environment from within the makefile, using LD_LIBRARY_PATH instead of soft links to libstdc++.so.6. I do not know if this affects the problems discussed here) The unit test binary is now available at the following link: http://uploadbin.net/5985e6be0714102e98449856e786e5eb/testMain Created attachment 179456 [details]
PAtch for DWARF parser
Incidentally I encountered the same problem when attempting to browse a file a file content in the Project Explorer view
I seem the problem is due to the way the the "bytes" are handled indeed
when analysing the DW_FORM_block1 it is expected to have a 1 byte length data (0-255)
The corresponding code in the DWARF file is implemented in the readAttribute function as
..........
case DwarfConstants.DW_FORM_block1:
{
int size = in.get(); <----------
byte[] bytes = new byte[size & 0xff];
.......
however when reading a byte which value starts with a 1 (example 0x80) the
value represented in the "size" variable will become 0xffffff80 i.e. "-128"
Therefore the following line where the byte array is created dumps because its declared size is negative
In the patch I replicated the fix for DW_FORM_block2 and DW_FORM_block4
hth
Salvatore
(In reply to comment #7) > In the patch I replicated the fix for DW_FORM_block2 and DW_FORM_block4 > hth I also encountered this bug for some executables I have built (not all of them). This patch would help. Any plans to commit? *** Bug 351581 has been marked as a duplicate of this bug. *** (In reply to comment #8) > I also encountered this bug for some executables I have built (not all of > them). This patch would help. Any plans to commit? I'll look at it in the next few days. Fixed in 8.1. - Salvatore, thanks for the patch. I made minor changes: I updated the copyrights with your name and I removed the change for the 4 bytes since int && 0xffff_ffff has no effect (AFAIK?). - Mikael, thank you for the report and the test binary. I tested it and it works now. Hi Marc thanks for integrating the patch. Yes you are right that the bitwise and is useless thanks Salvatore *** cdt git genie on behalf of Salvatore Culcasi ***
Bug 322475 - Internal error (NegativeArraySizeException) in Dwarf
[*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=4a5e1d6fe199a896d5816614e70cdcd4c1efd575
*** cdt git genie on behalf of Salvatore Culcasi ***
Bug 322475 - Internal error (NegativeArraySizeException) in Dwarf
[*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=273e46b4095d06fefb19cfe371a7994e727af225
|