Crash with myisam-recover=BACKUP,FORCE in MySQL-4.1

Hi,

I've just hit a bug which crashes mysql when myisam-recover is used.

How-to-repeat :

Launch MySQL with --myisam-recover=BACKUP,FORCE option.
Then MySQL seems to crash when a check is performed on a table and at the
same time a SELECT COUNT(*) FROM table is performed.

021023 9:47:39 InnoDB: Started
/usr/local/mysql/libexec/mysqld: ready for connections
021023 9:48:59 Warning: Checking table: './Hardwarefr/inscrit'
021023 9:48:59 Warning: Checking table:
'./Hardwarefr/moderationhardwarefr'
021023 9:48:59 Warning: Checking table:
'./Hardwarefr/forumcathardwarefr'
021023 9:49:00 Warning: Checking table: './Hardwarefr/multinick1'
021023 9:49:01 Warning: Checking table: './Hardwarefr/prive'
021023 9:49:03 Warning: Recovering table: './Hardwarefr/prive'
021023 9:49:17 Warning: Checking table: './Hardwarefr/threadhardwarefr1'
mysqld got signal 11;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose
the problem, but since we have already crashed, something is definitely
wrong
and this may fail.

key_buffer_size=824176640
read_buffer_size=1044480
sort_buffer_size=1048568
max_used_connections=4
max_connections=320
threads_connected=2
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections =
1458937 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x87efd80
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0xbe1ff048, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x80a0cb1
0x8283ba8
0x827901d
0x8263b50
0x80c8aa6
0x80c9b2f
0x80c7a76
0x80ab079
0x80afd89
0x80a9e97
0x80a9b2f
0x80a940f
0x828143a
0x82b58ea
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://www.mysql.com/doc/U/s/Using_stack_trace.html and follow
instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x87f8938 = SELECT COUNT(*) FROM threadhardwarefr1
thd->thread_id=22

The manual page at http://www.mysql.com/doc/C/r/Crashing.html contains
information that should help you find out what is causing the crash.

Number of processes running now: 0
021023 09:49:41 mysqld restarted
021023 9:49:42 InnoDB: Database was not shut down normally.
InnoDB: Starting recovery from log files...
InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 2 1911238256
InnoDB: Doing recovery: scanned up to log sequence number 2 1911238256
021023 9:49:42 InnoDB: Flushing modified pages from the buffer pool...
021023 9:49:42 InnoDB: Started
/usr/local/mysql/libexec/mysqld: ready for connections
021023 9:49:42 Warning: Checking table: './Hardwarefr/threadhardwarefr2'
mysqld got signal 11;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose
the problem, but since we have already crashed, something is definitely
wrong
and this may fail.

key_buffer_size=824176640
read_buffer_size=1044480
sort_buffer_size=1048568
max_used_connections=2
max_connections=320
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections =
1458937 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x874bc00
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0xbe7ff048, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x80a0cb1
0x8283ba8
0x827901d
0x8263b50
0x80c8aa6
0x80c9b2f
0x80c7a76
0x80ab079
0x80afd89
0x80a9e97
0x80a9b2f
0x80a940f
0x828143a
0x82b58ea
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://www.mysql.com/doc/U/s/Using_stack_trace.html and follow
instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x87698f0 = SELECT COUNT(*) FROM threadhardwarefr2
thd->thread_id=1

Unfortunately, I have not the resolved stack trace available since I didn't
have a valid mysqld.sym file at the time of the crash.

If you really need the resolved stack trace, I will try to reproduce the bug
this night. Please let me know.

Regards,
Jocelyn


------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)

To request this thread, e-mail bugs-thread12827@lists.mysql.com
To unsubscribe, e-mail

Re: Crash with myisam-recover=BACKUP,FORCE in MySQL-4.1

Jocelyn Fournier writes:
> Hi,
>
> I've just hit a bug which crashes mysql when myisam-recover is used.
>
> How-to-repeat :
>
> Launch MySQL with --myisam-recover=BACKUP,FORCE option.
> Then MySQL seems to crash when a check is performed on a table and at the
> same time a SELECT COUNT(*) FROM table is performed.
>

> Some pointers may be invalid and cause the dump to abort...
> thd->query at 0x87698f0 = SELECT COUNT(*) FROM threadhardwarefr2
> thd->thread_id=1
>
> Unfortunately, I have not the resolved stack trace available since I didn't
> have a valid mysqld.sym file at the time of the crash.
>
> If you really need the resolved stack trace, I will try to reproduce the bug
> this night. Please let me know.
>
> Regards,
> Jocelyn
>

Hi!

This seems highly unlikely with our locking system, but if you could
come up with a repeatable test case, we would be gratefull.

