| Bug #22879 | Server Crashed down, i don't find why | ||
|---|---|---|---|
| Submitted: | 2 Oct 2006 7:57 | Modified: | 23 Dec 2006 17:24 |
| Reporter: | Thomas Goik | Email Updates: | |
| Status: | No Feedback | Impact on me: | |
| Category: | MySQL Server | Severity: | S2 (Serious) |
| Version: | Ver 4.1.11-Debian_4sarge7-log | OS: | Linux (Linux 2.4.22 #3 SMP ) |
| Assigned to: | CPU Architecture: | Any | |
[2 Oct 2006 7:57]
Thomas Goik
[2 Oct 2006 8:06]
Valeriy Kravchuk
Thank you for a problem report. Please, send your my.cnf content and, if possible, probplematic query that crashed your server. How much RAM do you have?
[2 Oct 2006 8:40]
Thomas Goik
>Thank you for a problem report. Please, send your my.cnf content and, if >possible, probplematic query that crashed your server. How much RAM do >you have? I did'n find the query who crashed the server down, the RAM question is: 3 GB I send the my.cnf file at the file register here!
[2 Oct 2006 8:46]
Valeriy Kravchuk
I still do not see any my.cnf uploaded/sent. I am almost sure that we have out of memory issue bacause of improper configuration, but let me double check...
[2 Oct 2006 8:58]
Thomas Goik
u see it now? Thanks?
[2 Oct 2006 9:12]
MySQL Verification Team
hi thomas, did you "set global key_buffer_size=.." while server was running? Do you have any alter table statements running at same time?
[2 Oct 2006 9:29]
Thomas Goik
hi Shane; i didn't set anything meanwhile the server was running. Yes the system does alter tables on temp search tables, but this since a long time ago and never problems. what says Valeriy: out of memory could be, this day i had more client requests Ciao
[2 Oct 2006 12:30]
Heikki Tuuri
Hi! The InnoDB stack trace above is nonsensical. Are you sure that you used the right mysqld.sym to resolve the stack trace? Regards, Heikki
[15 Oct 2006 18:32]
Thomas Goik
Hi, today i got another crash down by the server Here is the error code with the stack trace: ey_buffer_size=824180736 read_buffer_size=4190208 max_used_connections=101 max_connections=100 threads_connected=21 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 1623663 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x8625ea38 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=0xbd1ff368, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x818935f 0x4005b825 0x8184e5f 0x8184993 0x81bacda 0x819be7f 0x819bce6 0x819b448 0x40055e51 0x402a08aa New value of fp=(nil) failed sanity check, terminating stack trace! ... Some pointers may be invalid and cause the dump to abort... thd->query at 0x7f900018 is invalid pointer thd->thread_id=1562976 s-esl4:/tmp# resolve_stack_dump -s /tmp/mysqld.sym -n mysqld.stack 0x818935f _ZNK11Gis_polygon13exterior_ringEP6String + 175 0x4005b825 _end + 934815841 0x8184e5f mysql_free_result + 159 0x8184993 mysql_fetch_row + 179 0x81bacda ibuf_build_entry_from_ibuf_rec + 490 0x819be7f dict_create_index_tree_step + 31 0x819bce6 dict_create_sys_fields_tuple + 230 0x819b448 dict_create_sys_columns_tuple + 680 0x40055e51 _end + 934792845 0x402a08aa _end + 937195750 This is realy wired because the server is runnig for a long time with no errors
[23 Nov 2006 17:24]
Valeriy Kravchuk
This is either out of memory issue, or, based on initial stack trace, a duplicate of bug #17332. Please, check with the patch (or new version with a patch) for bug #17332 (not fixed yet!), and inform about the results.
[24 Dec 2006 0:00]
Bugs System
No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open".
