crash log on fairly boring select statement

[Jeff Waugh]

drizzled crashed on a fairly boring select statement. It seemed very stable before I built it again with curl, pam and event support. I will attach a copy of the crash log.

session->query at 0x8b74fd0 = SELECT YEAR(post_date) AS `year`, MONTH(post_date) AS `month`, count(ID) as posts FROM test_posts WHERE post_type = 'post' AND post_status = 'publish' GROUP BY YEAR(post_date), MONTH(post_date) ORDER BY post_date DESC

[Monty Taylor (mordred)]

Assigning to Jay. The crash is triggered by an out_of_bounds exception thrown in std::string::substr. There are only two places in the code using substr, the gearman_functions plugin and temporal_format.cc. In gearman_functions, all substr calls are related to iterators on the same string, so it seems highly unlikely that it's the cause. Also, the query in question is using dates. :) I had a brief look, but it's doing things with the internal match vectors, so I figured Jay will grok it quicker than me.

[Jeff Waugh (jdub)]

Yep, looks like I can reproduce this on pretty much every date-oriented query in WordPress (in trunk and staging). Thanks!

[Jay Pipes (jaypipes)]

Hi Jeff!

Any chance you might be able to paste a schema and small data set that I can use in reproducing these bugs? I'm puzzled that our existing test cases haven't tested this and would like to add your schema and data set to a new test case.

Thanks!

Jay

[Jay Pipes (jaypipes)]

Jeff,

Which version of Drizzle are you using?

Also, I need a little more data to resolve this... when trying to reproduce the bug, I mock up a data set and I can't get the test to fail, as shown in the output below..

Welcome to the Drizzle client.. Commands end with ; or \g.
Your Drizzle connection id is 2
Server version: 2009.06.1057-bugs Source distribution

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

drizzle> use test
Database changed
drizzle> create table t1 (id int not null, post_date datetime not null, primary key (id));
Query OK, 0 rows affected (0.01 sec)

drizzle> insert into t1 values (1, '2009-08-02');
Query OK, 1 row affected (0.01 sec)

drizzle> insert into t1 values (2, '2009-07-02');
Query OK, 1 row affected (0 sec)

drizzle> SELECT YEAR(post_date) AS `year`, MONTH(post_date) AS `month`, count(id) as posts FROM t1 GROUP BY YEAR(post_date), MONTH(post_date) ORDER BY post_date DESC;
+------+-------+-------+
| year | month | posts |
+------+-------+-------+
| 2009 | 8 | 1 |
| 2009 | 7 | 1 |
+------+-------+-------+
2 rows in set (0 sec)

[Jay Pipes (jaypipes)]

Any crashing bug is critical...

[Jeff Waugh (jdub)]

Oh, hooray, I'm finally reproducing this -- turns out it only happens with a great big dataset (such as, uh, my blog). I'm going to send an export of my blog to Stewart to see what he can figure out. He can pass it on to whoever takes on this bug.

Thanks. :-)

[Jay Pipes (jaypipes)]

Stewart, Jeff, any update on this one? Stewart, did you receive Jeff's blog data and/or able to reproduce the bug?

[Jeff Waugh (jdub)]

On Tue, Jul 28, 2009 at 3:35 AM, Jay Pipes<email address hidden> wrote:
> Stewart, Jeff, any update on this one?  Stewart, did you receive Jeff's
> blog data and/or able to reproduce the bug?

Stewart hasn't had time to look at it yet -- would you like me to send
the blog dump to you? It's an interesting one because, unfixed, it
makes it terribly difficult to test or use the port. :-)

Thanks.

[Jay Pipes (jaypipes)]

That would be great, Jeff! Thanks much! <email address hidden> :)

[Jay Pipes (jaypipes)]

OK, so I have loaded Jeff's database and repeatedly run the statement in the original bug report, and have failed to be able to reproduce this bug. :(

So, what I *am* going to do is look into the temporal_format code around std::string::substr usage and ensure no out_of_bounds exceptions. That's about all I can do unless we can figure out how to reliably reproduce this bug.

[Jeff Waugh (jdub)]

I haven't been able to reproduce it from the drizzle CLI either... but it's amazingly reliably reproducible from WordPress -> drizzle-php-ext -> drizzle (2009.07.1095)... I've just built 2009.07.1103, so I'm going to test again with that.

Meanwhile, what are the differences between drizzle CLI and drizzle-php-ext when accessing the server? :-)

[Jay Pipes (jaypipes)]

Jeff Waugh wrote:
> I haven't been able to reproduce it from the drizzle CLI either... but
> it's amazingly reliably reproducible from WordPress -> drizzle-php-ext
> -> drizzle (2009.07.1095)... I've just built 2009.07.1103, so I'm going
> to test again with that.
>
> Meanwhile, what are the differences between drizzle CLI and drizzle-php-
> ext when accessing the server? :-)

Nothing, AFAIK. Eric, can you comment?

-jay

[Jay Pipes (jaypipes)]

Jeff, could you provide some details about your platform, OS, hardware. I'm going to try and find a machine in our test network that matches as much as possible. :)

[Eric Day (eday)]

There should be no difference in drizzle-php-ext and the CLI. They both use the same set of libdrizzle functions. Not sure why you would only see it with one, unless the queries form WP leaves some state from previous queries.

[Jeff Waugh (jdub)]

Jay: It's Ubuntu 9.04 (32-bit binaries running on a 64-bit capable Intel CPU), drizzled 2009.07.1103, libdrizzle 0.4 and drizzle-php-ext 0.4.1. I have switched from running Apache+mod_php to nginx+php/fastcgi, both with the same results (not that this should have much to do with drizzled crashing).

Eric: I think I'm going to have to log all the queries and then run them in the CLI... it's not even a concurrency issue, 'cos it's just me and my browser. ;-)

[Jeff Waugh (jdub)]

Further thought, not sure if it's helpful: I'm running drizzled as my user (after I installed it to ~/src/drizzle/BUILD), without any configuration files whatsoever.

[Jay Pipes (jaypipes)]

Yeah \o/

We finally have a repeatable test case for this! :)

https://bugs.launchpad.net/drizzle/+bug/500031

I am going to mark this bug as a duplicate of that one because I have a little more information on that bug regarding the stacktrace.

-jay