Re: [Bug 1729536] Re: InnoDB: Failing assertion: sym_node->table != NULL
2017-12-06 9:15 GMT+01:00 Eric Fjøsne <1729...@bugs.launchpad.net>: > What can I do next to further investigate this in order to provide > feedback over here in an efficient way ? Thinking aloud: 1. Share table structure 2. Copy table to another name, add optimize table for the copy and see if it still crashes. 3. If yes, try to isolate the crashes to specific columns by dropping them one at a time. 4. If no, try to replicate the load on the second table to see if you can cause the crashes. -- Olaf -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1729536 Title: InnoDB: Failing assertion: sym_node->table != NULL To manage notifications about this bug go to: https://bugs.launchpad.net/mysql-server/+bug/1729536/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1729536] Re: InnoDB: Failing assertion: sym_node->table != NULL
2017-12-01 10:32 GMT+01:00 Eric Fjøsne <1729...@bugs.launchpad.net>: > I reactivated one set of optimize queries for this night and it crashed > with the exact same backtrace. So I can confirm this is indeed related > to this specific set. However, there is nothing fancy about them at all. Nice! It might also be good to know if just the truncates works fine or crashes as well. > It is a simple SQL script with 9 OPTIMIZE statements being run from the mysql > client (CLI) on a single database. > OPTIMIZE TABLE Table1; > OPTIMIZE TABLE Table2; > OPTIMIZE TABLE Table3; An idea here would be to first test the first half of the queries, next day try the second half, to further isolate the culprit. Gr, -- Olaf -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1729536 Title: InnoDB: Failing assertion: sym_node->table != NULL To manage notifications about this bug go to: https://bugs.launchpad.net/mysql-server/+bug/1729536/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1729536] Re: InnoDB: Failing assertion: sym_node->table != NULL
2017-11-30 9:12 GMT+01:00 Eric Fjøsne <1729...@bugs.launchpad.net>: > @Olaf: it wasn't available anymore unfortunately. > > After deactivating the OPTIMIZE statements and changing the TRUNCATE > statement to DELETE FROM in our pre-production scripts, I can happily > confirm there was no outage on our server during this night. > > If this can help investigating this bug in any way? My guess: 1. Test with just the optimize enabled. 2. Test with just the truncate enabled. 3. If the crashes return, try to narrow it down to specific queries / tables. -- Olaf -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1729536 Title: InnoDB: Failing assertion: sym_node->table != NULL To manage notifications about this bug go to: https://bugs.launchpad.net/mysql-server/+bug/1729536/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1729536] Re: InnoDB: Failing assertion: sym_node->table != NULL
2017-11-29 10:46 GMT+01:00 Eric Fjøsne <1729...@bugs.launchpad.net>: > @ChristianEhrhardt > Thanks for your replies and initiatives. Much appreciated. > I did indeed notice the install package we could rollback to using apt-get > install mysql-server=XXX was 5.7.11, but this version is more than a year and > a half old, which doesn't sound like such a good idea. 5.7.19 might still be available in your local apt cache: /var/cache/apt/archives -- Olaf -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1729536 Title: InnoDB: Failing assertion: sym_node->table != NULL To manage notifications about this bug go to: https://bugs.launchpad.net/mysql-server/+bug/1729536/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1729536] Re: InnoDB: Failing assertion: sym_node->table != NULL
Hi, > I thought it was related specifically to replication, but according to your message, it seems it can happen for some other reason as well ? Yes, we're not using replication at all. I think the assert is a low-level one. Something before, probably unrelated to this stacktrace, goes wrong and this is only noticed later. > What I do know though is that it has to be somehow reproducible because the timeframe within which it happens is the same every day. That's interesting. What makes this timeframe different from other timeframes? Are you altering tables? Gr, Olaf -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1729536 Title: InnoDB: Failing assertion: sym_node->table != NULL To manage notifications about this bug go to: https://bugs.launchpad.net/mysql-server/+bug/1729536/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1729536] Re: InnoDB: Failing assertion: sym_node->table != NULL
2017-11-03 10:55 GMT+01:00 ChristianEhrhardt <1729...@bugs.launchpad.net>: > Hi Olaf, > there seem to be some related known issues in percona/mysql, see bug 1399471 > for more details and follow referenced further bugs from there. > > I'll explicitly subscribe Lars to take a look, but as printed in the > error message it would be great if you could file (and mention the > number here) a bug at [1] the upstream bug tracker for mysql. They might > have a backportable fix known already. Since upstream requires Oracle accounts I don't file bugs there anymore.. Note that we're running 5.7.20, I'm not sure why any backporting would be required. > You'd have to check if [2] or [3] are your case already. [2] doesn't seem applicable as our crash doesn't happen consistently at startup. Not sure about [3] > In general many of the issues seem related to e.g. migrating from > percona - does your setup have any percona history that could be > related? I didn't setup the server but I don't think so. I think it was first installed with Ubuntu 16.04.. didn't that include MySQL 5.7 already? If so, I don't think there were any upgrades. -- Olaf -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1729536 Title: InnoDB: Failing assertion: sym_node->table != NULL To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/1729536/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1729536] [NEW] InnoDB: Failing assertion: sym_node->table != NULL
Public bug reported: V: 5.7.20-0ubuntu0.16.04.1 I think it was when I added a field to a table (via phpMyAdmin). 2017-11-02 09:36:47 0x7fdc38ff9700 InnoDB: Assertion failure in thread 140583825807104 in file pars0pars.cc line 822 InnoDB: Failing assertion: sym_node->table != NULL InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 08:36:47 UTC - mysqld got signal 6 ; 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. Attempting to collect some information that could help diagnose the problem. As this is a crash and something is definitely wrong, the information collection process might fail. key_buffer_size=16777216 read_buffer_size=131072 max_used_connections=40 max_threads=151 thread_count=8 connection_count=8 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 76385 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0 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 = 0 thread_stack 0x3 /usr/sbin/mysqld(my_print_stacktrace+0x3b)[0xe8a93b] /usr/sbin/mysqld(handle_fatal_signal+0x489)[0x786749] /lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[0x7fdc5b70f390] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x38)[0x7fdc5aac8428] /lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7fdc5aaca02a] /usr/sbin/mysqld[0x75c31a] /usr/sbin/mysqld(_Z21pars_insert_statementP10sym_node_tPvP10sel_node_t+0x3a8)[0x1024088] /usr/sbin/mysqld(_Z7yyparsev+0x1227)[0x12455d7] /usr/sbin/mysqld(_Z8pars_sqlP11pars_info_tPKc+0x9e)[0x10258de] /usr/sbin/mysqld(_Z13fts_parse_sqlP11fts_table_tP11pars_info_tPKc+0x190)[0x12251e0] /usr/sbin/mysqld(_Z14fts_write_nodeP5trx_tPP10que_fork_tP11fts_table_tP12fts_string_tP10fts_node_t+0x292)[0x11ffa52] /usr/sbin/mysqld[0x12031d8] /usr/sbin/mysqld(_Z14fts_sync_tableP12dict_table_tbbb+0x329)[0x1209219] /usr/sbin/mysqld(_Z23fts_optimize_sync_tablem+0x42)[0x1210b62] /usr/sbin/mysqld(_Z19fts_optimize_threadPv+0x57c)[0x121a0bc] /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba)[0x7fdc5b7056ba] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fdc5ab9a3dd] 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. 2017-11-02T08:36:47.822416Z 0 [Warning] Changed limits: max_open_files: 1024 (requested 5000) ** Affects: mysql-5.7 (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1729536 Title: InnoDB: Failing assertion: sym_node->table != NULL To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/1729536/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 376715]
(In reply to Jim Porter (:squib) from comment #90) For Windows, as of Win7, Microsoft explicitly recommends *against* doing this: MS is silly :p I'm using Windows 7 and I'd still like to see a minimize to tray (with Escape as shortcut). I don't want to clutter my taskbar and alt-tab switcher. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/376715 Title: Thunderbird - feature request - nest in toolbar To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/376715/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 48734] Re: Home permissions too open
Ah, I assumed Opinion meant Wontfix. It'd still be nice if someone responded to the arguments. -- You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. https://bugs.launchpad.net/bugs/48734 Title: Home permissions too open -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 48734] Re: Home permissions too open
** Changed in: adduser (Ubuntu) Status: Opinion = New -- You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. https://bugs.launchpad.net/bugs/48734 Title: Home permissions too open -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 48734] Re: Home permissions too open
A response to #38 and #39 is still missing. -- You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. https://bugs.launchpad.net/bugs/48734 Title: Home permissions too open -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 48734] Re: Home permissions too open
** Changed in: adduser (Ubuntu) Status: Opinion = New -- You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. https://bugs.launchpad.net/bugs/48734 Title: Home permissions too open -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 48734] Re: Home permissions too open
Somebody? Implementing a public dir for easy sharing can IMO be easily done with defaulting to a world readable home dir. -- You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. https://bugs.launchpad.net/bugs/48734 Title: Home permissions too open -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 48734] Re: Home permissions too open
Sorry, that should read: without defaulting to a world readable home dir. -- You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. https://bugs.launchpad.net/bugs/48734 Title: Home permissions too open -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 48734] Re: Home permissions too open
** Changed in: adduser (Ubuntu) Status: Invalid = New -- You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. https://bugs.launchpad.net/bugs/48734 Title: Home permissions too open -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 48734] Re: Home permissions too open
status: New → Opinion That's silly, could someone at least respond to the arguments so we can have a proper discussion? -- You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. https://bugs.launchpad.net/bugs/48734 Title: Home permissions too open -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 48734] Re: Home permissions too open
@Colin, Mark: What about Principle of least privilege? Safe-by-default? Why does user www-data (for example) have access to my files? The defaults provide access to way more than other humans. You might at least want to use ACLs to limit it to other humans by default. It should be clear by now that some users expect a private home dir. Why not provide an easy way to switch from private to public? -- Home permissions too open https://bugs.launchpad.net/bugs/48734 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 675560] [NEW] Home dirs shouldn't be world readable
Public bug reported: Binary package hint: adduser By default, home dirs are world readable. From a privacy and security perspective, this should not be the case. ** Affects: adduser (Ubuntu) Importance: Undecided Status: New -- Home dirs shouldn't be world readable https://bugs.launchpad.net/bugs/675560 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 109559] Re: Please don't change permissions of /var/log/lighttpd during upgrade
chown www-data:www-data /var/log/lighttpd is done unconditionally in postinst. It should only be done when that dir is created for the first time, but I've no idea how to implement that. -- Please don't change permissions of /var/log/lighttpd during upgrade https://bugs.launchpad.net/bugs/109559 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 57091] Re: proc/sys/net/ipv4/tcp_syncookies=1 should be seriously considered to permit SYN flood defense...
Has this request been forwarded upstream (lkml)? -- proc/sys/net/ipv4/tcp_syncookies=1 should be seriously considered to permit SYN flood defense... https://bugs.launchpad.net/bugs/57091 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 57091] Re: proc/sys/net/ipv4/tcp_syncookies=1 should be seriously considered to permit SYN flood defense...
Are there any updates on this issue? I don't see any counter arguments to the fact syn cookies only take effect after the queue is full. Ideally this would be changed upstream, maybe an Ubuntu kernel dev could contact upstream about this? -- proc/sys/net/ipv4/tcp_syncookies=1 should be seriously considered to permit SYN flood defense... https://bugs.launchpad.net/bugs/57091 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 57091] Re: proc/sys/net/ipv4/tcp_syncookies=1 should be seriously considered to permit SYN flood defense...
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520668 ** Bug watch added: Debian Bug tracker #520668 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520668 -- proc/sys/net/ipv4/tcp_syncookies=1 should be seriously considered to permit SYN flood defense... https://bugs.launchpad.net/bugs/57091 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 57091] Re: proc/sys/net/ipv4/tcp_syncookies=1 should be seriously considered to permit SYN flood defense...
On Fri, Sep 25, 2009 at 4:56 PM, Kees Cook k...@ubuntu.com wrote: Olaf: that's why it is fix released. :) It is enabled in Ubuntu now. Ah, nice. I kinda expected a link to the package version in which it got fixed. -- proc/sys/net/ipv4/tcp_syncookies=1 should be seriously considered to permit SYN flood defense... https://bugs.launchpad.net/bugs/57091 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 57091] Re: proc/sys/net/ipv4/tcp_syncookies=1 should be seriously considered to permit SYN flood defense...
Ah, nevermind, I can't read, it's at the bottom of that message. On Fri, Sep 25, 2009 at 5:18 PM, Olaf van der Spek olafvds...@gmail.com wrote: On Fri, Sep 25, 2009 at 4:56 PM, Kees Cook k...@ubuntu.com wrote: Olaf: that's why it is fix released. :) It is enabled in Ubuntu now. Ah, nice. I kinda expected a link to the package version in which it got fixed. -- proc/sys/net/ipv4/tcp_syncookies=1 should be seriously considered to permit SYN flood defense... https://bugs.launchpad.net/bugs/57091 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 317781] Re: Ext4 data loss
@Michel Salim You can only fsync given a file descriptor, but I think writing an fsync binary that opens the file read-only, fsync on the descriptor, and close the file, should work. Wouldn't that only guarantee the updates through that descriptor (none) are synced? -- Ext4 data loss https://bugs.launchpad.net/bugs/317781 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 317781] Re: Ext4 data loss
@Theodore Ts'o 3.a) open and read file ~/.kde/foo/bar/baz 3.b) fd = open(~/.kde/foo/bar/baz.new, O_WRONLY|O_TRUNC|O_CREAT) 3.c) write(fd, buf-of-new-contents-of-file, size-of-new-contents-of-file) 3.d) fsync(fd) --- and check the error return from the fsync 3.e) close(fd) 3.f) rename(~/.kde/foo/bar/baz, ~/.kde/foo/bar/baz~) --- this is optional 3.g) rename(~/.kde/foo/bar/baz.new, ~/.kde/foo/bar/baz) (3) is the ***only*** thing which is guaranteed not to lose data. But it's not right either. It assumes you have permission to write the .new file. It assumes this file doesn't exist already (or can be overwritten). It uses an fsync, which may not be required (if atomicity but no durability is desired). It doesn't retain permissions of the old file. If the target is a symlink, it gets replaced by a normal file. If you do 3.f, there is a window where no file exists at all. It's too complex, so needs to be wrapped in library funtions. I think a concept like atomic updates (O_ATOMIC?) is needed. This would guarantee other apps and the disk (after a crash) either see the old file or the new file, but nothing else. -- Ext4 data loss https://bugs.launchpad.net/bugs/317781 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 103428] Re: if a firefox download is opened in e.g. openoffice, it is saved to /tmp, then deleted by bootclean script
They are saved in /tmp because they they are temp files ;). If you make any change to a file, you must save it using Save as... in OpenOffice. I think the file should be opened in such a state that it's unmodified (no question on close) but where Save works as Save As. -- if a firefox download is opened in e.g. openoffice, it is saved to /tmp, then deleted by bootclean script https://bugs.launchpad.net/bugs/103428 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list [EMAIL PROTECTED] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 103428] Re: if a firefox download is opened in e.g. openoffice, it is saved to /tmp, then deleted by bootclean script
See comments... not really a bug. Then why not change it to a feature request? -- if a firefox download is opened in e.g. openoffice, it is saved to /tmp, then deleted by bootclean script https://bugs.launchpad.net/bugs/103428 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list [EMAIL PROTECTED] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
