Simple 1 master, 1 slave replication fails totally, looks like garbage in binlogs (no replies)

Hello,

I've got what should be a very simple set up, but I can't get it to work at all.

I have one master, one slave. Everything's set up and looks ok, but the actual replication fails on the slave, apparently because the binary logs from the master contain garbage interspersed among the statements.

Details.

Master is 5.0.18 (running on SuSE). Slave is 5.1.41 (on Ubuntu). Master has been running for years, but this is the first time we've tried to replicate from it. Slave is brand new.

Slave copies the binlogs across fine, but the relay_log_pos is stuck on almost the first statement:
Last_SQL_Errno: 1300
Last_SQL_Error: Error 'Invalid utf8 character string: ''' on query. Default database: 'My_DB_Name'. Query: 'INSERT My_Table SET LA_Code = NAME_CONST('sLA_Code','

Looking in the binlogs (on both the slave and the master), it seems that the statmement which I would expect to look like:
INSERT My_Table SET LA_Code = NAME_CONST('sLA_Code',_latin1'S02' COLLATE 'latin1_swedish_ci'), ...
(which is taken from a working test master, running 5.1 and using statement-based replication too), actually looks like:
INSERT My_Table SET LA_Code = NAME_CONST('sLA_Code',<80>^@^@^@^@^@^@^@^@<81><A8>^B^@^@^@^@^P^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@pu^LD^@^@^@^@^B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ZT^@^@^@^@^@^@<81><A8>^B^@^@^@^@<93><FD>x^@^@^@^@^@_latin1'S02'), ...
where the stuff from <80> up until _latin1 is all binary garbage, mostly zeros.

Looking through the logs, it seems that every use of NAME_CONST() with a string value has the same sort of garbage prepended to the _latin1 qualifier on the string. This stuff is all being inserted by stored procs, so just about every statement is added to the log using NAME_CONST().

One thought that occured to me is that the names of the character sets have been corrupted on the master somehow, but I don't know how to check for that.

Does anyone have any suggestions of what I can try next ? (Short of ditching this server -- which is actually what we want to do, but we've got to keep it going for a few weeks or months longer).

Thanks for reading.

-- chris