Bug 1065676
Summary: | [abrt] mariadb-server: _ma_read_block_record(): mysqld killed by SIGSEGV | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | rng <rgasch> | ||||||||||||||||||||||||||
Component: | mariadb | Assignee: | Honza Horak <hhorak> | ||||||||||||||||||||||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||||||||||||||
Severity: | unspecified | Docs Contact: | |||||||||||||||||||||||||||
Priority: | unspecified | ||||||||||||||||||||||||||||
Version: | 20 | CC: | hhorak, jdornak, rgasch | ||||||||||||||||||||||||||
Target Milestone: | --- | ||||||||||||||||||||||||||||
Target Release: | --- | ||||||||||||||||||||||||||||
Hardware: | x86_64 | ||||||||||||||||||||||||||||
OS: | Unspecified | ||||||||||||||||||||||||||||
URL: | https://retrace.fedoraproject.org/faf/reports/bthash/cb6192d3c367d247a26a3279a65c444eb7fcc6b2 | ||||||||||||||||||||||||||||
Whiteboard: | abrt_hash:ee8b8b16384f17fa76d0998ffdb9223cdd04365c | ||||||||||||||||||||||||||||
Fixed In Version: | mariadb-5.5.37-1.fc19 | Doc Type: | Bug Fix | ||||||||||||||||||||||||||
Doc Text: | Story Points: | --- | |||||||||||||||||||||||||||
Clone Of: | Environment: | ||||||||||||||||||||||||||||
Last Closed: | 2014-05-19 10:06:30 UTC | Type: | --- | ||||||||||||||||||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||||||||||||||||||
Documentation: | --- | CRM: | |||||||||||||||||||||||||||
Verified Versions: | Category: | --- | |||||||||||||||||||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||||||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||||||||||||||||
Embargoed: | |||||||||||||||||||||||||||||
Attachments: |
|
Description
rng
2014-02-15 18:03:03 UTC
Created attachment 863592 [details]
File: backtrace
Created attachment 863593 [details]
File: cgroup
Created attachment 863594 [details]
File: core_backtrace
Created attachment 863595 [details]
File: dso_list
Created attachment 863596 [details]
File: environ
Created attachment 863597 [details]
File: exploitable
Created attachment 863598 [details]
File: limits
Created attachment 863599 [details]
File: maps
Created attachment 863600 [details]
File: open_fds
Created attachment 863601 [details]
File: proc_pid_status
Created attachment 863602 [details]
File: var_log_messages
(In reply to rng from comment #0) > Description of problem: > The following SQL statement generates a "SQLSTATE[HY000]: General error: > 2006 MySQL server has gone away" error: > > SELECT COUNT(*) ... > I can provide you with the schema and data which resulted in this crash. If you can, that would be great. Do I understand correctly, that you're able to reproduce repeatedly? > Version-Release number of selected component: > mariadb-server-5.5.34-3.fc20 What about new version, mariadb-5.5.35-3.fc20 -- does it also suffer from this issue? Let me test mariadb-5.5.35-3.fc20 tonight (this is a bit complicated because I've switched to MySql in order to be able to work, so I need to switch back again). I'll get back to you within 24 hours. Sorry, I didn't have time to check this today ... I will do so tomorrow. Created attachment 865305 [details]
The SQL schema and data needed to run the sql statement causing the crash
Simply load this file into your database and run the SQL statement given in the bug report against it. You will get the "server has gone away" error.
MariaDB 5.5.35-3.fc20 still has the same problem. Please see my previous message (comment 15) for a reproducible case. Thanks, it's easily reproducible on my machine as well with SQL command from comment #15 and a command from comment #0; also crashes with a bit simplified following SQL command: SELECT Count(*) FROM bpsocial_post AS tbl LEFT JOIN bpsocial_profile_object_option a ON a.spoo_uid = sspo_uid AND a.spoo_option_id = 1 LEFT JOIN bpsocial_profile_object_option b ON b.spoo_uid = sspo_uid AND b.spoo_option_id = 2 LEFT JOIN bpsocial_profile_object_option c ON c.spoo_uid = sspo_uid AND c.spoo_option_id = 3 LEFT JOIN bpsocial_profile_object_option d ON d.spoo_uid = sspo_uid AND d.spoo_option_id = 5 LEFT JOIN bpsocial_profile_object_option e ON e.spoo_uid = sspo_uid AND e.spoo_option_id = 4 LEFT JOIN bpsocial_profile_object_option f ON f.spoo_uid = sspo_uid AND f.spoo_option_id = 11 LEFT JOIN bpsocial_profile_object_option g ON g.spoo_uid = sspo_uid AND g.spoo_option_id = 7 LEFT JOIN bpsocial_profile_object_option h ON h.spoo_uid = sspo_uid AND h.spoo_option_id = 10 LEFT JOIN bpsocial_profile_object_option i ON i.spoo_uid = sspo_uid AND i.spoo_option_id = 18 LEFT JOIN bpsocial_profile_object_option j ON j.spoo_uid = sspo_uid AND j.spoo_option_id = 6 GROUP BY a.spoo_value, b.spoo_value, c.spoo_value, d.spoo_value, e.spoo_value, f.spoo_value, g.spoo_value, h.spoo_value, i.spoo_value, j.spoo_value; Surprisingly, it doesn't crash with community mysql-5.5.35, so it is probably a MariaDB-only bug. Reported upstream as: https://mariadb.atlassian.net/browse/MDEV-5724 Relevant comment from the upstream bug report (Michael Widenius commented on MDEV-5724): ---------------------------------------- The problem is that the temporary table we have to create to store the interim result has a row length of 300K. We try to allocate on row on the stack (which works) but next call causes a segmentation fault. I will fix this by not allocating bigger rows than 16K on the stack for rows. To avoid this bug, do one of the following: - Increase size of the thread-stack startup options (288K by default). 300K was needed for the above case. - Change some of the big VARCHAR to BLOB as BLOB only takes 16 bytes in the record buffer As mariadb-5.5.37-1.fc19 is already in the stable repo, this bug should also be already fixed, as upstream states this is fixed in 5.5.37. Please, re-open if you are still able to reproduce this. |