November 2008 - triage - Fedora Mailing-Lists

[Bug 268961] elfutils 129 ignores a local symbol within a global

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=268961 --- Comment #15 from Fedora Update System <updates(a)fedoraproject.org> 2008-11-12 22:36:18 EDT --- elfutils-0.137-3.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

15 years, 6 months

1
0
0 / 0

[Bug 268961] elfutils 129 ignores a local symbol within a global

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=268961 --- Comment #14 from Fedora Update System <updates(a)fedoraproject.org> 2008-11-12 22:35:52 EDT --- elfutils-0.137-3.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

15 years, 6 months

1
0
0 / 0

[Bug 179072] _dl_debug_state() RT_CONSISTENT called too early

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=179072 --- Comment #16 from Jan Kratochvil <jan.kratochvil(a)redhat.com> 2008-11-12 18:16:36 EDT --- I also could not find any documentation for _dl_debug_state()/RT_CONSISTENT, My text tries to advice (B) as the best choice out of the existing possibilities and thanks to finding out the Solaris code supports that. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

15 years, 6 months

1
0
0 / 0

[Bug 179072] _dl_debug_state() RT_CONSISTENT called too early

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=179072 --- Comment #15 from Paul Pluzhnikov <ppluzhnikov(a)google.com> 2008-11-12 18:05:03 EDT --- (In reply to comment #12) > _dl_debug_state() call be probably called at three places: > (A) r_map is already correct (guaranteed by RT_CONSISTENT); current version. > (B) Like (A) but also after the relocations are resolved. > (C) Like (B) but also after the initializers are executed. > > I believe the call+RT_CONSISTENT was intended for (A) and neither (B) nor (C). What makes you believe that? I can't find official documentation for RT_CONSISTENT, but Solaris (from which this interface is copied) AFAICT calls _dl_debug_state() (or rather its Solaris equivalent) at (B): http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/sgs/rtl... -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

15 years, 6 months

1
0
0 / 0

[Bug 179072] _dl_debug_state() RT_CONSISTENT called too early

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=179072 --- Comment #14 from Jan Kratochvil <jan.kratochvil(a)redhat.com> 2008-11-12 17:43:18 EDT --- Created an attachment (id=323396) --> (https://bugzilla.redhat.com/attachment.cgi?id=323396) Illustrative fix for GDB CVS HEAD not requiring fixed glibc (proof of concept). -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

15 years, 6 months

1
0
0 / 0

