[Bug 1263808] [NEW] Segfault when backgrounding process or on system suspend/resume
Public bug reported: beanstalkd 1.9 segfaults whenever it is run in the foreground and backgrounded with CTRL-Z then returned to the foreground with fg. It also segfaults when run as a daemon and the system resumes from being suspended. The problem is with beanstalkd, not with Ubuntu. This bug was introduced here: https://github.com/kr/beanstalkd/commit/e284badf079db519db8fdd2e86959f2ee17240be I've submitted a patch for this issue, but master hasn't been updated in ~6 months, so I wouldn't count on it getting merged soon. The patch is very minimal and can be found here: https://github.com/kr/beanstalkd/pull/221. I've also attached a diff to this bug report. Beyond the example cases I mentioned above, the truth of the bug is that beanstalkd will crash anytime epoll_wait returns EINTR to beanstalkd. I don't know a lot about epoll_wait, so I can't say when else that would be an issue. I've tested that this issue exists when beanstalkd 1.9 is built on Precise and the issue exists with the package available with Trusty. The package version of beanstalkd on Precise does not segfault. I don't know if it's something particular to the Trusty build, but beanstalkd 1.9 claims to be built with debug symbols, however when I try to open the core dump with gdb, it says that no debugging symbols were found. As such, I've not included a core. If it would be helpful for me to provide a core dump and a beanstalkd bin with debug symbols, let me know. ** Affects: beanstalkd (Ubuntu) Importance: Undecided Status: New ** Tags: patch ** Patch added: Not sure what correct patch format is. This is a diff that fixes the issue. https://bugs.launchpad.net/bugs/1263808/+attachment/3934869/+files/epoll_wait_segfault_fix.diff -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to beanstalkd in Ubuntu. https://bugs.launchpad.net/bugs/1263808 Title: Segfault when backgrounding process or on system suspend/resume To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/beanstalkd/+bug/1263808/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1263808] [NEW] Segfault when backgrounding process or on system suspend/resume
Public bug reported: beanstalkd 1.9 segfaults whenever it is run in the foreground and backgrounded with CTRL-Z then returned to the foreground with fg. It also segfaults when run as a daemon and the system resumes from being suspended. The problem is with beanstalkd, not with Ubuntu. This bug was introduced here: https://github.com/kr/beanstalkd/commit/e284badf079db519db8fdd2e86959f2ee17240be I've submitted a patch for this issue, but master hasn't been updated in ~6 months, so I wouldn't count on it getting merged soon. The patch is very minimal and can be found here: https://github.com/kr/beanstalkd/pull/221. I've also attached a diff to this bug report. Beyond the example cases I mentioned above, the truth of the bug is that beanstalkd will crash anytime epoll_wait returns EINTR to beanstalkd. I don't know a lot about epoll_wait, so I can't say when else that would be an issue. I've tested that this issue exists when beanstalkd 1.9 is built on Precise and the issue exists with the package available with Trusty. The package version of beanstalkd on Precise does not segfault. I don't know if it's something particular to the Trusty build, but beanstalkd 1.9 claims to be built with debug symbols, however when I try to open the core dump with gdb, it says that no debugging symbols were found. As such, I've not included a core. If it would be helpful for me to provide a core dump and a beanstalkd bin with debug symbols, let me know. ** Affects: beanstalkd (Ubuntu) Importance: Undecided Status: New ** Tags: patch ** Patch added: Not sure what correct patch format is. This is a diff that fixes the issue. https://bugs.launchpad.net/bugs/1263808/+attachment/3934869/+files/epoll_wait_segfault_fix.diff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1263808 Title: Segfault when backgrounding process or on system suspend/resume To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/beanstalkd/+bug/1263808/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1263808] Re: Segfault when backgrounding process or on system suspend/resume
Just found a Raring VM I had lying around. Raring does not seem to be affected. Saucy however, does seem to be affected by this bug. beanstalkd segfaults when backgrounded then moved to the foreground anyway. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1263808 Title: Segfault when backgrounding process or on system suspend/resume To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/beanstalkd/+bug/1263808/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 342717] Re: fc-cache segfaults when scanning an italic BDF font with empty SETWIDTH_NAME
Related to the security issue, I don't know if the attached font is segfaulting for the same reason, but I had a session ending segfault when running fc-cache -fv. I went through the ~3000 custom fonts I have, and this is the only one I could find that segfaults. Though oddly, the segfault only killed my gnome-session the first time. I don't know if it's a fontconfig issue or a gnome issue, but with the font in a font load path other gnome issues occur as well: If gnome is locked, the unlock dialog won't appear. If no session exists and you try to login, the login seems to succeed, but the desktop never loads. Removing the font resolves these issues. Running fontconfig version 2.11.0 on Trusty. ** Attachment added: Font that causes a segfault when running fc-cache -fv https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/342717/+attachment/3934285/+files/ahronbd.ttf -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/342717 Title: fc-cache segfaults when scanning an italic BDF font with empty SETWIDTH_NAME To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/342717/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1075901] Re: Incorrect ownership or permissions for spool/work directory
Given that this bug has already been marked in progress, this may not be helpful, but I think this bug is more serious than suggested and should be made a priority to fix for precise. I've run into situations where rsyslog will run at 100% CPU with no useful output or logging to indicate why. Attaching strace to the process revealed the application was spinning with the following: futex(0x151f8e0, FUTEX_WAKE_PRIVATE, 1) = 0 open(/var/spool/rsyslog/relp_queue_hostname.0001, O_WRONLY|O_CREAT|O_NOCTTY|O_CLOEXEC, 0600) = -1 EACCES (Permission denied) In this particular case the problem arose because the remote relp server was down long enough to fill the local rsyslog in-memory queue and force rsyslog to spool to disk for relp. However, I have also run into situations where rsyslog will try to open a spool for the local logging queue and also run into permissions issues. In either case, if one of the queues turns to spooling, the write rate of the other queue is drastically affected, which is possibly why I wasn't getting any useful logging information from rsyslog once the spinning started. Up until yesterday I took the approach of restarting the rsyslog process to remedy the issue which I now understand worked because it cleared the in-memory queue and thereby postponed further throttling. This morning I forced the issue by using logger to flood rsyslog (`for i in $(seq 1 5000); do logger Testing $i; done`). Within a few thousand messages the in-memory queue must have reached its limit, as rsyslog began to consume 100% cpu and messages only showed up in syslog at a rate of 5-10 every minute. strace again verified rsyslog was spinning on the permissions error above. With rsyslog in this state I issued a `sudo chown syslog:adm /var/spool/rsyslog` command and immediately cpu usage dropped to expected levels and the remaining log messages rapidly appeared in syslog (thousands per minute). With permissions correct I tried flooding rsyslog again and this time messages went directly to syslog with no adverse impact on cpu usage. I am using precise with rsyslog 5.8.6-1ubuntu8.1. Let me know if there's any other info I can provide or anything else I can do to help. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1075901 Title: Incorrect ownership or permissions for spool/work directory To manage notifications about this bug go to: https://bugs.launchpad.net/rsyslog/+bug/1075901/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
