Opened 9 years ago
Last modified 9 years ago
#47157 new defect
ld64 @2_0 +ld64_127 Linked huge PowerPC dynamic library causes crashes
| Reported by: | tobias.netzel@… | Owned by: | jeremyhu (Jeremy Huddleston Sequoia) |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 2.3.3 |
| Keywords: | Cc: | cooljeanius (Eric Gallager) | |
| Port: | ld64 |
Description
(I'm using OS X 10.5 PowerPC.)
The WebCore framework, when linked using ld64-127 causes crashes when trying to launch an executable that uses it.
Linking itself works without errors or warnings.
When using ld64-97 for linking the very same object files I don't get any crashes.
Now WebCore is quite huge, some 40 MB in release build with debug symbols.
Any suggestions where to look at in order to maybe fix this issue?
The other (much smaller) frameworks like JavaScriptCore and WebKit(Legacy) do work when linked using ld64-127.
However, when launching in gdb, for every framework linked with ld64-127 I see the following two messages:
unable to read unknown load command 0x24 unable to read unknown load command 0x26
Attachments (4)
Change History (11)
comment:1 Changed 9 years ago by larryv (Lawrence Velázquez)
| Owner: | changed from macports-tickets@… to jeremyhu@… |
|---|
comment:2 Changed 9 years ago by jeremyhu (Jeremy Huddleston Sequoia)
comment:3 follow-up: 4 Changed 9 years ago by jeremyhu (Jeremy Huddleston Sequoia)
What are the crashe? Can you attach logs that might shed some light?
comment:4 Changed 9 years ago by tobias.netzel@…
Replying to jeremyhu@…:
What are the crashe? Can you attach logs that might shed some light?
The crash seems to be a null pointer deref in the destructor of a C++-object, compiled from an Objective-C++ source file.
But the backtrace indicates that the stack got completely corrupted, so I don't consider the resulting crash location of any use in finding the cause for this issue.
I guess one would have to debug the library loading process - provided there's no other way to analyze the linker output.
comment:5 Changed 9 years ago by jeremyhu (Jeremy Huddleston Sequoia)
I'd use 'otool -l' to compare the load commands between the two versions and 'otool -t -v' to disassemble the text segment and compare that way. Maybe something will stick out.
Changed 9 years ago by tobias.netzel@…
| Attachment: | WebCore.otool added |
|---|
Changed 9 years ago by tobias.netzel@…
| Attachment: | WebCore_merged.otool added |
|---|
output of otool -lv for the file linked by ld64-127, some segments moved manually in order to make diffing easier
Changed 9 years ago by tobias.netzel@…
| Attachment: | JavaScriptCore.otool added |
|---|
output of otool -lv for the file linked by ld64-97; this one works
Changed 9 years ago by tobias.netzel@…
| Attachment: | JavaScriptCore_merged.otool added |
|---|
output of otool -lv for the file linked by ld64-127, some segments moved manually in order to make diffing easier; this one works, too
comment:6 Changed 9 years ago by tobias.netzel@…
I attached the output of otool -lv on JavaScriptCore and WebCore, linked with both ld64-97 and ld64-127 each.
JavaScriptCore seems to work OK when linked with both linkers, but WebCore linked with ld64-127 doesn't.
There are some differences; do you see something that's obviously wrong?
That just means that your gdb is using a libmacho that does not know about whatever those load commands are. You can run 'otool -l /path/to/macho' to see what they are (note you should of course be using otool from MacPorts' cctools port in this case).