View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0014471||FPC||Compiler||public||2009-09-01 03:01||2010-07-03 16:50|
|Reporter||macite||Assigned To||Jonas Maebe|
|Platform||i386||OS||Mac OS X|
|Fixed in Version||2.4.0|
|Summary||0014471: Bus Error when linking to dylib with Snow Leopard|
|Description||Compiling and running FPC generated dylibs on Snow Leopard using -k"-no_dead_strip_inits_and_terms" corrects the Segmentation Fault but has other issues.|
Console IO stops working. Compiling and running code attached without SysUtils and Trace calls/code results in the program running but no output is displayed on the console. This includes the "Here" code from the printf calls in RunTest.c as well as the WriteLn in the Pascal code. Removing the call to SayHello, but still linking to the FPC dylib has the same result (i.e. no output).
Adding in the trace code (which writes to file) results in a Bus Error.
This code works on Leopard.
(ps. love the product, keep up the great work!)
|Steps To Reproduce||Compile attached source code with:|
fpc -k"-no_dead_strip_inits_and_terms" Test.pas
gcc -arch i386 -L. -lTest RunTest.c
+ Trace log file
When run without SysUtils or Trace:
|Additional Information||gdb backtrace of error:|
#0 0x00005c93 in SYSTEM_FPC_SHORTSTR_ASSIGN$LONGINT$POINTER$POINTER ()
0000001 0x00005010 in P$TEST_TRACE$SHORTSTRING$SHORTSTRING$SHORTSTRING$SHORTSTRING ()
0000002 0x00004fdb in _P$TEST_main ()
0000003 0x8fe0ed6d in __dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE ()
0000004 0x8fe0d31e in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()
0000005 0x8fe0d2c2 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()
0000006 0x8fe0d3d1 in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextE ()
0000007 0x8fe024a9 in __dyld__ZN4dyld24initializeMainExecutableEv ()
0000008 0x8fe07950 in __dyld__ZN4dyld5_mainEPK12macho_headermiPPKcS5_S5_ ()
0000009 0x8fe018b1 in __dyld__ZN13dyldbootstrap5startEPK12macho_headeriPPKcl ()
0000010 0x8fe01057 in __dyld__dyld_start ()
|Tags||No tags attached.|
|Fixed in Revision||13717|
Bus Error with FPC on Snow Leopard.zip (1,353 bytes)
Maybe the Snow Leopard linker has the same bug as the iPhone SDK 3.0 linker, described at http://wiki.freepascal.org/iPhone/iPod_development#iPhone_SDK_3.0
Please try executing the following commands in a Terminal window:
echo "_SYSTEM_FPC_LIBINITIALIZEUNITS" > /tmp/tostrip
echo "_SYSTEM_LIB_EXIT" >> /tmp/tostrip
echo "fpc_initializeunits" >> /tmp/tostrip
sudo strip -X -R /tmp/tostrip /usr/local/lib/fpc/2.2.4/units/i386-darwin/rtl/system.o
And then rebuild your program.
Correction: and then rebuild your library.
||PS: I can't test myself, because I don't have Mac OS X 10.6 yet.|
No problems, I tested it with these instructions with no success.
However strip indicated that _SYSTEM_FPC_LIBINITIALIZEUNITS did not exist as a symbol in system.o
strip: symbols names listed in: /tmp/tostrip not in: /usr/local/lib/fpc/2.2.4/units/i386-darwin/rtl/system.o
Could you attach the library as compiled under 10.6?
Also, does it work if you use the following parameters (replace /Developer with where your developer tools are installed)
-k"-macosx_version_min 10.5" -Xr/Developer/SDKs/MacOSX10.5.sdk
Even that does not work either, please include a copy compiled with those options and one without them.
I have tried this with no luck.
Using the -k... -X... options result in a segmentation fault.
I have compiled 3 versions of the dylib following the various combinations of the above suggestions. These are in the attached file.
libTest-k.dylib was compiled with
fpc -k"-no_dead_strip_inits_and_terms" Test.pas
libTest-kx.dylib was compiled with
fpc -k"-macosx_version_min 10.5" -Xr/Developer/SDKs/MacOSX10.5.sdk Test.pas
libTest-kkx.dylib was compiled with
fpc -k"-no_dead_strip_inits_and_terms" -k"-macosx_version_min 10.5" -Xr/Developer/SDKs/MacOSX10.5.sdk Test.pas
The results of executing these was:
libTest-k.dylib - Bus Error
libTest-kx.dylib - Segmentation Fault
libTest-kkx.dylib - Segmentation Fault
The Bus Error is as before, the Segmentation Fault initialising the dylib.
libTest.zip (639,186 bytes)
There's definitely something weird going on.
This is the code of FPC_INITIALIZEUNITS in libTest-kkx.dylib:
00000e20 subl $0x08,%esp
00000e23 pushl %eax
00000e24 pushl %ecx
00000e25 calll 0x00000e2a
00000e2a popl %eax
00000e2b movl 0x00040da6(%eax),%ecx
00000e31 movl %ecx,0x0c(%esp)
00000e35 movl 0x000361d6(%eax),%ecx
00000e3b movl %ecx,0x08(%esp)
00000e3f popl %ecx
00000e40 popl %eax
This is its code in system.o of FPC 2.2.4:
00011290 subl $0x1c,%esp
00011293 movl %ebx,(%esp)
00011296 movl %esi,0x04(%esp)
0001129a movl %edi,0x08(%esp)
0001129e calll fpc_geteipasebx
000112a3 calll 0x0001e0b9 ; symbol stub for: _SYSTEM_FPC_CPUINIT
000112a8 movl 0x1e4b0-0x112a3(%ebx),%eax
000112ae movl (%eax),%edi
000112b0 movl $0x00000001,%esi
000112b5 cmpl %esi,%edi
000112b7 jl 0x000112db
[snip lots of other code]
Overall, it looks quite similar to the ARM linker bug I referred to earlier, but nevertheless it appears to be somewhat different since the same workaround doesn't help (although that workaround was for a system unit of FPC 2.3.1/2.5.1, hence the missing _SYSTEM_FPC_LIBINITIALIZEUNITS, stripping the other two symbols should have the same effect on 2.2.4).
One thing you could try to work around this problem is to compile with -Cn, edit ppas.sh and change "ld" into "ld_classic". That will make you use the pre-10.5 linker, which has not been really updated anymore since 10.4 (I think it's still available on 10.6). So it should not have this bug either. It can only link against the 10.4 SDK or earlier though, so you have to compile with -k"-macosx_version_min 10.4" -Xr/Developer/SDKs/MacOSX10.4u.sdk in that case.
That's not really a workable band-aid though.
The ppas.sh script is using libtool to create the dylib but I was able to convert this to use ld (then ld_classic) but I haven't been able to get ld_classic to work. I'm using:
/usr/bin/ld_classic -no_dead_strip_inits_and_terms -macosx_version_min 10.4 -dylib -multiply_defined suppress -L. -o /Users/acain/Desktop/Bus+Error+with+FPC+on+Snow+Leopard/libTest.dylib `cat link.res`
and I get the following error:
/usr/bin/ld_classic: /usr/lib/libc.dylib load command 5 unknown cmd field
Running with ld links but results in previous errors.
That error means that you did not use -Xr/Developer/SDKs/MacOSX10.4u.sd (or that you do not have the 10.4u sdk installed). ld_classic indeed cannot not work with 10.5 or 10.6 object files/libraries.
Ok, I got this working.
It appears that the -Xr option is ignored by the compiler as this value was supplied and yet the matching "-syslibroot /Developer/SDKs/MacOSX10.4u.sdk" instruction is missing from the generated ppas.sh.
I re-ran the test with "-Xr" as performed previously and the -k -Xr option now generate bus errors.
I've attached a new version of libTest.dylib that was linked using:
ld -no_dead_strip_inits_and_terms -syslibroot /Developer/SDKs/MacOSX10.5.sdk -macosx_version_min 10.5 -dylib -multiply_defined suppress -L. -o /Users/acain/Desktop/Bus+Error+with+FPC+on+Snow+Leopard/libTest.dylib `cat link.res`
I'll add a new issue for the -Xr option for the compiler.
libTest.dylib (473,596 bytes)
> It appears that the -Xr option is ignored by the compiler
Sorry, I made a mistake. The correct parameter is -XR (i.e., with a capital R)
||Thanks for the help on this. Hopefully you'll be able to work out an easier solution soon. :)|
-Xr looked right when I read the options...
-Xr<x> Set library search path to <x> (needed for cross compile) (BeOS, Linux)
But yes, -XR works, thanks!
> Thanks for the help on this. Hopefully you'll be able to
> work out an easier solution soon. :)
Does that mean that one of the things you tried did result in a working library? If so, which one?
Any form of linking with ld fails, but linking with ld_classic works.
Using ld ... results in a Segmentation Fault.
Using ld -no_dead_strip_inits_and_terms ... results in a Bus Error
Using ld_classic and -XR works
Let me know if you want me to try anything else.
||I think we've reached the limit of what I can do via the bug reporting form. I have to wait until I've received my copy of 10.6 so I can debug it.|
I got access to a 10.6 machine. You can work around the crash during initialisation by passing -no_order_inits to ld. I've filed a bug report about this with Apple, you can see a (separately posted) copy at http://openradar.appspot.com/7198997
If you do that, you will however get a crash during finalisation. You can work around that one by additionally passing -no_order_data to ld.
Unfortunately, Apple did not update libtool to recognise these options, so you cannot simply use -k-no_order_inits -k-no_order_data.
The reason that FPC uses libtool, is because that's what gcc on Mac OS X called when I added support for dynamic libraries. Currently, gcc calls "collect2". I'll ask the Apple people on the Xcode list what we should call in order to get backward and forward compatibility.
I've changed the compiler to call "ld" for now, so you can use -k-no_order_inits -k-no_order_data
I'm not sure yet what the best way will be to automatically specify them (we can't always add them automatically, since older versions of ld won't recognise those options).
||I've managed to change the compiler so that -k-no_order_data is no longer necessary.|
||Also, the -no_dead_strip_inits_and_terms turns out to be a red herring. It's not needed (though it won't harm).|
* -k"-no_dead_strip_inits_and_terms" was a red herring and is not required (and the compiler no longer automatically passes it either)
* the compiler now calls "ld" rather than "libtool", so that the new -no_order_data and -no_order_inits options can be used. Unfortunately, there is no way to do so with FPC 2.2.4 without resorting to editing the ppas.sh file or substituting libtool with some kind of shell script that adjusts the command line and passes it on to ld, except if you are using Xcode. In that case you can solve the problem by adding -Wl,-no_order_inits and -Wl,-no_order_data to the "Other linker flags".
* in r13650, I changed the resource string section so that it works with the linker's new data reordering, so that -k-no_order_data is *not* necessary
* you will still have to use -k-no_order_inits when compiling dynamic libraries under 10.6 until the linker is fixed. While I could work around this (if you the use the linker parameter "-init _name_of_init_symbol" instead of a .mod_init_func section then the linker won't reorder the code -- another bug in the linker), that workaround would break easy Xcode integration (there Xcode calls rather than the compiler calls the linker, so you'd have to instruct that one to use "-init" as well) and other things.
So, until further notice: use -k-no_order_inits when compiling dynamic libraries under Mac OS X 10.6 (using FPC 2.4.0rc1 or later). When using Xcode, add -Wl,-no_order_inits to the "Other linker flags" instead (-k parameters won't have any effect in that case).
Note that libraries compiled with FPC under earlier version of Mac OS X will keep working fine on Mac OS X 10.6.
|2009-09-01 03:01||macite||New Issue|
|2009-09-01 03:02||macite||File Added: Bus Error with FPC on Snow Leopard.zip|
|2009-09-01 11:58||Jonas Maebe||Note Added: 0030286|
|2009-09-01 11:58||Jonas Maebe||Status||new => feedback|
|2009-09-01 11:59||Jonas Maebe||FPCOldBugId||=> 0|
|2009-09-01 11:59||Jonas Maebe||OS||MacOS => Mac OS X|
|2009-09-01 11:59||Jonas Maebe||OS Version||Leopard => Snow Leopard|
|2009-09-01 12:25||Jonas Maebe||Note Edited: 0030286|
|2009-09-01 12:25||Jonas Maebe||Note Edited: 0030286|
|2009-09-01 16:43||Jonas Maebe||Note Added: 0030294|
|2009-09-02 09:22||macite||Note Added: 0030309|
|2009-09-02 10:34||Jonas Maebe||Note Added: 0030313|
|2009-09-03 06:09||macite||Note Added: 0030350|
|2009-09-03 06:09||macite||File Added: libTest.zip|
|2009-09-03 10:48||Jonas Maebe||Note Added: 0030360|
|2009-09-03 13:24||macite||Note Added: 0030366|
|2009-09-03 13:38||Jonas Maebe||Note Added: 0030367|
|2009-09-03 13:38||Jonas Maebe||Note Edited: 0030367|
|2009-09-03 14:10||macite||Note Added: 0030370|
|2009-09-03 14:10||macite||File Added: libTest.dylib|
|2009-09-03 14:19||Jonas Maebe||Note Added: 0030371|
|2009-09-03 14:20||macite||Note Added: 0030372|
|2009-09-03 14:22||macite||Note Added: 0030373|
|2009-09-03 14:32||Jonas Maebe||Note Added: 0030375|
|2009-09-04 00:36||macite||Note Added: 0030387|
|2009-09-04 10:11||Jonas Maebe||Note Added: 0030394|
|2009-09-04 10:11||Jonas Maebe||Status||feedback => assigned|
|2009-09-04 10:11||Jonas Maebe||Assigned To||=> Jonas Maebe|
|2009-09-04 18:17||Jonas Maebe||Note Added: 0030412|
|2009-09-05 12:32||Jonas Maebe||Note Added: 0030447|
|2009-09-05 16:41||Jonas Maebe||Note Added: 0030451|
|2009-09-05 22:24||Jonas Maebe||Note Added: 0030466|
|2009-09-06 22:15||Jonas Maebe||Fixed in Revision||=> 13658|
|2009-09-06 22:15||Jonas Maebe||Status||assigned => resolved|
|2009-09-06 22:15||Jonas Maebe||Fixed in Version||=> 2.5.1|
|2009-09-06 22:15||Jonas Maebe||Resolution||open => fixed|
|2009-09-06 22:15||Jonas Maebe||Note Added: 0030491|
|2009-09-17 18:29||Jonas Maebe||Note Edited: 0030491|
|2009-09-18 00:57||Jonas Maebe||Note Edited: 0030491|
|2009-09-18 01:17||Jonas Maebe||Note Edited: 0030491|
|2009-11-09 14:39||Jonas Maebe||Fixed in Revision||13658 => 13717|
|2009-11-09 14:39||Jonas Maebe||Fixed in Version||2.5.1 => 2.4.0|
|2009-11-09 14:40||Jonas Maebe||Relationship added||related to 0014465|
|2009-11-09 20:27||Jonas Maebe||Note Edited: 0030491|
|2010-07-03 16:50||Jonas Maebe||Status||resolved => closed|