Tasos> I am wondering if we can get past the "send a test case" responses; as you very
Tasos> well know I have sent you tables that cause isamchk to dump core, the core
Tasos> file from isamchk and the core file from mysqld, as well as the queries
Tasos> about 3 weeks ago.
The major problems with your mail was that you sent us the isam files
in binary format and I couldn't do anything with them until I got
access to a Sparc machine. I have also searched in my mail archive,
but couldn't find a single resent mail from you that include the
output from the 'mysqlbug' script. This output is essential in most
cases to even start looking in finding the bug!
Tasos> I will make one last attempt to put the "test case" on the ftp area. BTW, I
Tasos> you that isamchk -r on the table WORKS, isamchk -r -f DOES NOT (core dump)
Tasos> and for some unexplained reason you do not want to test it that way.
The problem is that isamchk -r -f works for me on the tables you sent
The only thing -f should do is that it does a 'unlink' of the name.TMD
file. (This can't cause the crash; This means that it's -r that
causes the crash...)
As I have said in my previous mails to you; I got your files and I did run a
isamchk -r and isamchk -r -f on then om my Solaris 2.7 sparc machine
and I didn't find any problems with them!
Even 'isamchk -e' didn't find any problems with the file!
Are you sure you did try:
isamchk -e lw_subscribers_248368333
Here is a sample run:
(/my/data/test) isamchk -e lw_subscribers_248368333
Checking ISAM file: lw_subscribers_248368333
Data records: 23 Deleted blocks: 0
- check file-size
- check delete-chain
- check index reference
- check data record references index: 1
- check data record references index: 2
- check data record references index: 3
- check data record references index: 4
- check data record references index: 5
- check data record references index: 6
- check data record references index: 7
- check data record references index: 8
- check data record references index: 9
- check data record references index: 10
- check records and index references
(/my/data/test) isamchk -r -f lw_subscribers_248368333
- recovering ISAM-table 'lw_subscribers_248368333.ISM'
Data records: 23
- Fixing index 1
- Fixing index 2
- Fixing index 3
- Fixing index 4
- Fixing index 5
- Fixing index 6
- Fixing index 7
- Fixing index 8
- Fixing index 9
- Fixing index 10
The core file you posted didn't help me in any way (one should by the
way NEVER post core files) :(
Are you sure you did run:
isamchk -r -f lw_subscribers_248368333
isamchk -r -f *.ISM
(We recently found a problem when running isamchk -r on many tables at
the same time; This should be fixed in 3.22.25)
Tasos> As fara as the question on the distribution goes, we downloaded it from your web
Sorry to ask again, but which MySQL distribution did you use?
I can't help you as long as I don't get all information I need (and
preferable in the same mail).
I assume you know that we require even our support customers to follow the
rules that are outlined at:
PLEASE read the above before reposting your question, this will save us all
a lot of time!
A test case is a file that includes:
- The tables that produce the error.
- A sample TESTED command that shows something doesn't work with
the included files!
- A full description of the error + all a sample run.
- All information from mysqlbug.
This would enable us to give the test case to any of our developers
and let him quickly find out what's wrong.
Please be kind and reply with mysqlbug next time you have a problem!
On the file you did send to us, the query:
select email,reverse(email) AS rev from lw_subscribers_248368333 where (userid > 0 and
status = 0) and mail_mode=6 GROUP BY email ORDER BY rev ASC LIMIT 0,-1
worked without any problems on my MySQL version..
I did however finally have access to my Sparc machine with Purify and
found a problem with reverse on an empty BLOB columns.
Here is a patch for this:
*** /my/monty/master/mysql-3.22.24/sql/item_strfunc.cc Wed Apr 28 23:17:53 1999
--- ./item_strfunc.cc Sat Aug 28 08:48:51 1999
*** 157,162 ****
--- 157,165 ----
+ /* An empty string is a special case as the string pointer may be null */
+ if (!res->length())
+ return &empty_string;
ptr = (char *) res->ptr();
Note that I found this problem by piecing together information from a
lot of different mails and this took me 3 hours instead of 10 minutes,
which would have been the case of a proper bug report!
We REALLY try to find and fix all bugs as quickly as possible. The
problem is that to do this we need anything that we can repeat in some
way as easily as possible.
For win32 you can fix this temporarily by changing the email column to
a CHAR() instead of a BLOB().