--
Regards,
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Sinisa Milivojevic
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Fulltime Developer
/_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus
<___/ www.mysql.com


------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)

To request this thread, e-mail bugs-thread12828@lists.mysql.com
To unsubscribe, e-mail

Re: Crash with myisam-recover=BACKUP,FORCE in MySQL-4.1

Hi,

I've just uploaded a table which allows to make a repeatable test case at
support.mysql.com/pub/mysql/secret/myisam-repair.tar.gz

To repeat the crash, it's quite simple :

run mysql with --myisam-recover=BACKUP,FORCE --skip-external-locking
options.

Then :

mysql> SELECT COUNT(*) FROM forumconthardwarefr12;
ERROR 2013: Lost connection to MySQL server during query

Regards,
Jocelyn

----- Original Message -----
From: "Sinisa Milivojevic"
To:
Cc:
Sent: Wednesday, October 23, 2002 4:27 PM
Subject: Re: Crash with myisam-recover=BACKUP,FORCE in MySQL-4.1


> Jocelyn Fournier writes:
> > Hi,
> >
> > I've just hit a bug which crashes mysql when myisam-recover is used.
> >
> > How-to-repeat :
> >
> > Launch MySQL with --myisam-recover=BACKUP,FORCE option.
> > Then MySQL seems to crash when a check is performed on a table and at
the
> > same time a SELECT COUNT(*) FROM table is performed.
> >
>
> > Some pointers may be invalid and cause the dump to abort...
> > thd->query at 0x87698f0 = SELECT COUNT(*) FROM threadhardwarefr2
> > thd->thread_id=1
> >
> > Unfortunately, I have not the resolved stack trace available since I
didn't
> > have a valid mysqld.sym file at the time of the crash.
> >
> > If you really need the resolved stack trace, I will try to reproduce the
bug
> > this night. Please let me know.
> >
> > Regards,
> > Jocelyn
> >
>
> Hi!
>
> This seems highly unlikely with our locking system, but if you could
> come up with a repeatable test case, we would be gratefull.
>
> --
> Regards,
> __ ___ ___ ____ __
> / |/ /_ __/ __/ __ \/ / Mr. Sinisa Milivojevic
> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Fulltime Developer
> /_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus
> <___/ www.mysql.com
>
>


------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)

To request this thread, e-mail bugs-thread12829@lists.mysql.com
To unsubscribe, e-mail

Re: Crash with myisam-recover=BACKUP,FORCE in MySQL-4.1

Jocelyn Fournier writes:
> Hi,
>
> I've just uploaded a table which allows to make a repeatable test case at
> support.mysql.com/pub/mysql/secret/myisam-repair.tar.gz
>
> To repeat the crash, it's quite simple :
>
> run mysql with --myisam-recover=BACKUP,FORCE --skip-external-locking
> options.
>
> Then :
>
> mysql> SELECT COUNT(*) FROM forumconthardwarefr12;
> ERROR 2013: Lost connection to MySQL server during query
>
> Regards,
> Jocelyn
>

Thanks ...

--
Regards,
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Sinisa Milivojevic
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Fulltime Developer
/_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus
<___/ www.mysql.com


------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)

To request this thread, e-mail bugs-thread12830@lists.mysql.com
To unsubscribe, e-mail

Re: Crash with myisam-recover=BACKUP,FORCE in MySQL-4.1

Just in case, here is the resolved stack trace :

0x80a0cb1 handle_segfault(int) + 481
0x8283ba8 pthread_sighandler + 176
0x827901d sm_10 + 0
0x8263b50 my_message + 32
0x80c8aa6 JOIN::exec() + 246
0x80c9b2f mysql_select(THD*, st_table_list*, List&, Item*, st_order*,
st_order*, Item*, st_order*, unsigned long, select_result*,
st_select_lex_unit*, st_select_lex*) + 111
0x80c7a76 handle_select(THD*, st_lex*, select_result*) + 246
0x80ab079 mysql_execute_command(THD*) + 873
0x80afd89 mysql_parse(THD*, char*, unsigned) + 153
0x80a9e97 dispatch_command(enum_server_command, THD*, char*, unsigned) + 855
0x80a9b2f do_command(THD*) + 111
0x80a940f handle_one_connection(void*) + 895
0x828143a pthread_start_thread + 218
0x82b58ea thread_start + 4

Regards,
Jocelyn
----- Original Message -----
From: "Sinisa Milivojevic"
To:
Cc:
Sent: Wednesday, October 23, 2002 4:51 PM
Subject: Re: Crash with myisam-recover=BACKUP,FORCE in MySQL-4.1


