[Devel] Problem with table_version in db.c

[Daniel-Constantin Mierla]

Hello,

On 07/02/06 20:07, Matty wrote:
>
> Howdy,
>
> When I attempt to start openser, I am greeted with the following error 
> (please continue reading for the reason why):
>
> $ openser
>
> [ ..... ]
>  0(0) usrloc:preload_udomain: Wrong version v2134024 for table 
> <location>, expected v1001
>  0(0) register_udomain(): Error while preloading domain 'location'
>  0(0) pool_remove: Removing connection from the pool
>  0(0) domain_fixup(): Error while registering domain
>
> I checked the MySQL database (5.22) table and the query being issued, 
> and they both check out:
>
> $ mysql -uroot -p -hmysql
> Enter password:
> Welcome to the MySQL monitor.  Commands end with ; or \g.
> Your MySQL connection id is 35 to server version: 5.0.22-log
>
> Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
>
> mysql> use openser
> Reading table information for completion of table and column names
> You can turn off this feature to get a quicker startup with -A
>
> Database changed
> mysql>  select table_version from version where table_name='location';
> +---------------+
> | table_version |
> +---------------+
> |          1001 |
> +---------------+
> 1 row in set (0.00 sec)
>
> To see what was going on, I added a break point to table_version and 
> dumped res.rows.values just prior to the function returning:
>
> (gdb) p *res.rows.values
> $7 = {type = DB_STRING, nul = 0, val = {int_val = 2134056,
>       double_val = 4.6067679823539676e-308, time_val = 2134056,
>       string_val = 0x209028 "1001", str_val = {s = 0x209028 "1001",
>       len = 0}, blob_val = {s = 0x209028 "1001", len = 0},
>       bitmap_val = 2134056}}
>
> Upon inspecting the code in table_version, I noticed that the VAL_INT 
> MACRO is used to return val.int_val to the calling function:
>
> /* From db.c */
> ret = VAL_INT(ROW_VALUES(RES_ROWS(res)));
> dbf->free_result(connection, res);
> return ret;
>
> When I dump val.int_val with gdb, I get differenet results each time 
> the program runs:
>
> (gdb) p *res.rows.values.val.int_val
> $10 = 825241649
>
> I did a bit more digging, and it looks like the 'type' field is set to 
> 2 (DB_STRING) after the query completes, and val.str_val.s contains 
> the result:
>
> (gdb) x/s res.rows.values.val.str_val.s
> 0x209028:        "1001"
>
> With that said, is there a reason that the "type" field isn't checked 
> on return from the query, and the appropriate result used? I can 
> submit the patches I am using to address this problem, but I wanted to 
> check with the development folks to see why the VAL_INT macro is 
> always used.
VAL_INT is used because the table_version should be integer number, but 
seems not to be in your case. Please check the structure of table 'version'.

describe version;
show create table version;

However, the check of the result type should be done as you suggested, I 
will commit it soon.

Cheers,
Daniel


>
> Thanks for any insight,
> - Ryan
> -- 
> UNIX Administrator
> http://daemons.net/~matty
>
> _______________________________________________
> Devel mailing list
> Devel at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/devel
>