The only time this occurs for me, is when I try to close a java
application (https://www.interactivebrokers.com/en/index.php?f=16045).
With this particular java application, it appears to happen more often,
if I use the window close button instead of the menu close item when
closing windows (but al
*** This bug is a duplicate of bug 1664979 ***
https://bugs.launchpad.net/bugs/1664979
** This bug has been marked a duplicate of bug 1664979
EQ overflowing. Additional events will be discarded until existing events
are processed.
--
You received this bug notification because you are a m
*** This bug is a duplicate of bug 1664979 ***
https://bugs.launchpad.net/bugs/1664979
** This bug has been marked a duplicate of bug 1664979
EQ overflowing. Additional events will be discarded until existing events
are processed.
--
You received this bug notification because you are a m
Ok, thanks for explaining this!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1649657
Title:
OpenSSL version is not dependable
To manage notifications about this bug go to:
https://bugs.launchpad.n
With OpenSSL 1.0.1, as long as you update to the most recent 1.0.1
release, there would be no ABI changes, right? Otherwise, your argument
is just that other people do separate patches, so Ubuntu will continue
to do that too, right?
--
You received this bug notification because you are a member
This problem needs to be handled as a bug due to its effect on OpenSSL
use. Handling single patches with the Ubuntu OpenSSL package creates
this problem, due to the lack of a version update. Instead, Ubuntu
should be using mainline OpenSSL to avoid problems like
https://en.wikipedia.org/wiki/Open
Public bug reported:
Greetings!
Is there any reason why Ubuntu 14.04 LTS openssl version is still
1.0.1f?
>From https://www.openssl.org/news/openssl-1.0.1-notes.html there have
been a lot of patches since that version. In fact this critical patch
https://www.openssl.org/news/vulnerabilities.html
Sorry for the previous comment. After testing with jemalloc and
valgrind, I found the problem was caused by a double free within a class
destructor, that was being used within an std::unordered_set, so the
copy constructor was causing deletions and accesses to the deleted
memory. It helped to hav
I believe I am seeing this bug in-action on Ubuntu 12.04.3 AMD64. I
have some gdb backtrace info pasted below. I am surprised glibc malloc
has been broken for more than 1 year. I will definitely avoid it in the
future, but it also shows the potential for future instability at the
OS-level:
##t