TSQLStatement crashes

Hi Rooters,

I’m running this short script on ROOT 5.18 on SLC 4.6 and get a crash.

    gROOT->Reset();

    TSQLServer *os = TSQLServer::Connect("oracle://dburl","dbname","dbpass");
    TSQLStatement* stmt = os->Statement("SELECT oid,cycledate,run,cycle,temp FROM mdtrun_viewDistinct WHERE run>=1250",100);
    if (stmt->Process()) { //Process statement
        cout<<"Statement Processed!\n";
        stmt->StoreResult(); //store result of statement in buffer
        Int_t nFields = stmt->GetNumFields();
        cout << "NumFields = " << nFields << "\n"; //display info about selected field
        cout<<stmt->GetFieldName(0)<<"\n"; //CRASH: *** glibc detected *** free(): invalid pointer: 0x08372d90 ***
    }
    else
        cout<<"Statement failed to process\n";
    os->Close();

This same bit of code words well for ROOT 5.16.
Any idea why this happens?

Thanks!

Hi

There were no changes in Oracle SQL plugin since ROOT version 5.16.
Therefore, I have following questions:

  1. Do you have now same environment (OS, Oracle InstantClient) as with ROOT 5.16?
  2. Did you compile ROOT yourself or used binary distribution?
  3. That is the value of stmt->GetNumFields()?
    4.Can you provide stack trace or run root with debugger?

Small remark - it is not a good idea to use gROOT->Reset(). Can you comment out it?

Regards,
Sergey

[quote=“linev”]Hi

There were no changes in Oracle SQL plugin since ROOT version 5.16.
Therefore, I have following questions:

  1. Do you have now same environment (OS, Oracle InstantClient) as with ROOT 5.16?
  2. Did you compile ROOT yourself or used binary distribution?
  3. That is the value of stmt->GetNumFields()?
    4.Can you provide stack trace or run root with debugger?

Small remark - it is not a good idea to use gROOT->Reset(). Can you comment out it?

Regards,
Sergey[/quote]

  1. Same OS, same Oracle InstantClient (/usr/lib/oracle/10.2.0.3), but a different machine.
  2. I used the RPMs.
  3. Yes, that’s what happens when doing stmt->GetNumFields();
    When doing stmt->GetInt(0); instead I get:
root [0] .x sqlquery.C
Statement Processed!
NumFields = 5
Error in <TOracleStatement::GetInt>: Code: 32129  Msg: ORA-32129: cannot get information about this column

*** glibc detected *** free(): invalid pointer: 0x087da958 ***
  1. Attached. Is that what you meant?
  2. Commented. Still no go.
    sqlTrace.txt (3.79 KB)

Hi

I mean debug trace, if it produced. Anyway, I see no good reasons why it crashes. There are many checks in GetFieldName() method to avoid any problems like you see.

I propose two more tests, but it may takes time.

  1. Install on this machine version 5.16. Just to prove that Oracle is working. Alternative is run sqlplus (if it is installed on your machine) and try same statements as you doing in script.

  2. Compile version 5.18 from source. For this you need not only Oracle libraries, but also includes installed on this machine. I suspect, that binary ROOT version was compiled with another InstantClient.

Regards,
Sergey

ROOT didn’t produce a debug trace. How do I get it?

  1. sqlplus with the same query works.
  2. Okay, this will take some time.
    Is this the flags used to make the binaries:
    root.cern.ch/root/myconfig/Versi … onfig.html ?
    If so, this is the same as 5.16 and should not be a problem.

Hi

Exactly this options I have in mind.
Probably, you can skip all irrelevant options like mysql, castor and so on.
It is also good idea to add option “–build debug”.

As I can see from configure options, binary ROOT was compiled with Oracle 10.2.0.2, you are using 10.2.0.3. This looks like buf-fix patch, but may also affect interface and be a reason for your problems.

Regards,
Sergey

I’ll try compiling 5.16.

I was using the same libs for 5.16 with no problem, and if Oracle SQL did not change since 5.16 I don’t see a reason for an interface problem.

Turns out the problem was an outdated OCCI as described in here. Needed to download the patched OCCI (10.2.0.3 gcc3.4.3 32bit) from here and install it.

Thanks for the help.