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