ruby sqlanywhere hangs in semop

[former_SQLA_member1694976]

i hope someone is able to help. i am writing an app using the sqlanywhere ruby extension with rails 3.2 and ruby 1.9.3. the following backtrace shows whats happening. (freezes in rails console / rails server is running as it seems to reuse the connection). How should/could i proceed ?

#0  0x00007fff9887dc46 in semop ()
#1  0x000000010a282074 in Java_com_sybase_asa_logon_ASAConnect_findServers ()
#2  0x000000010a205119 in Java_com_sybase_asa_logon_ASAConnect_findServers ()
#3  0x000000010a2052bd in Java_com_sybase_asa_logon_ASAConnect_findServers ()
#4  0x000000010a205335 in Java_com_sybase_asa_logon_ASAConnect_findServers ()
#5  0x000000010a21605d in Java_com_sybase_asa_logon_ASAConnect_findServers ()
#6  0x000000010a21770b in Java_com_sybase_asa_logon_ASAConnect_findServers ()
#7  0x000000010a1e86df in Java_com_sybase_asa_logon_ASAConnect_findServers ()
#8  0x000000010a1e8fd4 in Java_com_sybase_asa_logon_ASAConnect_findServers ()
#9  0x000000010a1ea069 in Java_com_sybase_asa_logon_ASAConnect_findServers ()
#10 0x000000010a1ea85a in Java_com_sybase_asa_logon_ASAConnect_findServers ()
#11 0x000000010a1d87b2 in sqlerror_message ()
#12 0x000000010a1d8afb in sqlerror_message ()
#13 0x000000010a1ca2a9 in sqlany_new_connection_ex ()
#14 0x0000000109bcbd00 in static_SQLAnywhereInterface_sqlany_connect (str=140447491704520, imp_drh=140734956844704, sqlany_conn=140447549318784)
    at sqlanywhere.c:409
#15 0x000000010970420b in call_cfunc (func=0x109bcbca0 <static_sqlanywhereinterface_sqlany_connect>, recv=140447516575120, len=2061125320, argc=1763449976,
    argv=0x51dd7600) at vm_insnhelper.c:326

[former_SQLA_member1694976]

a few background informations i forgot to mention: This is a rails app running on OSX Lion. I'm using the rails32 branch of activerecord-sqlanywhere-adapter. And i am not alone. Brandon hit this wall too... But i'g guess that this is at least an blocking error within the sybase client code...

[Former Member]

We get exactly the same problem and callstack when trying to connect through the C api on OS X. This looks like it's not a Ruby-specific problem, though it might be specific to the OS X build of SqlAnywhere, as we've not seen it happen on other platforms.

Doesn't happen every time, but frequently gets into this state. We only see it when a debugger is attached (although that might just be a timing factor). In our experience, this behaviour usually seems to be connected with extra dbeng12 processes hanging around and never closing down.

(Killing those extra processes usually doesn't solve the problem). Have not yet found a workaround, though this is causing serious problems for us.

[former_SQLA_member1694976]

tpowell,

first thanks for your answer.

i'd suggest a problem with the osx build too. The weired thing is, that the rails server command works perfect. (and it is opening two connections too / like the rails console does)

i'm now running an ubuntu vmware on my development machine with rsyncing the git tree to get console functionality.

Maybe this is a "workaround" for you too ...

[jeff_albion]

• Which version of the C API do you have installed from SQL Anywhere? (libdbcapi_r.dylib)

• What's the connection string that you are using - are you trying to start a database server using auto-start or is the database server already running?

• This stack trace looks remarkably familiar in reference to the C API on Mac OS X: http://sqlanywhere-forum.sap.com/questions/13540/dbeng12-startup-hang-on-osx

I do note that our default code is using RTLD_LAZY for loading the shared library by default - if you can provide a short Ruby example that will definitely show the hang issue upon connect, I can investigate the issue further to see if changing this load flag changes the behaviour inside Rails.

[former_SQLA_member1694976]

Jeff,

version is: VERSION_CLASS=GA VERSION_MAJOR=12 VERSION_MINOR=0 VERSION_PATCH=1 BUILD_NUMBER=3901 POINTERSIZE=32 PLATFORM=macosx DATE=2013/05/10 TIME=23:31:33 HOST=dbm105 THREADS=posix PRODUCTION=production COMPILER=gnu UNAME=Darwin dbm105 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1-RELEASE_I386 i386 IDENT=libdbcapi_r.dylib/12.0.1/P/i386/Darwin 9.8.0/3901/OPT/Fri May 10 23:31:33 EDT 2013

Database Connection String is: ServerName=lxdbsrv;DatabaseName=F2;UserID=U0;Password=xxx;CommLinks=tcpip(Host=172.16.71.100:2638);ConnectionName=RailsLexware;CharSet=Windows-1252;Idle=0

i did test with RTLD_NOW too - but without success...

A short Ruby example ist difficult, as my setup is slightly complex. I am writing a Bridge Software between Lexware (an german ERP software) and Shopware (a german Online Shop Software). Lexware is running within a Win7 VM. I develop on a OSX Macbook Pro. Said console works only within the Ubuntu Vmware. rails server works on OSX...

If you have a hint how to test more with this (i flooded the sqlanywhere extension with tons of printf's to find a difference between rails server and rails console / without success...) i'd be willing to do so...

best paul

[Former Member]

I should have stated, @JeffAlbion; that remarkably similar stack trace is us. I hadn't realised we'd posted the issue here. The RTLD_LAZY loading of the DLLs got us around the problem for quite a while, but the issue has since returned.

I should go update that original question; RTLD_LAZY appears to have simply shuffled timing around enough to avoid some timing issues at the time, without actually solving the underlying issue.

[Former Member]

I just thought I should add to the discussion seeing as I'm the one that raised the issue that Jeff has linked to.

We though we had this problem solved by changing the library load to RTLD_NOW but it appears as Trevor (tpowell) has pointed out above that we have not.

We are now seeing this in release builds as well as debug ones and is severely affecting our beta program...