[MDEV-3478] LP:460420 - MyISAM segfault in debug binary on ALTER TABLE Created: 2009-10-25  Updated: 2012-10-04  Resolved: 2012-10-04

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Arjen Lentz (Inactive) Assignee: Unassigned
Resolution: Not a Bug Votes: 0
Labels: Launchpad

Attachments: XML File LPexportBug460420.xml    

 Description   

branch from maria-5.1-merge (sorry can't verify exact revid but it's from within last week)
BUILD/compile-pentium-debug-max-no-ndb
So it's a debug binary. run...

CREATE TABLE `actors_movies` (
`actor_id` int(10) unsigned NOT NULL,
`movie_id` int(10) unsigned NOT NULL,
UNIQUE KEY `actor_id` (`actor_id`,`movie_id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

– table is empty
ALTER TABLE actors_movies ENGINE=MyISAM;

segfaults. With gdb attached we find the following:

Program received signal SIGSEGV, Segmentation fault.
0x00000000008911bc in ha_myisam::enable_indexes (this=Cannot access memory at address 0x7fd0dce20868
) at ha_myisam.cc:1444
1444 int ha_myisam::enable_indexes(uint mode)
(gdb) bt
#0 0x00000000008911bc in ha_myisam::enable_indexes (this=Cannot access memory at address 0x7fd0dce20868
) at ha_myisam.cc:1444
#1 0x000000000088bff8 in ha_myisam::end_bulk_insert (this=0x2a8be90, abort=false) at ha_myisam.cc:1610
#2 0x000000000071e108 in handler::ha_end_bulk_insert (this=0x2a8be90, abort=false) at handler.h:1242
#3 0x00000000007c88ac in copy_data_between_tables (from=0x30d9988, to=0x2a8adc8, create=@0x7fd0dce43a38, ignore=false, order_num=0, order=0x0, copied=0x7fd0dce42068, deleted=0x7fd0dce42060,
keys_onoff=LEAVE_AS_IS, error_if_not_empty=false) at sql_table.cc:7677
#4 0x00000000007d4d07 in mysql_alter_table (thd=0x7fd0c18b5298, new_db=0x29d05f8 "imdb", new_name=0x29d0280 "actors_movies", create_info=0x7fd0dce43420, table_list=0x29d02c8, alter_info=0x7fd0dce439f0,
order_num=0, order=0x0, ignore=false) at sql_table.cc:7087
#5 0x0000000000680aaf in mysql_execute_command (thd=0x7fd0c18b5298) at sql_parse.cc:2900
#6 0x0000000000687cdc in mysql_parse (thd=0x7fd0c18b5298, inBuf=0x29d01c0 "alter table actors_movies engine=myisam", length=39, found_semicolon=0x7fd0dce44c00) at sql_parse.cc:5979
#7 0x0000000000688ade in dispatch_command (command=COM_QUERY, thd=0x7fd0c18b5298, packet=0x7fd0c1961859 "alter table actors_movies engine=myisam", packet_length=39) at sql_parse.cc:1223
#8 0x0000000000689f4e in do_command (thd=0x7fd0c18b5298) at sql_parse.cc:862
#9 0x0000000000675a1c in handle_one_connection (arg=0x7fd0c18b5298) at sql_connect.cc:1130
#10 0x00007fd0dc90d3ba in start_thread () from /lib/libpthread.so.0
#11 0x00007fd0db980fcd in clone () from /lib/libc.so.6
#12 0x0000000000000000 in ?? ()

Again, note that this is a debug binary; since DEBUG has different structures, it's quite possible that this only happens in DEBUG binaries and not in regular. Nevertheless, it looks like a bug.

 Comments   
Comment by Arjen Lentz (Inactive) [ 2009-10-26 ]

Re: MyISAM segfault in debug binary on ALTER TABLE
last MB of trace (now with proper flushing) on ftp/private in myisam-debug-alter-segfault-lastMB-proper.trace

the way I generated it this time was... table already existed in MyISAM, empty. I simply did ALTER TABLE tblname ENGINE=MyISAM and that did the trick.

Comment by Sergei Petrunia [ 2009-10-26 ]

Re: MyISAM segfault in debug binary on ALTER TABLE
Cannot repeat. Could this by any chance be because you still have thread_stack=128K in my.cnf file?
Please check out BUG#452116, and this change in particular https://lists.launchpad.net/maria-developers/msg01282.html ?
The mariadb part has been pushed more than a week ago.

I was trying with maria-5.1-merge, with current tip cset:
revno: 2792
committer: Michael Widenius <monty@askmonty.org>
branch nick: maria-tmp
timestamp: Fri 2009-10-23 22:26:26 +0300
message: Automatic merge

Comment by Sergei Petrunia [ 2009-10-26 ]

Re: MyISAM segfault in debug binary on ALTER TABLE
Changing to invalid. Please re-open if the suggestion in the last message is not true.

Comment by Arjen Lentz (Inactive) [ 2009-10-26 ]

Re: [Bug 460420] Re: MyISAM segfault in debug binary on ALTER TABLE
Hi Sergey

On 26/10/2009, at 8:11 PM, Sergey Petrunia wrote:
> Cannot repeat. Could this by any chance be because you still have
> thread_stack=128K in my.cnf file?
> Please check out BUG#452116, and this change in particular https://lists.launchpad.net/maria-developers/msg01282.html
> ?
> The mariadb part has been pushed more than a week ago.

Ah - ya I was working from slight older packages I'd created, for
others reasons. Indeed 128K stack configured. Changed. I'll keep an
eye on it.

However, can the server just enforce a sane minimum, perhaps? If 128K
is not enough, what is?
Lots of things actually worked, just ALTER TABLE to MyISAM segfaulted,
but alter table to InnoDB worked fine. It'd be good if mysqld just
refused to use a size <whatever.

> I was trying with maria-5.1-merge, with current tip cset:
> revno: 2792
> committer: Michael Widenius <monty@askmonty.org>
> branch nick: maria-tmp
> timestamp: Fri 2009-10-23 22:26:26 +0300
> message: Automatic merge
>
> –
> MyISAM segfault in debug binary on ALTER TABLE
> https://bugs.launchpad.net/bugs/460420
> You received this bug notification because you are a member of Maria-
> captains, which is the registrant for Maria.

–
Arjen Lentz, Exec.Director @ Open Query (http://openquery.com)
Exceptional Services for MySQL at a fixed budget.

Follow our blog at http://openquery.com/blog/
OurDelta: enhanced builds for MySQL @ http://ourdelta.org

Comment by Michael Widenius [ 2009-10-26 ]

Re: [Bug 460420] Re: MyISAM segfault in debug binary on ALTER TABLE

Hi!

>>>>> "Arjen" == Arjen Lentz <arjen@openquery.com> writes:

Arjen> Hi Sergey
Arjen> On 26/10/2009, at 8:11 PM, Sergey Petrunia wrote:
>> Cannot repeat. Could this by any chance be because you still have
>> thread_stack=128K in my.cnf file?
>> Please check out BUG#452116, and this change in particular https://lists.launchpad.net/maria-developers/msg01282.html
>> ?
>> The mariadb part has been pushed more than a week ago.

Arjen> Ah - ya I was working from slight older packages I'd created, for
Arjen> others reasons. Indeed 128K stack configured. Changed. I'll keep an
Arjen> eye on it.

Arjen> However, can the server just enforce a sane minimum, perhaps? If 128K
Arjen> is not enough, what is?
Arjen> Lots of things actually worked, just ALTER TABLE to MyISAM segfaulted,
Arjen> but alter table to InnoDB worked fine. It'd be good if mysqld just
Arjen> refused to use a size <whatever.

We do refuse some sizes, but it's actually hard to predict the exact
minimum size (too many variables and access paths).
Also for 32 bit and 64 bit the min stack size is totally different.

So the best we can do is that when we notice a problem, we increment
the min allowed stack size...

Regards,
Monty

Comment by Arjen Lentz (Inactive) [ 2009-10-26 ]

Re: [Bug 460420] Re: MyISAM segfault in debug binary on ALTER TABLE
Hi Monty

On 27/10/2009, at 1:58 AM, Michael Widenius wrote:
>>>>>> "Arjen" == Arjen Lentz <arjen@openquery.com> writes:
> Arjen> On 26/10/2009, at 8:11 PM, Sergey Petrunia wrote:
>>> Cannot repeat. Could this by any chance be because you still have
>>> thread_stack=128K in my.cnf file?
>>> Please check out BUG#452116, and this change in particular https://lists.launchpad.net/maria-developers/msg01282.html
>>> ?
>>> The mariadb part has been pushed more than a week ago.
>
> Arjen> Ah - ya I was working from slight older packages I'd created,
> for
> Arjen> others reasons. Indeed 128K stack configured. Changed. I'll
> keep an
> Arjen> eye on it.
>
> Arjen> However, can the server just enforce a sane minimum, perhaps?
> If 128K
> Arjen> is not enough, what is?
> Arjen> Lots of things actually worked, just ALTER TABLE to MyISAM
> segfaulted,
> Arjen> but alter table to InnoDB worked fine. It'd be good if mysqld
> just
> Arjen> refused to use a size <whatever.
>
> We do refuse some sizes, but it's actually hard to predict the exact
> minimum size (too many variables and access paths).
> Also for 32 bit and 64 bit the min stack size is totally different.
>
> So the best we can do is that when we notice a problem, we increment
> the min allowed stack size...

Yep so that's what I'm asking... you upping that min allowed number?
And the compile knows the difference between 32/64 bit and platforms/
architectures, so it can handle that.

Also, while thread_stack_size * max_connections can add up, people
generally have sufficient memory for this.
Like at 200K, 1000 connections will just eat 200M. That's peanuts on a
64bit box (that's what we're discussing here).
32bit should be way less, so that's good too.

Thanks

Cheers,
Arjen.
–
Arjen Lentz, Exec.Director @ Open Query (http://openquery.com)
Exceptional Services for MySQL at a fixed budget.

Follow our blog at http://openquery.com/blog/
OurDelta: enhanced builds for MySQL @ http://ourdelta.org

Comment by Rasmus Johansson (Inactive) [ 2009-10-26 ]

Launchpad bug id: 460420

Generated at Thu Feb 08 06:48:55 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.