Any idea why calling symbols from certain shared libraries would cause poly/ML to crash on OS X? Example:
val gtk = load_lib "libgtk-quartz-2.0.dylib";
val gtk = ?: dylib
val gtk_init = call2 (load_sym gtk "gtk_init") (INT,INT) VOID;
val gtk_init = fn: int * int -> unit
gtk_init(0,0);
[1] 96630 killed rlwrap -z poly
This (or rather, the equivalent) code works fine on linux, and "libgtk-quartz-2.0.dylib" will link with C code in OS X with no problems. It seems to only do this for some libraries. For instance, the "difference" example from the poly docs (http://www.polyml.org/docs/CInterface.html) also works fine on OS X.
On 24/06/12 01:47, Aleks Kissinger wrote:
Any idea why calling symbols from certain shared libraries would cause poly/ML to crash on OS X? Example:
val gtk = load_lib "libgtk-quartz-2.0.dylib";
val gtk = ?: dylib
val gtk_init = call2 (load_sym gtk "gtk_init") (INT,INT) VOID;
val gtk_init = fn: int * int -> unit
gtk_init(0,0);
[1] 96630 killed rlwrap -z poly
It doesn't completely surprise me that this crashes: gtk_init has the signature
void gtk_init (int *argc, char ***argv);
so you're using the conversion INT for passing a pointer. INT is same size as the C int, which is likely to be 32 bits on a 64 bit platform. However, on a 64 bit platform, a pointer should be 64 bits. I suspect that this, possibly along with different calling conventions, might cause the variation you see between platforms.
The conversion LONG will give you the C long, usually the same size as a pointer, but you really want to be using the conversions POINTER or POINTERTO for passing pointers.
Out of interest, are you attempting to use GTK+ from SML?
Phil
Yes, I realise this is a bit evil, so maybe it's just lucky that it didn't cause problems on the linux side. However, I get the same crash when I call a test function (with the correct signature) that is simply *linking* the gtk library:
#include <gtk/gtk.h>
int times2(int i) { return i*2; }
This, built with:
gcc -fPIC -c ml_helpers.c -o ml_helpers.o `pkg-config --cflags gtk+-2.0` gcc -shared -Wl -o ../libpolygtk.so ml_helpers.o `pkg-config --libs gtk+-2.0`
To answer your other question: I am in the process of writing some very basic GTK bindings for Poly, at least initially for rapid prototyping and testing. There's a github project:
https://github.com/akissinger/polygtk
I've had success getting the two included examples (some buttons w. callbacks and text entry) working in linux, but this mysterious crash is holding up OS X support.
a
On 25 June 2012 16:27, Phil Clayton phil.clayton@lineone.net wrote:
On 24/06/12 01:47, Aleks Kissinger wrote:
Any idea why calling symbols from certain shared libraries would cause poly/ML to crash on OS X? Example:
val gtk = load_lib "libgtk-quartz-2.0.dylib";
val gtk = ?: dylib
val gtk_init = call2 (load_sym gtk "gtk_init") (INT,INT) VOID;
val gtk_init = fn: int * int -> ?unit
gtk_init(0,0);
[1] ? ?96630 killed ? ? rlwrap -z ?poly
It doesn't completely surprise me that this crashes: gtk_init has the signature
?void gtk_init (int *argc, char ***argv);
so you're using the conversion INT for passing a pointer. ?INT is same size as the C int, which is likely to be 32 bits on a 64 bit platform. However, on a 64 bit platform, a pointer should be 64 bits. ?I suspect that this, possibly along with different calling conventions, might cause the variation you see between platforms.
The conversion LONG will give you the C long, usually the same size as a pointer, but you really want to be using the conversions POINTER or POINTERTO for passing pointers.
Out of interest, are you attempting to use GTK+ from SML?
Phil
On 25/06/12 18:43, Aleks Kissinger wrote:
Yes, I realise this is a bit evil, so maybe it's just lucky that it didn't cause problems on the linux side. However, I get the same crash when I call a test function (with the correct signature) that is simply *linking* the gtk library:
#include<gtk/gtk.h>
int times2(int i) { return i*2; }
This, built with:
gcc -fPIC -c ml_helpers.c -o ml_helpers.o `pkg-config --cflags gtk+-2.0` gcc -shared -Wl -o ../libpolygtk.so ml_helpers.o `pkg-config --libs gtk+-2.0`
Unfortunately I can't reproduce the issue as I don't have OS X. Still, it would be useful to know the exact version of Poly/ML that you are using.
On my machine (Linux x86_64) the file libpolygtk.so, generated with the commands you give, is identical whether or not the #include line is present, which probably explains why I don't get any error. Once the SO file is built, the following works fine:
LD_LIBRARY_PATH=..: poly << ++++ local open CInterface; val lib = load_lib "libpolygtk.so"; in val times2 = call1 (load_sym lib "times2") INT INT; end; times2 3; ++++
To answer your other question: I am in the process of writing some very basic GTK bindings for Poly, at least initially for rapid prototyping and testing. There's a github project:
https://github.com/akissinger/polygtk
I've had success getting the two included examples (some buttons w. callbacks and text entry) working in linux, but this mysterious crash is holding up OS X support.
I've been working on GTK+ bindings for quite a while now. These support both MLton and Poly/ML but it's still not quite ready for release. (Initially I started extending mGTK, but it's now a 100% rewrite.) For that reason, I'm very interested in why including gtk.h breaks dynamic libraries.
Phil
On 25 June 2012 16:27, Phil Claytonphil.clayton@lineone.net wrote:
On 24/06/12 01:47, Aleks Kissinger wrote:
Any idea why calling symbols from certain shared libraries would cause poly/ML to crash on OS X? Example:
val gtk = load_lib "libgtk-quartz-2.0.dylib";
val gtk = ?: dylib
val gtk_init = call2 (load_sym gtk "gtk_init") (INT,INT) VOID;
val gtk_init = fn: int * int -> unit
gtk_init(0,0);
[1] 96630 killed rlwrap -z poly
It doesn't completely surprise me that this crashes: gtk_init has the signature
void gtk_init (int *argc, char ***argv);
so you're using the conversion INT for passing a pointer. INT is same size as the C int, which is likely to be 32 bits on a 64 bit platform. However, on a 64 bit platform, a pointer should be 64 bits. I suspect that this, possibly along with different calling conventions, might cause the variation you see between platforms.
The conversion LONG will give you the C long, usually the same size as a pointer, but you really want to be using the conversions POINTER or POINTERTO for passing pointers.
Out of interest, are you attempting to use GTK+ from SML?
Phil
Okay, I've gotten poly to crash for a simpler example (as reproducing my exact gtk build would a pain...). It seems that the process receives a SIGKILL whenever it tries to load code linking Carbon, which GTK-OSX has the misfortune of doing. Here's how to reproduce the bug on OS X:
/* diff.c */ int difference (int x, int y) { return x > y ? x - y : y - x; }
# test.ML open CInterface; val lib = load_lib "libdiff.so"; val diff = call2 (load_sym lib "difference") (INT,INT) INT; val d = diff (2,3);
Now, running these commands works as expected: $ gcc -c diff.c $ gcc -shared diff.o -o libdiff.so $ poly --use test.ML
But these cause poly to receive a SIGKILL: $ gcc -c diff.c $ gcc -framework Carbon -shared diff.o -o libdiff.so $ poly --use test.ML ... val lib = ?: dylib val diff = fn: int * int -> int [1] 64760 killed poly --use test.ML
Any ideas? Since Carbon is deprecated, I suspect it is coming in to conflict with something used by poly, but I haven't been able to track it down.
On 24 June 2012 01:47, Aleks Kissinger aleks0@gmail.com wrote:
Any idea why calling symbols from certain shared libraries would cause poly/ML to crash on OS X? Example:
val gtk = load_lib "libgtk-quartz-2.0.dylib";
val gtk = ?: dylib
val gtk_init = call2 (load_sym gtk "gtk_init") (INT,INT) VOID;
val gtk_init = fn: int * int -> unit
gtk_init(0,0);
[1] ? ?96630 killed ? ? rlwrap -z ?poly
This (or rather, the equivalent) code works fine on linux, and "libgtk-quartz-2.0.dylib" will link with C code in OS X with no problems. It seems to only do this for some libraries. For instance, the "difference" example from the poly docs (http://www.polyml.org/docs/CInterface.html) also works fine on OS X.
Argh, sorry to spam. It seems Carbon is a red herring. poly/CInterface seems to crash when the code is linking *any* framework via the "-framework XXX" option to gcc.
On 2 July 2012 17:25, Aleks Kissinger aleks0@gmail.com wrote:
Okay, I've gotten poly to crash for a simpler example (as reproducing my exact gtk build would a pain...). It seems that the process receives a SIGKILL whenever it tries to load code linking Carbon, which GTK-OSX has the misfortune of doing. Here's how to reproduce the bug on OS X:
/* diff.c */ int difference (int x, int y) { ? ? return x > y ? x - y : y - x; }
# test.ML open CInterface; val lib = load_lib "libdiff.so"; val diff = call2 (load_sym lib "difference") (INT,INT) INT; val d = diff (2,3);
Now, running these commands works as expected: $ gcc -c diff.c $ gcc -shared diff.o -o libdiff.so $ poly --use test.ML
But these cause poly to receive a SIGKILL: $ gcc -c diff.c $ gcc -framework Carbon -shared diff.o -o libdiff.so $ poly --use test.ML ... val lib = ?: dylib val diff = fn: int * int -> int [1] ? ?64760 killed ? ? poly --use test.ML
Any ideas? Since Carbon is deprecated, I suspect it is coming in to conflict with something used by poly, but I haven't been able to track it down.
On 24 June 2012 01:47, Aleks Kissinger aleks0@gmail.com wrote:
Any idea why calling symbols from certain shared libraries would cause poly/ML to crash on OS X? Example:
val gtk = load_lib "libgtk-quartz-2.0.dylib";
val gtk = ?: dylib
val gtk_init = call2 (load_sym gtk "gtk_init") (INT,INT) VOID;
val gtk_init = fn: int * int -> unit
gtk_init(0,0);
[1] ? ?96630 killed ? ? rlwrap -z ?poly
This (or rather, the equivalent) code works fine on linux, and "libgtk-quartz-2.0.dylib" will link with C code in OS X with no problems. It seems to only do this for some libraries. For instance, the "difference" example from the poly docs (http://www.polyml.org/docs/CInterface.html) also works fine on OS X.
On 02/07/2012 17:30, Aleks Kissinger wrote:
Argh, sorry to spam. It seems Carbon is a red herring. poly/CInterface seems to crash when the code is linking *any* framework via the "-framework XXX" option to gcc.
But these cause poly to receive a SIGKILL: $ gcc -c diff.c $ gcc -framework Carbon -shared diff.o -o libdiff.so $ poly --use test.ML ... val lib = ?: dylib val diff = fn: int * int -> int [1] 64760 killed poly --use test.ML
Have you tried running this with gdb? It would probably be best to build poly for debugging first: make distclean ./configure --enable-debug --disable-shared make
If you manage to get a trace I may be able to make some sense of it.
David
$ gdb --args poly --use test.ML .... .... val lib = ?: dylib val diff = fn: int * int -> int Reading symbols for shared libraries ...................... done
Program received signal SIGTRAP, Trace/breakpoint trap. [Switching to process 75853 thread 0x1703] 0x00007fff8619cedf in __CFInitialize () (gdb) bt #0 0x00007fff8619cedf in __CFInitialize () #1 0x00007fff5fc0fe6f in __dyld__ZN16ImageLoaderMachO11doImageInitERKN11ImageLoader11LinkContextE () #2 0x00007fff5fc0fae7 in __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE () #3 0x00007fff5fc0d2e4 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE () #4 0x00007fff5fc0d27d in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE () #5 0x00007fff5fc0d27d in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE () #6 0x00007fff5fc0e0b7 in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextERNS_21InitializerTimingListE () #7 0x00007fff5fc031b9 in __dyld__ZN4dyld15runInitializersEP11ImageLoader () #8 0x00007fff5fc09657 in __dyld_dlopen () #9 0x00007fff84c5195b in dlopen () #10 0x000000010095f25a in load_lib (taskData=0x100d005b0, string=0x101829a08) at foreign.cpp:738 #11 0x000000010095eff5 in foreign_dispatch_c (taskData=0x100d005b0, args=0x101829a08, fcode_h=0x101829a00) at foreign.cpp:1699 #12 0x00000001009b6634 in X86Dependent::CallIO2 (this=0x100a42d90, taskData=0x100d005b0, ioFun=0x10095eeb0 <foreign_dispatch_c(TaskData*, SaveVecEntry*, SaveVecEntry*)>) at x86_dep.cpp:680 #13 0x00000001009a1576 in EnterPolyCode (taskData=0x100d005b0) at run_time.cpp:1326 #14 0x000000010098ef62 in NewThreadFunction (parameter=0x100d005b0) at processes.cpp:1121 #15 0x00007fff886ad8bf in _pthread_start () #16 0x00007fff886b0b75 in thread_start () (gdb) continue Continuing.
Program received signal SIGKILL, Killed. [Switching to process 75853 thread 0x1307] 0x00007fff8c597bca in __psynch_cvwait () (gdb) bt #0 0x00007fff8c597bca in __psynch_cvwait () #1 0x00007fff886b1274 in _pthread_cond_wait () #2 0x0000000100971b9c in PCondVar::WaitFor (this=0x100a40e48, pLock=0x100a40de8, milliseconds=400) at locking.cpp:244 #3 0x000000010098d287 in Processes::BeginRootThread (this=0x100a40dc0, rootFunction=0x100000e98) at processes.cpp:1315 #4 0x0000000100979994 in polymain (argc=3, argv=0x7fff5fbfef68, exports=0x1009e41c0) at mpoly.cpp:300 #5 0x000000010094f94a in main (argc=3, argv=0x7fff5fbfef68) at polystub.c:43 (gdb) continue Continuing.
Program terminated with signal SIGKILL, Killed. The program no longer exists.
On 2 July 2012 18:19, David Matthews David.Matthews@prolingua.co.uk wrote:
On 02/07/2012 17:30, Aleks Kissinger wrote:
Argh, sorry to spam. It seems Carbon is a red herring. poly/CInterface seems to crash when the code is linking *any* framework via the "-framework XXX" option to gcc.
But these cause poly to receive a SIGKILL: $ gcc -c diff.c $ gcc -framework Carbon -shared diff.o -o libdiff.so $ poly --use test.ML ... val lib = ?: dylib val diff = fn: int * int -> int [1] 64760 killed poly --use test.ML
Have you tried running this with gdb? It would probably be best to build poly for debugging first: make distclean ./configure --enable-debug --disable-shared make
If you manage to get a trace I may be able to make some sense of it.
David
polyml mailing list polyml@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
On 02/07/2012 19:50, Aleks Kissinger wrote:
$ gdb --args poly --use test.ML .... .... val lib = ?: dylib val diff = fn: int * int -> int Reading symbols for shared libraries ...................... done
Program received signal SIGTRAP, Trace/breakpoint trap. [Switching to process 75853 thread 0x1703] 0x00007fff8619cedf in __CFInitialize ()
Right, well a quick check with Google turned up this: http://stackoverflow.com/questions/3414523/debugging-a-crash-when-a-library-...
which references: http://openradar.appspot.com/7209349
Apparently it's all to do with the CoreFoundation library. The second reference gives a couple of possible work-arounds. I'm afraid that things like this seem to happen with Mac OS.
Regards, David
Wow, that's annoying. That does seem to be the issue. Adding the following to my .profile cleared it up:
export DYLD_INSERT_LIBRARIES=/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
a
On 2 July 2012 20:02, David Matthews David.Matthews@prolingua.co.uk wrote:
On 02/07/2012 19:50, Aleks Kissinger wrote:
$ gdb --args poly --use test.ML .... .... val lib = ?: dylib val diff = fn: int * int -> int Reading symbols for shared libraries ...................... done
Program received signal SIGTRAP, Trace/breakpoint trap. [Switching to process 75853 thread 0x1703] 0x00007fff8619cedf in __CFInitialize ()
Right, well a quick check with Google turned up this: http://stackoverflow.com/questions/3414523/debugging-a-crash-when-a-library-...
which references: http://openradar.appspot.com/7209349
Apparently it's all to do with the CoreFoundation library. The second reference gives a couple of possible work-arounds. I'm afraid that things like this seem to happen with Mac OS.
Regards,
David
polyml mailing list polyml@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
-
aleks0＠gmail.com -
David.Matthews＠prolingua.co.uk -
phil.clayton＠lineone.net