Community
Participate
Working Groups
Build Identifier: I20100608-0911 Eclipse CDT is constantly throwing exceptions and popping an error message with the text: "An internal error occurred during: "FetchJob"". When this happens Eclipse hangs for long periods where no input (or output) is possible. Stack trace and info follows: eclipse.buildId=I20100608-0911 java.version=1.6.0_20 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=en_US Framework arguments: -product org.eclipse.epp.package.linuxtools.product Command-line arguments: -os linux -ws gtk -arch x86 -product org.eclipse.epp.package.linuxtools.product Error Thu Aug 12 09:15:02 CEST 2010 An internal error occurred during: "FetchJob". java.lang.NegativeArraySizeException at org.eclipse.cdt.utils.debug.dwarf.Dwarf.readAttribute(Dwarf.java:479) at org.eclipse.cdt.utils.debug.dwarf.Dwarf.parseDebugInfoEntry(Dwarf.java:448) at org.eclipse.cdt.utils.debug.dwarf.Dwarf.parseDebugInfo(Dwarf.java:386) at org.eclipse.cdt.utils.debug.dwarf.Dwarf.parse(Dwarf.java:362) at org.eclipse.cdt.utils.debug.dwarf.DwarfReader.getSourceFilesFromDebugInfoSection(DwarfReader.java:385) at org.eclipse.cdt.utils.debug.dwarf.DwarfReader.getSourceFiles(DwarfReader.java:363) at org.eclipse.cdt.internal.core.model.Binary.addSourceFiles(Binary.java:309) at org.eclipse.cdt.internal.core.model.Binary.computeChildren(Binary.java:279) at org.eclipse.cdt.internal.core.model.Binary.buildStructure(Binary.java:265) at org.eclipse.cdt.internal.core.model.Openable.generateInfos(Openable.java:265) at org.eclipse.cdt.internal.core.model.CElement.openWhenClosed(CElement.java:430) at org.eclipse.cdt.internal.core.model.CElement.getElementInfo(CElement.java:309) at org.eclipse.cdt.internal.core.model.CElement.getElementInfo(CElement.java:299) at org.eclipse.cdt.internal.core.model.Parent.getChildren(Parent.java:55) at org.eclipse.cdt.internal.ui.CWorkbenchAdapter.getChildren(CWorkbenchAdapter.java:44) at org.eclipse.cdt.internal.ui.DeferredCWorkbenchAdapter.fetchDeferredChildren(DeferredCWorkbenchAdapter.java:37) at org.eclipse.cdt.internal.ui.util.RemoteTreeContentManager$FetchJob.run(RemoteTreeContentManager.java:85) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) This occurs no matter what I do, I just work with the CDT for a while. Sometimes the errors start coming immediately when I start Eclipse CDT. I notice the last lines in the stack trace contains "debug" but the problem is not limited to debugging. In fact, the stack trace above comes from an Eclipse CDT instance where I have never done any debugging! I have tried using different workspaces, different Eclipse configurations, different machines (openSUSE 11.2 or 11.3), the errors are still there. Reproducible: Always Steps to Reproduce: 1. Download Eclipse IDE for C/C++ Linux Developers. 2. Work with it. 3. After a while, or immediately an error message pops up saying "An internal error occurred during: "FetchJob"". From now on, the messages will keep coming in bursts as you work, making it almost impossible to use the CDT.
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
