Community
Participate
Working Groups
Created attachment 187486 [details] Error stack I have the error of the title, when in the debbuger, in the executables tab i click on the executable name to see the source file name. There's the error stack atached.
Created attachment 187487 [details] It's a picture of the problem
I can reproduce this too. Can you change the component of the bug to cdt-core? I will try to fix this.
Created attachment 187493 [details] Mach-O 64 parser, readLong patch -readLong was calling readInt, I copied readLong from utils.ERandomAccessFile -added a null check when no lines info, handles stripped binaries
Andrew, would you mind looking at this when you have a few cycles to spare? It is a simple patch, just copied stuff and a null check. It would be a nice fix for 7.0.2! Thanks :)
This class is now almost a verbatim clone of org.eclipse.cdt.utils.ERandomAccessFile. Is there a good reason to have this code duplicated?
Can someone tell me how to apply the patch, I new to Eclipse and I don't really know how to patch it.
(In reply to comment #5) > This class is now almost a verbatim clone of > org.eclipse.cdt.utils.ERandomAccessFile. Is there a good reason to have this > code duplicated? I tried to change the cdt.utils.macho one to delegate to the cdt.utils one so that it would avoid API compatibility problems, but it doesn't work. Maybe because it's creating two RandomAccessFile objects for the same file (because it needs to call super), hmmmmm. Using the cdt.utils class inside the macho code creates compatibility problems and also readIntE returns a long instead of an int which means lots of casts or lots of compatibility filers. Changing the base class also creates a compatibility problem and readIntE is final and the return type can't be overridden. So, I'm not sure what's worse, the API changes or the duplication? (In reply to comment #6) > Can someone tell me how to apply the patch, I new to Eclipse and I don't really > know how to patch it. I think you should wait for the fix to be in a nightly build. I will paste the link here when it is available. Or if you want to get started with CDT development: http://wiki.eclipse.org/Getting_started_with_CDT_development
Now that 7.0.2 is done, I will look at reusing utils.ERandomAccessFile. I doubt that anyone is depending on macho.ERandomAccessFile so I think it's fine to break the API.
AFAIK we don't tests for any of the binary parsers. This means we're flying blind when making changes here :s. It would be good to add a test case when fixing bugs in them...
*** Bug 306342 has been marked as a duplicate of this bug. ***
*** Bug 302623 has been marked as a duplicate of this bug. ***
Created attachment 192275 [details] Mach-O 64 parser, readLong patch, with API changes
The last patch: -deprecates macho.ERandomAccessFile -changes efile member of MachO64 and AR to a utils.ERandomAccessFile -creates API problem filters for the two changed members -adds a null check when no lines info (for stripped binaries) The original MachO is still using macho.ERandomAccessFile but it is also marked as deprecated so the two could be removed next release. Removing the classes now would bump the major version of the core plugin and I think it's not reasonable to do that at this point. James, how bad is it to create API filters? It shouldn't matter since it is very unlikely that someone is depending on it, right? (In reply to comment #9) > AFAIK we don't tests for any of the binary parsers. This means we're flying > blind when making changes here :s. It would be good to add a test case when > fixing bugs in them... It would be good yes. I'd like to handle that in a separate bug and provide at least some basic tests for all binary parsers.
(In reply to comment #13) > James, how bad is it to create API filters? It shouldn't matter since it is > very unlikely that someone is depending on it, right? This is a problem we have when we make implementation too visible. API freeze has passed, which means we can't even add new API, far less break existing API. So a few questions: - Is it expected that people can extend the MachO64 / AR classes? - Do they need access these protected fields? If either the above is true, we have a problem. If this class isn't designed to be extended can you also make the classes @noextend, so changing protected & private implementation won't be API breaking in the future. The change is small, and the risk is low but there's still a risk. At this point you should email cdt-dev for any objections.
(In reply to comment #14) > (In reply to comment #13) > > James, how bad is it to create API filters? It shouldn't matter since it is > > very unlikely that someone is depending on it, right? > > This is a problem we have when we make implementation too visible. > > API freeze has passed, which means we can't even add new API, far less break > existing API. So a few questions: > - Is it expected that people can extend the MachO64 / AR classes? It is not clear to me if these classes are meant to be extended or not. It seems that it would be pretty hard and convoluted to do so. In any case, I would like to fix this for 8.0 and the safest way to go at this point in the release cycle would be patch https://bugs.eclipse.org/bugs/attachment.cgi?id=187493 James, let me know if you have any objections. If not, I will commit this more conservative patch tomorrow.
Fixed in HEAD (8.0). Will defer potential API changes to next version part of bug 347187.
*** cdt cvs genie on behalf of mlaperle *** Bug 335268 - An internal error occurred during: "Reading Debug Symbol Information: Hello World" [*] MachO64.java 1.4 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.core/utils/org/eclipse/cdt/utils/macho/MachO64.java?root=Tools_Project&r1=1.3&r2=1.4 [*] ERandomAccessFile.java 1.7 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.core/utils/org/eclipse/cdt/utils/macho/ERandomAccessFile.java?root=Tools_Project&r1=1.6&r2=1.7
