2 Replies Latest reply on Apr 15, 2016 2:09 PM by JeffHenry

    FMS 14 Crashes when using ODBC connections

    JeffHenry

      Hi FM Community,

       

      I have a hosting client that uses ODBC connections to their hosted database files frequently for live events. More than once, we've had FileMaker Server crash at these live events. No logs were thrown by the server admin console that would point to a direct cause, so I check out the Mac OS X Console to see what I can find.

       

      Here's a snippet from the most recent log:

       

      Crashed Thread:        53

       

      Exception Type:        EXC_CRASH (SIGABRT)

      Exception Codes:       0x0000000000000000, 0x0000000000000000

       

      Application Specific Information:

      abort() called

      *** error for object 0x7fb7b02c0a00: pointer being freed was not allocated

       

      <-- SNIP -->

       

      Thread 53 Crashed:

      0   libsystem_kernel.dylib        0x00007fff969e2286 __pthread_kill + 10

      1   libsystem_c.dylib             0x00007fff914439ab abort + 129

      2   libsystem_malloc.dylib        0x00007fff9a0101cb free + 428

      3   atopnsrc.so                   0x0000000115c56d61 SQLTablesW + 189577

      4   atopnsrc.so                   0x0000000115c4356d SQLTablesW + 109717

      5   atopnsrc.so                   0x0000000115c43628 SQLTablesW + 109904

      6   atopnsrc.so                   0x0000000115c46945 SQLTablesW + 122989

      7   atopnsrc.so                   0x0000000115c44a63 SQLTablesW + 115083

      8   atopnsrc.so                   0x0000000115b2561a 0x115ae0000 + 284186

      9   atopnsrc.so                   0x0000000115b39efb 0x115ae0000 + 368379

      10  atopnsrc.so                   0x0000000115bf454c SQLCopyDesc + 24962

      11  atopnsrc.so                   0x0000000115b240ad 0x115ae0000 + 278701

      12  atopnsrc.so                   0x0000000115c1d1f1 SQLExecDirectW + 1009

      13  com.filemaker.dbengine.framework 0x000000010d00c204 SQLExecDirect_Internal + 548

      14  com.filemaker.dbengine.framework 0x000000010d00c764 SQLExecDirectW + 228

      15  com.filemaker.dbengine.framework 0x000000010d331ea8 FMODBC::ODBCQuery::ExecuteDirect(Draco::unistring const&, long long) + 548

      16  com.filemaker.dbengine.framework 0x000000010d33b0bc FMODBC::RCODBCQuery::PerformOperation() + 1304

      17  com.filemaker.dbengine.framework 0x000000010d3974a3 Draco::RCUploadDownload::Perform() + 625

      18  com.filemaker.dbengine.framework 0x000000010d3a715f Draco::RCNetworkStack::DispatchTransaction(Draco::RCConnection*, unsigned int, unsigned char*, unsigned int) + 1395

      19  com.filemaker.dbengine.framework 0x000000010d3a6a31 RPO_i::Perform(unsigned int, char const*, unsigned int, OctetSeq&, OctetSeq_out) + 173

      20  com.filemaker.dbengine.framework 0x000000010d3a26ab _0RL_lcfn_07aabdf5dad7309d_70000000(omniCallDescriptor*, omniServant*) + 176

      21  com.filemaker.omniorb4.framework 0x000000010d919cef omniCallHandle::upcall(omniServant*, omniCallDescriptor&) + 1099

      22  com.filemaker.dbengine.framework 0x000000010d3a3adf _impl_RCFMP12::_dispatch(omniCallHandle&) + 1871

      23  com.filemaker.omniorb4.framework 0x000000010da0b5bf omni::omniOrbPOA::dispatch(omniCallHandle&, omniLocalIdentity*) + 715

      24  com.filemaker.omniorb4.framework 0x000000010d9e37b2 omniLocalIdentity::dispatch(omniCallHandle&) + 94

      25  com.filemaker.omniorb4.framework 0x000000010d973ba6 omni::GIOP_S::handleRequest() + 330

      26  com.filemaker.omniorb4.framework 0x000000010d973805 omni::GIOP_S::dispatcher() + 323

      27  com.filemaker.omniorb4.framework 0x000000010d990ad6 omni::giopWorker::real_execute() + 1378

      28  com.filemaker.omniorb4.framework 0x000000010d990cc6 omni::giopWorker::execute() + 46

      29  com.filemaker.omniorb4.framework 0x000000010d9961d7 omniAsyncWorker::real_run() + 657

      30  com.filemaker.dbengine.framework 0x000000010d03d44e Draco::threadCreateInterceptor(omni::omniInterceptors::createThread_T::info_T&) + 22

      31  com.filemaker.omniorb4.framework 0x000000010d996482 omniAsyncWorker::run(void*) + 46

      32  com.filemaker.omniorb4.framework 0x000000010da1ae49 omni_thread_wrapper + 148

      33  libsystem_pthread.dylib       0x00007fff984fe05a _pthread_body + 131

      34  libsystem_pthread.dylib       0x00007fff984fdfd7 _pthread_start + 176

      35  libsystem_pthread.dylib       0x00007fff984fb3ed thread_start + 13

       

      I'm wondering if anyone has experience this and knows a possible cause? Bad ODBC query? Is it a network connection thing? I'm not too familiar on the ODBC aspect, but from what I know, they have the ODBC drivers configured properly because the system works normally, but we occasionally experience these crashes. I'm trying to determine if it is something that I as the server admin can repair, or if it is something their developers need to look at on the other end of the ODBC Connections.

       

      Best,

      Jeff Henry

        • 1. Re: FMS 14 Crashes when using ODBC connections
          TSGal

          JeffHenry:

           

          Thank you for your post.

           

          A bad ODBC query should not cause a crash.  The crash report centers around the Actual Technologies driver.  Do you know what was the query when the crash occurred?  Have you performed the same query previously?  If not, see if the same query causes the crash.

           

          Any other information you can provide about your computing environment may be helpful in narrowing down the crash.

           

          TSGal

          FileMaker, Inc.

          • 2. Re: FMS 14 Crashes when using ODBC connections
            JeffHenry

            Hi TSGal,

             

            I've reached out to Actual Technologies as well to get their feedback on the crash. I'm waiting on my client to see if they can provide the Query details for you.

             

            This is FileMaker 14.0.4 running on OS X 10.10.5.

             

            I will reply back if I get more info.

             

            Thank you,

            Jeff Henry