> Jocelyn Fournier writes:
> > Hi,
> >
> > I've just uploaded a table which allows to make a repeatable test case
at
> > support.mysql.com/pub/mysql/secret/myisam-repair.tar.gz
> >
> > To repeat the crash, it's quite simple :
> >
> > run mysql with --myisam-recover=BACKUP,FORCE --skip-external-locking
> > options.
> >
> > Then :
> >
> > mysql> SELECT COUNT(*) FROM forumconthardwarefr12;
> > ERROR 2013: Lost connection to MySQL server during query
> >
> > Regards,
> > Jocelyn
> >
>
> Thanks ...
>
> --
> Regards,
> __ ___ ___ ____ __
> / |/ /_ __/ __/ __ \/ / Mr. Sinisa Milivojevic
> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Fulltime Developer
> /_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus
> <___/ www.mysql.com
>
>


------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)

To request this thread, e-mail bugs-thread12831@lists.mysql.com
To unsubscribe, e-mail

Re: Crash with myisam-recover=BACKUP,FORCE in MySQL-4.1

Hello Jocelyn,

Thank you for this bug report.

I was able to reproduce and has good backtrace for it so we will fix it
ASAP.


I am trying to test one more of your bugs, but I need more information
about it.

It is about yourt SIGHUP patch - I can't have enough beckground info
except than your patch. Can you give me more details or at least point
me to your postings to bugs@lists.mysql.com so I can find them.



--
For technical support contracts, visit https://order.mysql.com/?ref=msal
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Alexander Keremidarski
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Full-Time Developer
/_/ /_/\_, /___/\___\_\___/ Sofia, Bulgaria
<___/ www.mysql.com M: +359 88 231668



------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)

To request this thread, e-mail bugs-thread12849@lists.mysql.com
To unsubscribe, e-mail

Re: Crash with myisam-recover=BACKUP,FORCE in MySQL-4.1

Hi Alexander,

I will try to summarize the problem :

