[Bug 298480]
This completely breaks tmux (or screen). The currently active window gets the EOF is therefore closed whenever I close Konsole. When I re-attach to the tmux session the window is of course gone. This is unacceptable. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/298480 Title: Konsole should not terminate background processes upon closing konsole window To manage notifications about this bug go to: https://bugs.launchpad.net/kde-baseapps/+bug/298480/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1488254]
(In reply to comment #33) > (In reply to comment #32) > > (In reply to comment #31) > > > (In reply to comment #28) > > > > The incompatibility was introduced by gcc's "automatic tagging of > > > > functions > > > > and variables with tagged types where the tags are not already > > > > reflected in > > > > the mangled name". > > > > > > > > Now every library function with e.g a std::string return type causes > > > > linker > > > > errors. > > > > > > > > To solve this issue, Clang only would have to implement the return type > > > > ABI > > > > tagging. All other ABI tags are irrelevant AFAIK. > > > > > > The change was necessary to support dual-abi in one binary; you need to > > > be able to distinguish different ABIs in the return type. > > > > No, the "automatic tagging of function return types" was unnecessary. The > > new > > ABI was working perfectly fine with both compilers before that change. > > As long as you keep the ABIs completely separated it works, yes. > > To get basic dual ABI support you could require manual tagging of all > functions > which need tags (like, say, `std::string std::to_string(int)`) - but such > procedure would be way too much work and error prone. > > Especially if you have third party libraries providing such functions (like > boost), > which certainly would not start manual tagging, the linker could let you use > functions you really must not use. I really think that implementing the full gcc abi-tag support is not feasible for Clang. So I would recommend to focus on compatibility with the single (new) ABI alone. Distros that use the new ABI have recompiled all their C++ libraries, so there isn't much need for the dual ABI anyway. (After all the ABI tags are just a tool to help with the transition.) > I really see no option in this; if the return type is tagged, the tag must be > present in the signature somehow, or you can never mix different ABIs in the > same binary. > > (I would have preferred to simply make tagged return (and variable!) types > part > of the name, which would have been straightforward compared to the mess GCC > implemented: if the tag is already present in certain places, it is not > added, > depending on the context it might not be added at all, ...) But this is all that's needed. Just change the mangling of the affected return (and variable) types and you're set. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1488254 Title: clang++ no longer ABI-compatible with g++ To manage notifications about this bug go to: https://bugs.launchpad.net/llvm/+bug/1488254/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1488254]
(In reply to comment #31) > (In reply to comment #26) > > (In reply to comment #25) > > > 3. The problem only started because distros have chosen GCC 5 as their > > > default compilers for the current releases, which defaults to C++11. > > > > No gcc-5 doesn't default to C++11 and the issue here has nothing to do with > > C++98 vs. C++11. > > > > Please try to get the facts strait, before posting long misleading replies. > > It is related to C++11; afaik one of the reasons to break the ABI was to > become C++11 standard compliant; also the new classes are tagged > "cxx11". The new ABI is used for C++98 as well... > (In reply to comment #28) > > The incompatibility was introduced by gcc's "automatic tagging of functions > > and variables with tagged types where the tags are not already reflected in > > the mangled name". > > > > Now every library function with e.g a std::string return type causes linker > > errors. > > > > To solve this issue, Clang only would have to implement the return type ABI > > tagging. All other ABI tags are irrelevant AFAIK. > > "Only" sounds like it would be easy and obvious. Sadly, this is not a > trivial problem. > > The change was necessary to support dual-abi in one binary; you need to > be able to distinguish different ABIs in the return type. No, the "automatic tagging of function return types" was unnecessary. The new ABI was working perfectly fine with both compilers before that change. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1488254 Title: clang++ no longer ABI-compatible with g++ To manage notifications about this bug go to: https://bugs.launchpad.net/llvm/+bug/1488254/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1488254]
(In reply to comment #27) > (In reply to comment #26) > > No. It was implemented in April this year, shortly before the gcc-5 release. > > I've pointed out compatibility issue immediately: > > https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00153.html > (...) > > The were no behavioral changes at all after that patch went in. > > In the Linaro thread, Jim points out to the abi_tag patch from 2012. Your > mention is about "significant changes to attribute abi_tag". I can't see how > I was wrong. > > > > No gcc-5 doesn't default to C++11 and the issue here has nothing to do with > > C++98 vs. C++11. > > > > Please try to get the facts strait, before posting long misleading replies. > > This is what most of the documentation, email threads and conversations I > had seem to point at. If you have a different opinion, than by all means, > please share your knowledge. > > Saying "it has nothing to do with" doesn't explain what it has to do with. > I'm happy to be proven wrong here, as long as we get all the facts on the > table. This bug doesn't seem to provide strong facts either. The incompatibility was introduced by gcc's "automatic tagging of functions and variables with tagged types where the tags are not already reflected in the mangled name". Before that patch (https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01029.html) both gcc and clang could use the new ABI without any problem. Now every library function with e.g a std::string return type causes linker errors. To solve this issue, Clang only would have to implement the return type ABI tagging. All other ABI tags are irrelevant AFAIK. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1488254 Title: clang++ no longer ABI-compatible with g++ To manage notifications about this bug go to: https://bugs.launchpad.net/llvm/+bug/1488254/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1488254]
(In reply to comment #25) > Following up on the Linaro Toolchain list[1], I found out a few facts: > > 1. This feature was implemented in GCC and libstdc++ in 2012, after > discussions on the cauldron with distro representatives. No. It was implemented in April this year, shortly before the gcc-5 release. I've pointed out compatibility issue immediately: https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00153.html > 2. The feature is poorly documented, and may have changed behaviour until > recently. I have no evidence of changes, is anyone does, please update. The were no behavioral changes at all after that patch went in. > 3. The problem only started because distros have chosen GCC 5 as their > default compilers for the current releases, which defaults to C++11. No gcc-5 doesn't default to C++11 and the issue here has nothing to do with C++98 vs. C++11. Please try to get the facts strait, before posting long misleading replies. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1488254 Title: clang++ no longer ABI-compatible with g++ To manage notifications about this bug go to: https://bugs.launchpad.net/llvm/+bug/1488254/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 480671]
There are debugging dump statements left in this patch, that print the username on every auto-login attempt to the console. This might be a security issue, because it is now easy to tell when and under what username a user tried to login to varies websites. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/480671 Title: Firefox auto-completes login fields in a case-insensitive manner To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/480671/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 653414] Re: BUG: Bad page state in process firefox-bin pfn:3ed00
This is fixed by:
commit a56d5318716d120e040294bb258901ba89fb9c90
Author: Jiri Slaby jsl...@suse.cz
Date: Tue Oct 26 14:22:11 2010 -0700
hpet: unmap unused I/O space
When the initialization code in hpet finds a memory resource and does not
find an IRQ, it does not unmap the memory resource previously mapped.
There are buggy BIOSes which report resources exactly like this and what
is worse the memory region bases point to normal RAM. This normally would
not matter since the space is not touched. But when PAT is turned on,
ioremap causes the page to be uncached and sets this bit in page-flags.
Then when the page is about to be used by the allocator, it is reported
as:
BUG: Bad page state in process md5sum pfn:3ed00
page:eadbd800 count:0 mapcount:0 mapping:(null) index:0x0
page flags: 0x200100(uncached)
Pid: 7956, comm: md5sum Not tainted 2.6.34-12-desktop #1
Call Trace:
[810df851] bad_page+0xb1/0x100
[810dfa45] prep_new_page+0x1a5/0x1c0
[810dfe01] get_page_from_freelist+0x3a1/0x640
[810e01af] __alloc_pages_nodemask+0x10f/0x6b0
...
In this particular case:
1) HPET returns 3ed0 as memory region base, but it is not in
reserved ranges reported by the BIOS (excerpt):
BIOS-e820: 0010 - af6cf000 (usable)
BIOS-e820: af6cf000 - afdcf000 (reserved)
2) there is no IRQ resource reported by HPET method. On the other
hand, the Intel HPET specs (1.0a) says (3.2.5.1):
_CRS (
// Report 1K of memory consumed by this Timer Block
memory range consumed
// Optional: only used if BIOS allocates Interrupts [1]
IRQs consumed
)
[1] For case where Timer Block is configured to consume IRQ0/IRQ8 AND
Legacy 8254/Legacy RTC hardware still exists, the device objects
associated with 8254 RTC devices should not report IRQ0/IRQ8 as
consumed resources.
So in theory we should check whether if it is the case and use those
interrupts instead.
Anyway the address reported by the BIOS here is bogus, so non-presence
of IRQ doesn't mean the optional part in point 2).
Since I got no reply previously, fix this by simply unmapping the space
when IRQ is not found and memory region was mapped previously. It would
be probably more safe to walk the resources again and unmap appropriately
depending on type. But as we now use only ioremap for both 2 memory
resource types, it is not necessarily needed right now.
Addresses https://bugzilla.novell.com/show_bug.cgi?id=629908
Reported-by: Olaf Hering o...@aepfle.de
Signed-off-by: Jiri Slaby jsl...@suse.cz
Acked-by: Clemens Ladisch clem...@ladisch.de
Cc: sta...@kernel.org
Signed-off-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Linus Torvalds torva...@linux-foundation.org
diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
index a4eee32..84e6a7e 100644
--- a/drivers/char/hpet.c
+++ b/drivers/char/hpet.c
@@ -1000,6 +1000,8 @@ static int hpet_acpi_add(struct acpi_device *device)
return -ENODEV;
if (!data.hd_address || !data.hd_nirqs) {
+ if (data.hd_address)
+ iounmap(data.hd_address);
printk(%s: no address or irqs in _CRS\n, __func__);
return -ENODEV;
}
** Bug watch added: Novell/SUSE Bugzilla #629908
https://bugzilla.novell.com/show_bug.cgi?id=629908
--
BUG: Bad page state in process firefox-bin pfn:3ed00
https://bugs.launchpad.net/bugs/653414
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 197589] Re: Numeric keypad no longer works after upgrade
My parents PC was hit by this bug today. I got a phone call from my father and he tells me that the numblock keys don't work anymore. So I connect to his PC with vinagre and find out he's right. I tell him to reboot the machine, but the problem is still there after reboot. Then I ran xev on his machine and saw that the keyboard was generating events as expected. My father plugged in another keyboard and everything worked fine. I searched the net and found this bug. I've never heard of the SHIFT-NUMLOCK key combination before... I think this behavior (killing numblock keys even after reboot) needs immediate fixing. -- Numeric keypad no longer works after upgrade https://bugs.launchpad.net/bugs/197589 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
