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
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/devel
_______________________________________________
Devel mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/devel
