[Devel] Problem with table_version in db.c

[Matty]

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.

Thanks for any insight,
- Ryan
--
UNIX Administrator
http://daemons.net/~matty