If INSERT DELAYED thread are present and a SIGHUP occurs, then some delayed
thread seem to "lock" the insertion into the table (all process which try to
access to the tables concerned by the delayed threads are in "waiting for
table" state) :

e.g. :

mysql> show processlist;
+--------+---------+-----------+------------+--------------- -+------+-------
-------------+---------------------------------------------- ----------------
----------------------------------------+
| Id | User | Host | db | Command | Time | State
| Info
|
+--------+---------+-----------+------------+--------------- -+------+-------
-------------+---------------------------------------------- ----------------
----------------------------------------+
| 58174 | DELAYED | localhost | Hardwarefr | Delayed_insert | 9409 |
Waiting for INSERT |
|
|
| 100582 | DELAYED | localhost | Hardwarefr | Delayed_insert | 38 |
Waiting for INSERT |
|
| 100759 | DELAYED | localhost | Hardwarefr | Delayed_insert | 542 |
Waiting for INSERT |
|
| 103907 | mysql | localhost | Hardwarefr | Query | 6458 |
Waiting for table | SELECT topic FROM
searchconthardwarefr8,forumconthardwarefr8 WHERE
topic=forumconthardwarefr8.numero |
| 104343 | mysql | localhost | Hardwarefr | Query | 6458 |
Waiting for table | SELECT topic FROM searchconthardwarefr8 WHERE
(mot='biproc') AND date >= '2002-06-27' |
| 104390 | mysql | localhost | Hardwarefr | Query | 6459 |
Waiting for table | SELECT topic FROM
searchconthardwarefr8,forumconthardwarefr8 WHERE
topic=forumconthardwarefr8.numero |
| 104486 | mysql | localhost | Hardwarefr | Query | 6458 |
Waiting for table | SELECT topic FROM
searchconthardwarefr8,forumconthardwarefr8 WHERE
topic=forumconthardwarefr8.numero |
| 106291 | mysql | localhost | Hardwarefr | Query | 6085 |
Waiting for table | SELECT topic FROM
searchconthardwarefr8,forumconthardwarefr8 WHERE
topic=forumconthardwarefr8.numero |
| 141991 | mysql | localhost | Hardwarefr | Sleep | 1 |
| NULL
|
| 141992 | root | localhost | NULL | Query | 0 | NULL
| show processlist
|
| 141993 | mysql | localhost | Hardwarefr | Sleep | 6 |
| NULL
|

| 142029 | mysql | localhost | Hardwarefr | Sleep | 0 |
| NULL
|
+--------+---------+-----------+------------+--------------- -+------+-------
-------------+---------------------------------------------- ----------------
----------------------------------------+
317 rows in set (0.04 sec)


If you take a look at mysqld.cc, you can see :

case SIGHUP:
reload_acl_and_cache((THD*) 0,
(REFRESH_LOG | REFRESH_TABLES | REFRESH_FAST |
REFRESH_STATUS | REFRESH_GRANT | REFRESH_THREADS
|
REFRESH_HOSTS),
(TABLE_LIST*) 0); // Flush logs
mysql_print_status((THD*) 0); // Send debug some info


In sql_parse.cc, we have :


bool reload_acl_and_cache(THD *thd, ulong options, TABLE_LIST *tables)
{

if (options & (REFRESH_TABLES | REFRESH_READ_LOCK))
{
if ((options & REFRESH_READ_LOCK) && thd)
{
if (lock_global_read_lock(thd))
return 1;
}
result=close_cached_tables(thd,(options & REFRESH_FAST) ? 0 : 1,
tables);
}


Thus, when a SIGHUP occurs, close_cached_tables(0, 0, 0) is called. (since
REFRESH_FAST is set, as well as REFRESH_TABLES)

In sql_base.cc, we have :

bool close_cached_tables(THD *thd, bool if_wait_for_refresh,
TABLE_LIST *tables)
{

if (!tables)
{
while (unused_tables)
{
#ifdef EXTRA_DEBUG
if (hash_delete(&open_cache,(byte*) unused_tables))
printf("Warning: Couldn't delete open table from hash\n");
#else
VOID(hash_delete(&open_cache,(byte*) unused_tables));
#endif
}
refresh_version++; // Force close of open
tables
}

if (if_wait_for_refresh)
{
/*
If there is any table that has a lower refresh_version, wait until
this is closed (or this thread is killed) before returning
*/
if (!tables)
kill_delayed_threads();
thd->mysys_var->current_mutex= &LOCK_open;
thd->mysys_var->current_cond= &COND_refresh;
thd->proc_info="Flushing tables";



As if_wait_for_refresh is set to 0, and tables is set to 0, we force close
of open table, but we never call kill_delayed_threads, which causes the bug.

It's why I think

if (!tables)
kill_delayed_threads();

should be outside of if (if_wait_for_refresh) condition. (it solves the
problem for me)


Regards,
Jocelyn

----- Original Message -----
From: "Alexander Keremidarski"
To: "Jocelyn Fournier"
Cc: "Sinisa Milivojevic" ;
Sent: Thursday, October 24, 2002 3:14 PM
Subject: Re: Crash with myisam-recover=BACKUP,FORCE in MySQL-4.1


> Hello Jocelyn,
>
> Thank you for this bug report.
>
> I was able to reproduce and has good backtrace for it so we will fix it
> ASAP.
>
>
> I am trying to test one more of your bugs, but I need more information
> about it.
>
> It is about yourt SIGHUP patch - I can't have enough beckground info
> except than your patch. Can you give me more details or at least point
> me to your postings to bugs@lists.mysql.com so I can find them.
>
>
>
> --
> For technical support contracts, visit https://order.mysql.com/?ref=msal
> __ ___ ___ ____ __
> / |/ /_ __/ __/ __ \/ / Mr. Alexander
Keremidarski
> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Full-Time Developer
> /_/ /_/\_, /___/\___\_\___/ Sofia, Bulgaria
> <___/ www.mysql.com M: +359 88 231668
>
>
>
> ------------------------------------------------------------ ---------
> Before posting, please check:
> http://www.mysql.com/manual.php (the manual)
> http://lists.mysql.com/ (the list archive)
>
> To request this thread, e-mail bugs-thread12849@lists.mysql.com
> To unsubscribe, e-mail
>
>


------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)

To request this thread, e-mail bugs-thread12852@lists.mysql.com
To unsubscribe, e-mail

SIGHUP and INSERT DELAYED

On Thu, 2002-10-24 at 16:46, Jocelyn Fournier wrote:
> Hi Alexander,
>
> I will try to summarize the problem :
>
> If INSERT DELAYED thread are present and a SIGHUP occurs, then some delayed
> thread seem to "lock" the insertion into the table (all process which try to
> access to the tables concerned by the delayed threads are in "waiting for
> table" state) :

I was not able to reproduce this effect :(

How did you exactly tested it? By sending kill -HUP to mysqld master
process?

What release did you use? I checked the code you are refering to - it is
same in 4.0 and 4.1.



Best regards

--
For technical support contracts, visit https://order.mysql.com/?ref=msal
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Alexander Keremidarski
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Full-Time Developer
/_/ /_/\_, /___/\___\_\___/ Sofia, Bulgaria
<___/ www.mysql.com M: +359 88 231668



------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)

To request this thread, e-mail bugs-thread12858@lists.mysql.com
To unsubscribe, e-mail

Re: SIGHUP and INSERT DELAYED

Hi,

I'm using release 4.1 but the code is the same in 4.0 and 4.1. (and perhaps
in 3.23 too)
I wasn't able to reproduce the bug by sending a kill -HUP, so in order to
test my fix, I created a new keyword "SIGHUP" in the sql lexer/yacc which
called :

reload_acl_and_cache((THD*) 0,
(REFRESH_LOG | REFRESH_TABLES | REFRESH_FAST |
REFRESH_STATUS | REFRESH_GRANT | REFRESH_THREADS
|
REFRESH_HOSTS),
(TABLE_LIST*) 0); // Flush logs
mysql_print_status((THD*) 0); // Send debug some info

Without the fix, the queries on delayed table became in "waiting for table"
state, and after the fix, as delayed thread was properly killed, the problem
didn't occur anymore.
In fact I also wonder how to envoke the "case SIGHUP:" in mysqld.cc (since
kill -HUP doesn't work).
Anyway, every now and then I can see in the .err the result of
mysql_print_status, so it's definitively called (but I don't know why /
how).

i.e. :

[root@forum] /home/mysql> tail -n1000 forum.hardware.fr.err


021023 10:12:52 mysqld ended

021023 10:12:53 mysqld started
021023 10:12:54 InnoDB: Started
/usr/local/mysql/libexec/mysqld: ready for connections

Status information:

Current dir: /home/mysql/
Current locks:
lock: 8623f4fc:

lock: 8974e9c:

lock: 892f204:

lock: 893055c:

lock: 88f9b3c:

lock: 88b9e5c:

lock: 86193fcc:

lock: 861915a4:

lock: 861d1eb4:

lock: 861bd004:

lock: 8896584:

lock: 8756064:

lock: 88bbbcc:

lock: 8776e34:

lock: 88a1e6c:

lock: 88e9074:

lock: 88a691c:

lock: 88a032c:

lock: 88fcb4c:

lock: 88c8804:

lock: 8494cfc:

lock: 88e342c:

lock: 8615c924:

lock: 8615afe4:

lock: 877371c:

lock: 88a2fd4:

lock: 8613ba74:

lock: 86139dfc:

lock: 86138184:

lock: 8613650c:

lock: 86134894:

lock: 86132c1c:

lock: 86130fa4:

lock: 8612f32c:

lock: 8612d6b4:

lock: 86112a64:

lock: 8611aa94:

lock: 8611da54:

lock: 8751354:

lock: 8760ea4:

lock: 5459fd4c:

lock: 5454f0ac:

lock: 541fe104:

lock: 5415cb14:

lock: 5410c25c:

lock: 53db61e4:

lock: 53d65544:

lock: 537058ec:

lock: 53701c04:

lock: 537747f4:

lock: 87e40ac:

lock: 53725c74:

lock: 5371bf74:

lock: 5371393c:

key_cache status:
blocks used: 156530
not flushed: 0
w_requests: 0
writes: 0
r_requests: 0
reads: 0

handler status:
read_key: 0
read_next: 0
read_rnd 0
read_first: 0
write: 0
delete 0
update: 0

Table status:
Opened tables: 0
Open tables: 37
Open files: 75
Open streams: 0

Alarm status:
Active alarms: 3
Max used alarms: 18
Next alarm time: 0


Regards,
Jocelyn

----- Original Message -----
From: "Alexander Keremidarski"
To: "Jocelyn Fournier"
Cc: "Sinisa Milivojevic" ;
Sent: Friday, October 25, 2002 3:04 PM
Subject: SIGHUP and INSERT DELAYED


> On Thu, 2002-10-24 at 16:46, Jocelyn Fournier wrote:
> > Hi Alexander,
> >
> > I will try to summarize the problem :
> >
> > If INSERT DELAYED thread are present and a SIGHUP occurs, then some
delayed
> > thread seem to "lock" the insertion into the table (all process which
try to
> > access to the tables concerned by the delayed threads are in "waiting
for
> > table" state) :
>
> I was not able to reproduce this effect :(
>
> How did you exactly tested it? By sending kill -HUP to mysqld master
> process?
>
> What release did you use? I checked the code you are refering to - it is
> same in 4.0 and 4.1.
>
>
>
> Best regards
>
> --
> For technical support contracts, visit https://order.mysql.com/?ref=msal
> __ ___ ___ ____ __
> / |/ /_ __/ __/ __ \/ / Mr. Alexander
Keremidarski
> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Full-Time Developer
> /_/ /_/\_, /___/\___\_\___/ Sofia, Bulgaria
> <___/ www.mysql.com M: +359 88 231668
>
>
>


------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)

To request this thread, e-mail bugs-thread12862@lists.mysql.com
To unsubscribe, e-mail

Re: SIGHUP and INSERT DELAYED

Hi,

Here are the changes I've done (using latest bk 4.1 tree), in order to test
my patch :

===== lex.h 1.78 vs edited =====
--- 1.78/sql/lex.h Wed Oct 2 15:42:47 2002
+++ edited/lex.h Fri Oct 25 15:22:59 2002
@@ -312,6 +312,7 @@
{ "RTREE", SYM(RTREE_SYM),0,0},
{ "SECOND", SYM(SECOND_SYM),0,0},
{ "SELECT", SYM(SELECT_SYM),0,0},
+ { "SIGHUP", SYM(SIGHUP_SYM),0,0},
{ "SERIALIZABLE", SYM(SERIALIZABLE_SYM),0,0},
{ "SESSION", SYM(SESSION_SYM),0,0},
{ "SET", SYM(SET),0,0},
===== sql_yacc.yy 1.193 vs edited =====
--- 1.193/sql/sql_yacc.yy Fri Oct 25 02:42:33 2002
+++ edited/sql_yacc.yy Fri Oct 25 15:28:35 2002
@@ -138,6 +138,7 @@
%token ROLLBACK_SYM
%token ROLLUP_SYM
%token SELECT_SYM
+%token SIGHUP_SYM
%token SHOW
%token SLAVE
%token SQL_THREAD
@@ -611,7 +612,7 @@
%type internal_variable_name

%type
- query verb_clause create change select do drop insert replace
insert2
+ query verb_clause create change sighup select do drop insert replace
insert2
insert_values update delete truncate rename
show describe load alter optimize flush
reset purge begin commit rollback slave master_def master_defs
@@ -695,11 +696,25 @@
| set
| slave
| show
+ | sighup
| truncate
| handler
| unlock
| update
| use;
+
+
+sighup:
+ SIGHUP_SYM
+ {
+ reload_acl_and_cache((THD*) 0,
+ (REFRESH_LOG | REFRESH_TABLES | REFRESH_FAST |
+ REFRESH_STATUS | REFRESH_GRANT |
REFRESH_THREADS |
+ REFRESH_HOSTS),
+ (TABLE_LIST*) 0); // Flush logs
+ mysql_print_status((THD*) 0); // Send debug some info
+ };
+

/* change master */


Regards,
Jocelyn

----- Original Message -----
From: "Alexander Keremidarski"
To: "Jocelyn Fournier"
Cc: "Sinisa Milivojevic" ;
Sent: Friday, October 25, 2002 3:04 PM
Subject: SIGHUP and INSERT DELAYED


> On Thu, 2002-10-24 at 16:46, Jocelyn Fournier wrote:
> > Hi Alexander,
> >
> > I will try to summarize the problem :
> >
> > If INSERT DELAYED thread are present and a SIGHUP occurs, then some
delayed
> > thread seem to "lock" the insertion into the table (all process which
try to
> > access to the tables concerned by the delayed threads are in "waiting
for
> > table" state) :
>
> I was not able to reproduce this effect :(
>
> How did you exactly tested it? By sending kill -HUP to mysqld master
> process?
>
> What release did you use? I checked the code you are refering to - it is
> same in 4.0 and 4.1.
>
>
>
> Best regards
>
> --
> For technical support contracts, visit https://order.mysql.com/?ref=msal
> __ ___ ___ ____ __
> / |/ /_ __/ __/ __ \/ / Mr. Alexander
Keremidarski
> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Full-Time Developer
> /_/ /_/\_, /___/\___\_\___/ Sofia, Bulgaria
> <___/ www.mysql.com M: +359 88 231668
>
>
>


------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)

To request this thread, e-mail bugs-thread12860@lists.mysql.com
To unsubscribe, e-mail

Re: Crash with myisam-recover=BACKUP,FORCE in MySQL-4.1

Hi!

On Wed, Oct 23, 2002 at 03:41:28PM +0200, Jocelyn Fournier wrote:
> Hi,
>
> I've just hit a bug which crashes mysql when myisam-recover is used.
>
> How-to-repeat :
>
> Launch MySQL with --myisam-recover=BACKUP,FORCE option.
> Then MySQL seems to crash when a check is performed on a table and at the
> same time a SELECT COUNT(*) FROM table is performed.
[skip]

Thank you for bugreport! Sorry for delayed reply, but I had problem with
reproducing this bug, but I reproduced this bug with help of Alexander
Keremidarski and fixed it:

diff -Nrc a/sql/log_event.cc b/sql/log_event.cc
*** a/sql/log_event.cc Mon Nov 4 01:02:38 2002
--- b/sql/log_event.cc Mon Nov 4 01:02:38 2002
***************
*** 841,849 ****
VOID(pthread_mutex_lock(&LOCK_thread_count));
thd->query_id = query_id++;
VOID(pthread_mutex_unlock(&LOCK_thread_count));
! thd->query_error = 0; // clear error
! thd->net.last_errno = 0;
! thd->net.last_error[0] = 0;
thd->slave_proxy_id = thread_id; // for temp tables

/*
--- 841,849 ----
VOID(pthread_mutex_lock(&LOCK_thread_count));
thd->query_id = query_id++;
VOID(pthread_mutex_unlock(&LOCK_thread_count));
! thd->query_error= 0; // clear error
! thd->clear_error();
!
thd->slave_proxy_id = thread_id; // for temp tables

/*
diff -Nrc a/sql/mini_client.cc b/sql/mini_client.cc
*** a/sql/mini_client.cc Mon Nov 4 01:02:38 2002
--- b/sql/mini_client.cc Mon Nov 4 01:02:38 2002
***************
*** 451,456 ****
--- 451,457 ----

mysql->net.last_error[0]=0;
mysql->net.last_errno=0;
+ mysql->net.report_error=0;
mysql->info=0;
mysql->affected_rows= ~(my_ulonglong) 0;
net_clear(net); /* Clear receive buffer */
diff -Nrc a/sql/sql_base.cc b/sql/sql_base.cc
*** a/sql/sql_base.cc Mon Nov 4 01:02:38 2002
--- b/sql/sql_base.cc Mon Nov 4 01:02:38 2002
***************
*** 1464,1472 ****
}
}
pthread_mutex_unlock(&LOCK_open);
! thd->net.last_error[0]=0; // Clear error message
! thd->net.last_errno=0;
! error=0;
if (openfrm(path,alias,
(uint) (HA_OPEN_KEYFILE | HA_OPEN_RNDFILE | HA_GET_INDEX |
HA_TRY_READ_ONLY),
--- 1464,1471 ----
}
}
pthread_mutex_unlock(&LOCK_open);
! thd->clear_error(); // Clear error message
! error= 0;
if (openfrm(path,alias,
(uint) (HA_OPEN_KEYFILE | HA_OPEN_RNDFILE | HA_GET_INDEX |
HA_TRY_READ_ONLY),
***************
*** 1476,1483 ****
(entry->file->is_crashed() && entry->file->check_and_repair(thd)))
{
/* Give right error message */
! thd->net.last_error[0]=0;
! thd->net.last_errno=0;
my_error(ER_NOT_KEYFILE, MYF(0), name, my_errno);
sql_print_error("Error: Couldn't repair table: %s.%s",db,name);
if (entry->file)
--- 1475,1481 ----
(entry->file->is_crashed() && entry->file->check_and_repair(thd)))
{
/* Give right error message */
! thd->clear_error();
my_error(ER_NOT_KEYFILE, MYF(0), name, my_errno);
sql_print_error("Error: Couldn't repair table: %s.%s",db,name);
if (entry->file)
***************
*** 1486,1493 ****
}
else
{
! thd->net.last_error[0]=0; // Clear error message
! thd->net.last_errno=0;
}
pthread_mutex_lock(&LOCK_open);
unlock_table_name(thd,&table_list);
--- 1484,1490 ----
}
else
{
! thd->clear_error(); // Clear error message
}
pthread_mutex_lock(&LOCK_open);
unlock_table_name(thd,&table_list);
diff -Nrc a/sql/sql_class.h b/sql/sql_class.h
*** a/sql/sql_class.h Mon Nov 4 01:02:38 2002
--- b/sql/sql_class.h Mon Nov 4 01:02:38 2002
***************
*** 625,630 ****
--- 625,636 ----
void add_changed_table(const char *key, long key_length);
CHANGED_TABLE_LIST * changed_table_dup(const char *key, long key_length);
int send_explain_fields(select_result *result);
+ inline void clear_error()
+ {
+ net.last_error[0]= 0;
+ net.last_errno= 0;
+ net.report_error= 0;
+ }
};

/*
diff -Nrc a/sql/sql_insert.cc b/sql/sql_insert.cc
*** a/sql/sql_insert.cc Mon Nov 4 01:02:38 2002
--- b/sql/sql_insert.cc Mon Nov 4 01:02:38 2002
***************
*** 1180,1186 ****
table->file->extra(HA_EXTRA_IGNORE_DUP_KEY);
using_ignore=1;
}
! thd.net.last_errno = 0; // reset error for binlog
if (write_record(table,&info))
{
info.error_count++; // Ignore errors
--- 1180,1186 ----
table->file->extra(HA_EXTRA_IGNORE_DUP_KEY);
using_ignore=1;
}
! thd.clear_error(); // reset error for binlog
if (write_record(table,&info))
{
info.error_count++; // Ignore errors
diff -Nrc a/sql/sql_parse.cc b/sql/sql_parse.cc
*** a/sql/sql_parse.cc Mon Nov 4 01:02:38 2002
--- b/sql/sql_parse.cc Mon Nov 4 01:02:38 2002
***************
*** 857,864 ****
old_timeout=net->read_timeout;
// Wait max for 8 hours
net->read_timeout=(uint) thd->variables.net_wait_timeout;
! net->last_error[0]=0; // Clear error message
! net->last_errno=0;

net_new_transaction(net);
if ((packet_length=my_net_read(net)) == packet_error)
--- 857,863 ----
old_timeout=net->read_timeout;
// Wait max for 8 hours
net->read_timeout=(uint) thd->variables.net_wait_timeout;
! thd->clear_error(); // Clear error message

net_new_transaction(net);
if ((packet_length=my_net_read(net)) == packet_error)


--
For technical support contracts, visit https://order.mysql.com/
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Oleksandr Byelkin
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Full-Time Developer
/_/ /_/\_, /___/\___\_\___/ Lugansk, Ukraine
<___/ www.mysql.com

------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)

To request this thread, e-mail bugs-thread12895@lists.mysql.com
To unsubscribe, e-mail

Re: SIGHUP and INSERT DELAYED

Jocelyn Fournier writes:
> Hi,
>
> Any news about this bug ? Have you been able to reproduce it ? :)
>
> Thanks and regards,
> Jocelyn
>

Hi!

Yes, we have worked on this issue.

However, problem is that we are not able to reproduce a problem in
real-life.

It simply is not good enough for us to reproduce it virtually, i.e. by
inserting SIGHUP in the code.

--
Regards,
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Sinisa Milivojevic
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Fulltime Developer
/_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus
<___/ www.mysql.com


------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)

To request this thread, e-mail bugs-thread12915@lists.mysql.com
To unsubscribe, e-mail

Re: SIGHUP and INSERT DELAYED

Hi,

The main question is how to make mysql entering this part of the code (ie
introducing a sighup), and why it enters this part of the code :). AFAIK, it
seems to occur only under high load.

Regards,
Jocelyn
----- Original Message -----
From: "Sinisa Milivojevic"
To:
Cc: ;
Sent: Friday, November 08, 2002 11:38 AM
Subject: Re: SIGHUP and INSERT DELAYED


> Jocelyn Fournier writes:
> > Hi,
> >
> > Any news about this bug ? Have you been able to reproduce it ? :)
> >
> > Thanks and regards,
> > Jocelyn
> >
>
> Hi!
>
> Yes, we have worked on this issue.
>
> However, problem is that we are not able to reproduce a problem in
> real-life.
>
> It simply is not good enough for us to reproduce it virtually, i.e. by
> inserting SIGHUP in the code.
>
> --
> Regards,
> __ ___ ___ ____ __
> / |/ /_ __/ __/ __ \/ / Mr. Sinisa Milivojevic
> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Fulltime Developer
> /_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus
> <___/ www.mysql.com
>
>
>
>


------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)

To request this thread, e-mail bugs-thread12916@lists.mysql.com
To unsubscribe, e-mail

Re: SIGHUP and INSERT DELAYED

Jocelyn Fournier writes:
> Hi,
>
> The main question is how to make mysql entering this part of the code (ie
> introducing a sighup), and why it enters this part of the code :). AFAIK, it
> seems to occur only under high load.
>
> Regards,
> Jocelyn

Possible.

OK, we shall try to reproduce in vivo under high load.

--
Regards,
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Sinisa Milivojevic
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Fulltime Developer
/_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus
<___/ www.mysql.com


------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)

To request this thread, e-mail bugs-thread12917@lists.mysql.com
To unsubscribe, e-mail

Re: Crash with myisam-recover=BACKUP,FORCE in MySQL-4.1

Hi!

>>>>> "Jocelyn" == Jocelyn Fournier writes:

Jocelyn> Hi Alexander,
Jocelyn> I will try to summarize the problem :

Jocelyn> If INSERT DELAYED thread are present and a SIGHUP occurs, then some delayed
Jocelyn> thread seem to "lock" the insertion into the table (all process which try to
Jocelyn> access to the tables concerned by the delayed threads are in "waiting for
Jocelyn> table" state) :



Jocelyn> As if_wait_for_refresh is set to 0, and tables is set to 0, we force close
Jocelyn> of open table, but we never call kill_delayed_threads, which causes the bug.

Jocelyn> It's why I think

Jocelyn> if (!tables)
Jocelyn> kill_delayed_threads();

Jocelyn> should be outside of if (if_wait_for_refresh) condition. (it solves the
Jocelyn> problem for me)

Yes, this is right. I have now fixed this in the MySQL 4.0 tree.
(Will push this shortly).

Thanks a lot for finding this bug!

Regards,
Monty

--
For technical support contracts, goto https://order.mysql.com/
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Michael Widenius
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, CTO
/_/ /_/\_, /___/\___\_\___/ Helsinki, Finland
<___/ www.mysql.com

------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)

To request this thread, e-mail bugs-thread12952@lists.mysql.com
To unsubscribe, e-mail