segmentation fault!!

Hi!. I had a problem with a program in C++ using OCCI libraries. The program runs OK while is "running", but if I put in the console ctlr-c appears a message "segmentation fault"...here is the code.

Code:

---

#include <string.h>
#include <stdlib.h>
#include <iostream>
#include <occi.h>

extern "C"
{
#include "sql_def.h"
};


using namespace oracle::occi;
using namespace std;

      char *sUserDB,*sPswdDB,*idDB;
      Environment *env;
      Connection *con;

int db_connect(char *Usr, char *Pswd, char *Sid)
{
  sUserDB = Usr;
  sPswdDB = Pswd;
 idDB  = Sid;
  cout << "Conectando a la BD."<< endl;
  env = Environment::createEnvironment();
  try
  {
    if (*idDB == 0)
      con = env->createConnection(sUserDB,sPswdDB);
    else
      con = env->createConnection(sUserDB,sPswdDB,idDB);
    return 0;
  }
  catch(SQLException &ex)
  {
    cerr <<ex.getErrorCode() << ": " << ex.getMessage() << endl;
    return -1;
  }
}

int db_disconnect()
{
  env->terminateConnection(con);
  Environment::terminateEnvironment(env);
  cout << "Desconectando la BD." << endl;
  return 0;
}

int main(int argc, char* argv[])
{
 int a = 0;

 db_connect("db_pec","db_pec07","HERACLES");
 db_disconnect();

 cout << "salir:" << endl;
 cin >> a;
 return 0;
}

---

it's a very simple code...thanks

What OS?
At what point in the code is Ctrl-C pressed? Connect, disconnect, or input?
What do you want it to do when Ctrl-C is pressed?

If it's during connect or disconnect, you'll need to check the documentation on how signals are handled - if at all.

gg

The OS is linux (I don't know what distribution).

I press ctrl-c to kill the process. At this moment the process dies but display on the screen a message "segmentation fault".

I think that in the createEnvironment could be the problem. I put

Code:

---

Environment::THREADED_MUTEXED

---

as parameter and works...but I don't know if that's is the bes thing that i can do.

It may not help that much, but if you build your with debug (-g), then do "gdb myapp" and follow your steps to reproduce the problem, you should be able to see the call-stack using "backtrace <n>" to show the last <n> items of the stack (e.g. backtrace 10 will show ten call levels).

--
Mats