[Bug 179072] _dl_debug_state() RT_CONSISTENT called too early

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=179072 Jan Kratochvil <jan.kratochvil(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed In Version|2.4-7 | -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

15 years, 6 months

1
0
0 / 0

[Bug 179072] _dl_debug_state() RT_CONSISTENT called too early

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=179072 --- Comment #13 from Jan Kratochvil <jan.kratochvil(a)redhat.com> 2008-11-12 17:40:14 EDT --- Created an attachment (id=323395) --> (https://bugzilla.redhat.com/attachment.cgi?id=323395) Two testcases (not suitable for the glibc testsuite). Testcase for the problem with libpthread loaded first only on dlopen(). Prerequisite is to run: prelink -uf /lib64/libpthread.so.0 GDB was tested gdb-6.8-1.fc9 up to GDB CVS HEAD snapshot. $ gdb ./testload ... (gdb) r Starting program: /tmp/rh179072/testload [Thread debugging using libthread_db enabled] Error while reading shared library symbols: Cannot find new threads: generic error Cannot find new threads: generic error (gdb) _ Testcase that the patched library and/or patched GDB fixes the threads problem: $ gdb ./testload ... (gdb) r Starting program: /tmp/rh179072/testload [Thread debugging using libthread_db enabled] [New Thread 0x7ffff7fde6f0 (LWP 7018)] [New Thread 0x7ffff7bc0950 (LWP 7021)] [Thread 0x7ffff7bc0950 (LWP 7021) exited] Program exited normally. ------------------------------------------------------------------------------ Testcase that at the (B) time (with the patch) we still cannot call safely functions as they may expect static class variables to be initialized: # class C { # int i; # C () { i = 1; } # void f () { assert (i == 1); } # }; $ gdb -x ./cxx.gdbinit ... (gdb) p c $1 = {i = 0} (gdb) p c.f $2 = {void (C *)} 0x7ffff7ddd73a <C::f()> (gdb) p c.f() cxxmain: cxxlib.C:8: void C::f(): Assertion `i == 1' failed. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

15 years, 6 months

1
0
0 / 0

[Bug 179072] _dl_debug_state() RT_CONSISTENT called too early

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=179072 --- Comment #12 from Jan Kratochvil <jan.kratochvil(a)redhat.com> 2008-11-12 17:38:41 EDT --- Created an attachment (id=323394) --> (https://bugzilla.redhat.com/attachment.cgi?id=323394) Minimized to only move _dl_debug_state() after relocations, for glibc-2.8.90-16. (In reply to comment #0) > The time to call _dl_debug_state() is just before running the initializer > functions of the newly-loaded objects. _dl_debug_state() call be probably called at three places: (A) r_map is already correct (guaranteed by RT_CONSISTENT); current version. (B) Like (A) but also after the relocations are resolved. (C) Like (B) but also after the initializers are executed. I believe the call+RT_CONSISTENT was intended for (A) and neither (B) nor (C). (C) is probably too late because we would not be able to debug initializers. But still nobody guarantees we should stop at (B) instead of at current (A). ------------------------------------------------------------------------------ GDB currently assumes that at _dl_debug_state() time if the `nptl_version', `_thread_db_*' and other symbols are present libthread_db can be used. This is currently not true as it fails at least while reading libpthread unrelocated symbol `stack_used': glibc-20081031T2102/nptl/allocatestack.c: static LIST_HEAD (stack_used); File: /lib64/libpthread.so.0 Symbol table '.symtab' contains 907 entries: Num: Value Size Type Bind Vis Ndx Name 61: 0000000000217220 16 OBJECT LOCAL DEFAULT 28 stack_used Relocation section '.rela.dyn' at offset 0x41a8 contains 68 entries: Offset Info Type Sym. Value Sym. Name + Addend 000000217220 000000000008 R_X86_64_RELATIVE 0000000000217220 No other _dl_debug_state() call is done at a later time so the debugger cannot start tracking the threads. The only possibility is to delay libthread_db initialization by placing a breakpoint at the _dl_debug_state() notification time to the function found for DT_INIT. While I implemented the attached GDB patch and so I do not try to avoid this place for the fix I do not find it as the right solution. ------------------------------------------------------------------------------ Another possibility is to fix libpthread data structures to be fully PIC and so understandable by libthread_db at the current _dl_debug_state() point (A). It seems libthread_db can already parse libpthread at (B) time still before its __pthread_initialize_minimal() is called from DT_INIT. I find it also as a real possibility how to fix glibc libthread_db. Still I do not see there a regression risk to delay _dl_debug_state() after relocations resolving; there is nothing more useful on an unrelocated library. (STT_IFUNC code - called code returning a value for relocations - would be a bit harder to debug but only for resolving with RTLD_NOW - not a problem.) Adjusted the patch for glibc-2.8.90-16 making it a minimal working change. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

15 years, 6 months

1
0
0 / 0

[Bug 208779] add keyboard selector in the panel by default

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=208779 Nikos Charonitakis <nikosx(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flag|needinfo? | --- Comment #6 from Nikos Charonitakis <nikosx(a)gmail.com> 2008-11-12 10:55:33 EDT --- well, i saw the new keyboard selector at login. This was a new disaster :) see https://bugzilla.redhat.com/show_bug.cgi?id=469761 Any way, what changes now? You select Greek keyboard at login and by doing this you cant even login... If you decide to login at last, you select US keyboard. I ve done this way and i have again to set keyboard applet from scratch adding greek keyboard etc Now is even missing xorg.conf line (actually their is no xorg.conf at all) for Greek keyboard, so the usual layout combination does not work. Summary: Situation is even worst today ;) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

15 years, 6 months

1
0
0 / 0

[Bug 179759] Ant should provide $ANT_HOME/lib/ant.jar

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=179759 Orion Poplawski <orion(a)cora.nwra.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |Reopened Status|CLOSED |ASSIGNED CC| |orion(a)cora.nwra.com Resolution|INSUFFICIENT_DATA | QAContact| |extras-qa(a)fedoraproject.org Status Whiteboard| bzcl34nup | --- Comment #4 from Orion Poplawski <orion(a)cora.nwra.com> 2008-11-12 10:55:20 EDT --- ${ant.home} is now /usr/share/ant, which is appropriate. But many projects expect ${ant.home}/lib/ant.jar to exist as in the binary distribution (I'm seeing it in gridengine's sdm module). Please provide symlinks to the jar files in ${ant.home}/lib/. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

15 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

triage November 2008