glib2.0 / Ocilib - GTree inserts sometimes "ð-X" /Secfault while searching

Question

I'm trying to insert values into GTree from oracle. It fails sometimes. The value OCI_GetString (rs, 1) is "111,333,4", but the tree inserts "ð-X". Can I fix it? Or is there any tested alternative implementation of bbt, which you can recommend?
I try to insert values lke this:

int buildQotHash(GTree* tree, char (*str)[3000])
{
    OCI_Connection* cn;
    OCI_Statement* st;
    OCI_Resultset* rs;
    if (!OCI_Initialize(err_handler, NULL, OCI_ENV_DEFAULT))
        return EXIT_FAILURE;

    cn = OCI_ConnectionCreate( "db", "user",  "passwd", OCI_SESSION_DEFAULT);
    st = OCI_StatementCreate(cn);

    OCI_ExecuteStmt(st, "select field1 <cut>, field18  from table");

    rs = OCI_GetResultset(st);
    int i = 1;
    int j = 0;
    while (OCI_FetchNext(rs))
    {

      tic *t         = malloc(sizeof(tic))  ;

      t->qotId           = OCI_GetInt    (rs,  2);
      t->close           = OCI_GetFloat  (rs,  3);
      if (OCI_GetDate(rs, 4) != NULL) OCI_DateToText(OCI_GetDate(rs, 4), "DD.MM.YYYY HH24:MI", 19, t->closeTs );
      t->open            = OCI_GetFloat  (rs,  5);
      t->high            = OCI_GetFloat  (rs,  6);
      t->low             = OCI_GetFloat  (rs,  7);
      t->volume          = OCI_GetFloat  (rs,  8);
      t->ask             = OCI_GetFloat  (rs,  9);
      if (OCI_GetDate(rs, 10) != NULL) OCI_DateToText(OCI_GetDate(rs, 10), "DD.MM.YYYY HH24:MI", 19, t->askTs );
      t->askVolume       = OCI_GetFloat  (rs, 11);
      t->bid             = OCI_GetFloat  (rs, 12);
      if (OCI_GetDate(rs, 13) != NULL) OCI_DateToText(OCI_GetDate(rs, 13), "DD.MM.YYYY HH24:MI", 19, t->bidTs );
      t->bidVolume       = OCI_GetFloat  (rs, 14);
      t->realClose       = OCI_GetFloat  (rs, 15);
      if (OCI_GetDate(rs, 16) != NULL) OCI_DateToText(OCI_GetDate(rs, 16), "DD.MM.YYYY HH24:MI", 19, t->realCloseTs );
      t->settle          = OCI_GetFloat  (rs, 17);
      if (OCI_GetDate(rs, 18) != NULL) OCI_DateToText(OCI_GetDate(rs, 18), "DD.MM.YYYY HH24:MI", 19, t->settleTs );
      const char *tri = OCI_GetString (rs,  1);
      g_tree_insert(tree,(gpointer *) tri, t);
      sprintf(str[j]+strlen(str[j]),"&ik%d=%s", i, tri);
      //i= (i > 99) ? i++ : 0;
      i > 99 ? j++ : j;
      i++;
      if(i>100)i=1;
    }

    OCI_Cleanup();

    return EXIT_SUCCESS;

}

Apart from that, I'm getting secfaul while searching .

I initialize tree like this:

  GTree* t = g_tree_new((GCompareFunc)g_ascii_strcasecmp);

  char subStr[8][3000];
  buildQotHash(t, subStr);

I get the key-value pairs while traversing tree after init:

gboolean iter_all(gpointer key, gpointer value, gpointer data) {
 ticP tp = (ticP) value;
 printf("%s %s\n", (char *)key, tp->closeTs);
 return FALSE;
}

g_tree_foreach(t, (GTraverseFunc)iter_all, NULL);

This line ends up with secfault:

 if( (triP!=NULL) &&( (value = g_tree_lookup(tree, (gpointer *)triP) )!= NULL)  ) fillFields((ticP)value, p);

In the debugger I see:

   (gdb) print tree
    $20 = (GTree *) 0x51c6c0
    (gdb) print triP
    $21 = 0x5ef6a0 "89680,222,402"
    (gdb) print (gpointer *)triP
    $22 = (gpointer *) 0x5ef6a0
    (gdb) print  g_tree_lookup(tree, (gpointer *)triP)

    Program received signal SIGSEGV, Segmentation fault.
    0x00002aaaaac10800 in ?? () from /opt/gnome/lib64/libglib-2.0.so.0
    The program being debugged was signaled while in a function called from GDB.
    GDB remains in the frame where the signal was received.
    To change this behavior use "set unwindonsignal on".
    Evaluation of the expression containing the function
    (g_tree_lookup) will be abandoned.
    When the function is done executing, GDB will silently stop.

Answer 1

It's hard to really tell what's going wrong without being able to run the code (I'm not planning on installing Oracle), but judging by the fact that you're assigning OCI_GetString's return value to a const char*, it's probably owned by the library. My guess is that as soon as you call OCI_FetchNext the value may change (or the associated memory freed). If I were you, the first thing I would try would be to make a copy of that value (using g_strdup), and use the copy in your tree. To prevent leaks you should probably also use g_tree_new_full to allocate your tree with the appropriate destroy notify functions.