OpenDBX

Task #28 — Problem wih Firebird in Linux

Task Type	Bug Report	Severity	Low
Category	Library	Priority	Normal
Status	Closed	Reported Version	1.4.x
Assigned To	No-one	Due in Version	Undecided
Operating System	All	Percent Complete
Details	Hi Norber: I was testing firebird in Ubuntu 9.10. I installed the super server, not the common one. I compile and insall OpenDBX without any problem. Your tests pass perfectly. However, I am having problems in my tests. This is the situation: I am executing the following SQL queries: connect 'SELECT * FROM student' fetch 5 times the next raw. free the resultSet 'SELECT * FROM student order by name_surname'. disconnec When it tries to finish the first resultset, I have this error: *** glibc detected *** /home/ubuntu/squeak/pharo-vm-0.15.2f-linux/squeak: free(): invalid next size (fast): 0x09b95f28 *** This are the order of the functions I am calling: odbx_init called with values: backend = firebird host = port = odbx_bind: called with values: handle = 163128800 database = /home/ubuntu/firebird/sodbxtest2.fdb userName = sodbxtest userPassword = sodbxtest odbx_query: called with values: handle = 163128800 query = SELECT * FROM student odbx_result: called with values: handle = 163128800 chunk = 0 odbx_result call return: 3 odbx_result resultSet handle returned: 163128504 odbx_column_count: called with values: resultSet handle = 163128504 odbx_row_fetch: called with values: resultSet handle = 163128504 odbx_row_fetch call returned 1 odbx_row_fetch: called with values: resultSet handle = 163128504 odbx_row_fetch call returned 1 odbx_row_fetch: called with values: resultSet handle = 163128504 odbx_row_fetch call returned 1 odbx_row_fetch: called with values: resultSet handle = 163128504 odbx_row_fetch call returned 1 odbx_row_fetch: called with values: resultSet handle = 163128504 odbx_row_fetch call returned 1 odbx_result_finish: will be called with values: resultSet handle = 163128504 Here I have the error. I change the function to this (I put flags): static int firebird_odbx_result_finish( odbx_result_t* result ) { DEBUGLOG( result->handle->log.write( &(result->handle->log), 1, "firebird_odbx_result_finish() called" ); ) puts("I get the struct fbc"); struct fbconn* fbc = (struct fbconn*) result->handle->aux; if( fbc != NULL ) { puts("fbc is not null"); if( isc_dsql_free_statement( fbc->status, &(fbc->stmt), DSQL_drop ) != 0 ) { return -ODBX_ERR_BACKEND; } puts("isc_dsql_free_statement was called ok"); if( fbc->trlevel == 0 ) { puts("fbc trlevel is zero"); static char tbuf[] = { isc_tpb_version3, isc_tpb_write, isc_tpb_read_committed, isc_tpb_rec_version }; if( isc_commit_transaction( fbc->status, fbc->tr ) != 0 ) { return -ODBX_ERR_BACKEND; } puts("isc_commit_transaction was called ok"); if( isc_start_transaction( fbc->status, fbc->tr + fbc->trlevel, 1, &(result->handle->generic), sizeof( tbuf ), tbuf ) != 0 ) { return -ODBX_ERR_BACKEND; } puts("isc_start_transaction"); } } puts("Is result generic not null"); if( result->generic != NULL ) { puts(" result generic is not null"); unsigned long i; XSQLVAR* var = ((XSQLDA*) result->generic)->sqlvar; puts("I will free everything"); for( i = 0; i < ((XSQLDA*) result->generic)->sqln; i++ ) { puts("I will free one"); free( var[i].sqldata ); } } puts("firebird_priv_result_free"); firebird_priv_result_free( result ); puts("firebird_priv_result_free called"); return ODBX_ERR_SUCCESS; } And this is the output: I get the struct fbc fbc is not null isc_dsql_free_statement was called ok fbc trlevel is zero isc_commit_transaction was called ok isc_start_transaction Is result generic not null result generic is not null I will free everything I will free one I will free one I will free one I will free one I will free one I will free one *** glibc detected *** /home/ubuntu/squeak/pharo-vm-0.15.2f-linux/squeak: double free or corruption (out): 0x095b8ad0 *** So...maybe we are looping more than we should ? I then added the openDBX log. I attach some files of an example. Additional information: - In Windows in works perfect. - The amount of "I will free one" is not always the same. Sometimes it is 6, 5, 2, 1, etc. Sometimes, after this error, I opened another terminal, open smalltalk again, run the same test again, and it was common that number decrease. And afer restarting in general was 5 o 6. - I tried to put a NULL as timeout, but same results. - I installed the SUPER server, becasue with the classic I have problems. WHat version do you use ? supper or classic ? - I think is something related to threads. Do you have any idea? Let me know if I can do something more. Cheers, Mariano

Closed by  Norbert Sendetzky (nose)
Date:  Sunday, 28 Mar 2010, 3:12pm.
Reason for closing:   Not a bug
Additional comments about closing:  After extended testing the cause of the segfaults seems to be in the application code, not in libopendbx