FFI, ODBC and mysterious crashes
Simon Kirk
Simon.Kirk at pinesoft.co.uk
Mon Nov 7 11:12:41 UTC 2005
Hi all.
I'm trying to get an ODBC connection working properly between a 3.8
Squeak VM running on unix (gentoo linux) and an Intersystems Caché
database instance, but i'm getting some mysterious issue that is making
Squeak crash with no warning.
Unfortunately I can't debug precisely what's happening in the ODBC
driver for the Caché database as their driver is (naturally) closed-source.
Everything seems fine up to the limit of where I can debug - ie within
the ODBC driver manager (unixODBC in this case, although the same
behaviour is observed with libiodbc). The call goes into the
Intersystems Caché driver, and I can see that a connection happens
through to the database server (an strace reveals this, and the database
global instance count increments). However at some unspecified point
inside the driver, the whole shooting match crashes, Squeak and all. I
should point out that I have no problems connecting to MySQL,
PostgreSQL, etc on my linux machine via Squeak and ODBC. Similarly,
Windows machines don't have this problem either (ie a
Squeak->ODBC->Caché connection works just fine).
At this point this quote from the FFI pages seems pertinent: "FFI allows
you to call functions written in other languages (mostly C)... This of
course implies that you have to play by the rules of the outside (C)
world - or in other words, if you make a mistake you'll not drop into
the debugger but Squeak will just crash."
Seems to me that this is precisely what's happening :)
What I'm wondering is whether there are any candidate activities
happening in the Intersystems Caché closed-source driver library that
may be crashing Squeak due to interaction with FFI? For instance,
debugging the Squeak VM has an interesting effect: I can't step forward
while debugging any code called via FFI (inside the unixODBC driver
manager in this case), as all that happens is I end up here in the VM:
static void sigalrm(int signum) { lowResMSecs += LOW_RES_TICK_MSECS; }.
The only way to get off there is to clear the breakpoint in the driver
manager code (or move it onwards to another point) and allow the code to
continue. Not really relevant, except for the sigalrm call above. A
process can only have one alarm method set via sigalarm at any given
time - so to clarify: If the Intersystems Caché driver is trying to set
up a timer of its own, would that case the VM to crash completely?
I suppose that's just one example of how things can be trampling on each
other, but there doesn't seem to be a lot of detail about things that
can happen while using FFI that will cause issues. I hope somebody can
help shed some light on this for me. I've attached the backtrace from
the point where the Squeak VM dies in the hope that it may contain
something somebody will recognise.
Thanks in advance for any help.
Simon
ps. I will be contacting support at Intersystems as well - but they will
almost certainly baulk if I mention that I'm using Squeak Smalltalk as
they're very unlikely to have ever encountered support queries involving
it before :)
backtrace at VM death:
#0 0xb7e44941 in kill () from /lib/libc.so.6
#1 0x778cfc6d in pthread_kill () from /lib/libpthread.so.0
#2 0x778cffc1 in raise () from /lib/libpthread.so.0
#3 0xb7e446f4 in raise () from /lib/libc.so.6
#4 0xb7e45a66 in abort () from /lib/libc.so.6
#5 0x777b5d28 in __default_terminate () from
/usr/lib/libstdc++-libc6.2-2.so.3
#6 0x777b5d45 in __terminate () from /usr/lib/libstdc++-libc6.2-2.so.3
#7 0x777b6766 in __unwinding_cleanup () from
/usr/lib/libstdc++-libc6.2-2.so.3
#8 0x777b6931 in __throw () from /usr/lib/libstdc++-libc6.2-2.so.3
#9 0x77815155 in SQLConnect () from /opt/cache/bin/libcachecurrent.so
#10 0x7794755a in SQLConnect (connection_handle=0x815edc8,
server_name=0x8161758 "Samples", name_length1=-3, user_name=0x81602b0
"foo", name_length2=-3, authentication=0x81602c0 "bar", name_length3=-3)
at SQLConnect.c:3825
#11 0x779b94e0 in ffiCallAddressOf () at
/home/piumarta/squeak/3.7/platforms/unix/plugins/SqueakFFIPrims/x86-sysv-asm.S:57
#12 0x779b94b7 in ffiCallAddressOfWithReturnType (fn=0, callType=0,
typeSpec=84148226) at
/home/piumarta/squeak/3.7/platforms/unix/plugins/SqueakFFIPrims/x86-sysv.c:316
#13 0x779b5ce0 in ffiCalloutToWithFlags (address=6, callType=2005753844)
at
/home/piumarta/squeak/3.7/platforms/unix/src/plugins/SqueakFFIPrims/SqueakFFIPrims.c:1053
#14 0x779b7a2d in primitiveCallout () at
/home/piumarta/squeak/3.7/platforms/unix/src/plugins/SqueakFFIPrims/SqueakFFIPrims.c:2164
#15 0x08063fc6 in primitiveCalloutToFFI () at gnu-interp.c:12226
#16 0x080614fa in interpret () at gnu-interp.c:7249
#17 0x0805a5fb in main (argc=0, argv=0xbf99c494, envp=0x0) at
/home/piumarta/squeak/3.7/platforms/unix/vm/sqUnixMain.c:1367
This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com
More information about the Squeak-dev
mailing list
|