• Solved: KOrganizer - Calendar - MariaDB Error


    Trying to to start KOrganizer, I get a dialog box from Akonadi Server Self-Test. The first line with an issue states “MySQL server log contains errors”. The content of the log is:

    2014-07-18 11:32:19 7f907d524780 InnoDB: Warning: Using innodb\_additional\_mem\_pool\_size is DEPRECATED. This option may be removed in future releases, together with the option innodb\_use\_sys\_malloc and with the InnoDB's internal memory allocator.  
    140718 11:32:19 [Note] InnoDB: Using mutexes to ref count buffer pool pages  
    140718 11:32:19 [Note] InnoDB: The InnoDB memory heap is disabled  
    140718 11:32:19 [Note] InnoDB: Mutexes and rw\_locks use GCC atomic builtins  
    140718 11:32:19 [Note] InnoDB: Compressed tables use zlib 1.2.8  
    140718 11:32:19 [Note] InnoDB: Using Linux native AIO  
    140718 11:32:19 [Note] InnoDB: Using CPU crc32 instructions  
    140718 11:32:19 [Note] InnoDB: Initializing buffer pool, size = 80.0M  
    140718 11:32:19 [Note] InnoDB: Completed initialization of buffer pool  
    140718 11:32:19 [Note] InnoDB: Highest supported file format is Barracuda.  
    140718 11:32:19 [Note] InnoDB: Log scan progressed past the checkpoint lsn 15029368  
    140718 11:32:19 [Note] InnoDB: Database was not shutdown normally!  
    140718 11:32:19 [Note] InnoDB: Starting crash recovery.  
    140718 11:32:19 [Note] InnoDB: Reading tablespace information from the .ibd files...  
    140718 11:32:19 [Note] InnoDB: Restoring possible half-written data pages   
    140718 11:32:19 [Note] InnoDB: from the doublewrite buffer...  
    InnoDB: Doing recovery: scanned up to log sequence number 15029592  
    140718 11:32:19 [Note] InnoDB: Starting an apply batch of log records to the database...  
    InnoDB: Progress in percent: 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99   
    InnoDB: Apply batch completed  
    140718 11:32:20 [ERROR] 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.  
      
    To report this bug, see http://kb.askmonty.org/en/reporting-bugs  
      
    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.  
      
    Server version: 10.0.12-MariaDB  
    key\_buffer\_size=16384  
    read\_buffer\_size=131072  
    max\_used\_connections=0  
    max\_threads=258  
    thread\_count=0  
    It is possible that mysqld could use up to   
    key\_buffer\_size + (read\_buffer\_size + sort\_buffer\_size)\*max\_threads = 566740 K bytes of memory  
    Hope that's ok; if not, decrease some variables in the equation.  
      
    Thread pointer: 0x0x0  
    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...  
    stack\_bottom = 0x0 thread\_stack 0x48000  
    /usr/bin/mysqld(my\_print\_stacktrace+0x3d)[0xb9cc5d]  
    /usr/bin/mysqld(handle\_fatal\_signal+0x345)[0x70cc25]  
    /usr/lib/libpthread.so.0(+0xf4b0)[0x7f907c8784b0]  
    /usr/bin/mysqld[0x9d3a59]  
    /usr/bin/mysqld[0x9d5c63]  
    /usr/bin/mysqld[0x9354d5]  
    /usr/bin/mysqld[0x86edab]  
    /usr/bin/mysqld(\_Z24ha\_initialize\_handlertonP13st\_plugin\_int+0x64)[0x70edd4]  
    /usr/bin/mysqld[0x5c3bf3]  
    /usr/bin/mysqld(\_Z11plugin\_initPiPPci+0x558)[0x5c4a08]  
    /usr/bin/mysqld[0x529ba0]  
    /usr/bin/mysqld(\_Z11mysqld\_mainiPPc+0x5ad)[0x52dcad]  
    /usr/lib/libc.so.6(\_\_libc\_start\_main+0xf0)[0x7f907b645000]  
    /usr/bin/mysqld[0x5225b1]  
    The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains  
    information that should help you find out what is causing the crash.  
    
    

    I tried to see if this is a known bug on the site identified to report the bug, but the sites “Version” page did not have an entry for 10.0.12. I also tried looking at the manual page on the bottom of the error message, but couldn’t figure it what to do.

    Suggestions?

  • Trying to to start KOrganizer, I get a dialog box from Akonadi Server Self-Test. The first line with an issue states “MySQL server log contains errors”. The content of the log is:

    2014-07-18 11:32:19 7f907d524780 InnoDB: Warning: Using innodb\_additional\_mem\_pool\_size is DEPRECATED. This option may be removed in future releases, together with the option innodb\_use\_sys\_malloc and with the InnoDB's internal memory allocator.  
    140718 11:32:19 [Note] InnoDB: Using mutexes to ref count buffer pool pages  
    140718 11:32:19 [Note] InnoDB: The InnoDB memory heap is disabled  
    140718 11:32:19 [Note] InnoDB: Mutexes and rw\_locks use GCC atomic builtins  
    140718 11:32:19 [Note] InnoDB: Compressed tables use zlib 1.2.8  
    140718 11:32:19 [Note] InnoDB: Using Linux native AIO  
    140718 11:32:19 [Note] InnoDB: Using CPU crc32 instructions  
    140718 11:32:19 [Note] InnoDB: Initializing buffer pool, size = 80.0M  
    140718 11:32:19 [Note] InnoDB: Completed initialization of buffer pool  
    140718 11:32:19 [Note] InnoDB: Highest supported file format is Barracuda.  
    140718 11:32:19 [Note] InnoDB: Log scan progressed past the checkpoint lsn 15029368  
    140718 11:32:19 [Note] InnoDB: Database was not shutdown normally!  
    140718 11:32:19 [Note] InnoDB: Starting crash recovery.  
    140718 11:32:19 [Note] InnoDB: Reading tablespace information from the .ibd files...  
    140718 11:32:19 [Note] InnoDB: Restoring possible half-written data pages   
    140718 11:32:19 [Note] InnoDB: from the doublewrite buffer...  
    InnoDB: Doing recovery: scanned up to log sequence number 15029592  
    140718 11:32:19 [Note] InnoDB: Starting an apply batch of log records to the database...  
    InnoDB: Progress in percent: 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99   
    InnoDB: Apply batch completed  
    140718 11:32:20 [ERROR] 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.  
      
    To report this bug, see http://kb.askmonty.org/en/reporting-bugs  
      
    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.  
      
    Server version: 10.0.12-MariaDB  
    key\_buffer\_size=16384  
    read\_buffer\_size=131072  
    max\_used\_connections=0  
    max\_threads=258  
    thread\_count=0  
    It is possible that mysqld could use up to   
    key\_buffer\_size + (read\_buffer\_size + sort\_buffer\_size)\*max\_threads = 566740 K bytes of memory  
    Hope that's ok; if not, decrease some variables in the equation.  
      
    Thread pointer: 0x0x0  
    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...  
    stack\_bottom = 0x0 thread\_stack 0x48000  
    /usr/bin/mysqld(my\_print\_stacktrace+0x3d)[0xb9cc5d]  
    /usr/bin/mysqld(handle\_fatal\_signal+0x345)[0x70cc25]  
    /usr/lib/libpthread.so.0(+0xf4b0)[0x7f907c8784b0]  
    /usr/bin/mysqld[0x9d3a59]  
    /usr/bin/mysqld[0x9d5c63]  
    /usr/bin/mysqld[0x9354d5]  
    /usr/bin/mysqld[0x86edab]  
    /usr/bin/mysqld(\_Z24ha\_initialize\_handlertonP13st\_plugin\_int+0x64)[0x70edd4]  
    /usr/bin/mysqld[0x5c3bf3]  
    /usr/bin/mysqld(\_Z11plugin\_initPiPPci+0x558)[0x5c4a08]  
    /usr/bin/mysqld[0x529ba0]  
    /usr/bin/mysqld(\_Z11mysqld\_mainiPPc+0x5ad)[0x52dcad]  
    /usr/lib/libc.so.6(\_\_libc\_start\_main+0xf0)[0x7f907b645000]  
    /usr/bin/mysqld[0x5225b1]  
    The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains  
    information that should help you find out what is causing the crash.  
    
    

    I tried to see if this is a known bug on the site identified to report the bug, but the sites “Version” page did not have an entry for 10.0.12. I also tried looking at the manual page on the bottom of the error message, but couldn’t figure it what to do.

    Suggestions?

  • Did you make any changes to the default config file? I believe its /etc/my.cnf or /etc/mysql/my.cnf

  • @“lots.0.logs”:ca9knngu said:

    Did you make any changes to the default config file? I believe its /etc/my.cnf or /etc/mysql/my.cnf[/quote:ca9knngu]

    I didn’t. No idea if any recent updates would have.

  • Its possible that its a bug that hasn’t been reported or was just recently reported. You may want to install an earlier (more stable) version from the AUR instead.

  • @“lots.0.logs”:34groneg said:

    Its possible that its a bug that hasn’t been reported or was just recently reported. You may want to install an earlier (more stable) version from the AUR instead.[/quote:34groneg]

    I found this related to MariaDB 10.0.10 (I’m on 10.0.12) and was closed in May 2014. Seems that you need MariaDB complied with with GCC 4.8 not 4.9 to fix the problem. I can’t figure out what I need a previous version of.

    [url:34groneg]https://mariadb.atlassian.net/browse/MDEV-6202[/url:34groneg]

  • Finally found a way to fix my issue. Seems to be several variants of the issue and different ways to solve it.

    [url:nmk0n9i3]https://bbs.archlinux.org/viewtopic.php?id=184192[/url:nmk0n9i3]

    For myself, the only step I needed to do was delete this file:

    ~/.local/share/akonadi/mysql.conf

    Then run korganizer again and it started right up again.

Posts 7Views 1014
Log in to reply