Bug#350989: Bug##350989: libtool on alpha causes linking errors when run on AFS
> So. Does the same happen with newer versions like 4.0 or 4.1? And how > can it be reproduced? Sorry that it took a little long to reply... Anyway, please close the bug: I cannot reproduce it myself anymore! I was able to do it with several independent sources with 100% probability at the time of the original bug report, but not any more. I'd be delighted to know what's happened, but the bug's still probably best closed. -Juha -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | Laboratory of Theoretical Physics | | Department of Physics, University of Turku| | home: http://www.utu.fi/~juolja/ | --- signature.asc Description: PGP signature
Bug#361024: problem affects many other programs
Hello, dia displays a fatal error on startup, too. I suspect that a lot of programs is affected, and I'm not sure if my most recent series of gq crashes (usually "rock solid" for me) could be attributed to this problem, too. Since unrelated software is affected, I suggest upgrading to "important". Best, --Toni++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#361024: libstdc++6: cannot handle TLS data
severity 361024 critical thanks dude Justification: breaks unrelated software This bug is causing total breakage of apt-show-versions. It's also causing problems with dia and gnucash (unable to load plugins written in C++) and possibly other software in the archive. Nick Lewycky -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: libstdc++6: cannot handle TLS data
Processing commands for [EMAIL PROTECTED]: > severity 361024 critical Bug#361024: libstdc++6: cannot handle TLS data Severity set to `critical'. > thanks dude Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#361024: Simple test case [Was: libstdc++.so.6: cannot handle TLS data]
Sheplyakov Alexei writes: > Hello! > > On Wed, 05 Apr 2006 18:41:05 -0600, Gordon Haverland wrote: > > Traceback (most recent call last): > > File "/usr/bin/apt-listchanges", line 30, in ? > > import apt_pkg > > ImportError: libstdc++.so.6: cannot handle TLS data > > I've seen many similar errors on my system too (I've got a bunch of > home-brew Guile[1] modules written in C++). Such an error appears whenever > a thread created by C code tries to dlopen(3) C++ shared library. > I've managed to create (hopefully) simple test case (based on > C++ dlopen mini-HOWTO), see the attached tarball (unpack and run > `make'). I did not reported this before since I thought that's /me doing > something wrong... thanks for the testcase, however I'm unable to reproduce the failure with a recent unstable archive, nor do I see the apt-listchanges failures. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Bug c++/26757] [4.1 regression] ICE (Segmentation fault) building 3ddesktop source
--- Comment #9 from reichelt at gcc dot gnu dot org 2006-04-06 16:13 --- *** Bug 27056 has been marked as a duplicate of this bug. *** -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26757 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#361024: Simple test case [Was: libstdc++.so.6: cannot handle TLS data]
Matthias Klose wrote: > thanks for the testcase, however I'm unable to reproduce the failure > with a recent unstable archive, nor do I see the apt-listchanges > failures. I can confirm the apt-listchanges failure here, running unstable. The only exceptional thing about my system that I think could be relevant is that I'm running a non-Debian kernel from kernel.org (2.6.15.6). The error message itself is being printed by ld.so, which belongs to the libc6 package. My libc6 version is "2.3.6-5". I've tried running the testcase with "LD_DEBUG=all" in the environment, but the output wasn't very illuminating (attached). Perhaps someone not showing symptoms can diff it against a run on their own system. Actually, valgrind screams with lots of errors in /lib/ld-2.3.6.so when running the testcase, or any other affected program. Hmm. That would explain its non-deterministic nature. Valgrind output also attached. Nick Lewycky demo.ld.bz2 Description: Unix tar archive demo.valgrind.bz2 Description: Unix tar archive
[Bug c++/26757] [4.1 regression] ICE (Segmentation fault) building 3ddesktop source
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Keywords||monitored http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26757 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Bug c++/26757] [4.1 regression] ICE (Segmentation fault) building 3ddesktop source
-- fang at csl dot cornell dot edu changed: What|Removed |Added CC||fang at csl dot cornell dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26757 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#361024: Simple test case [Was: libstdc++.so.6: cannot handle TLS data]
Nick Lewycky writes: > Matthias Klose wrote: > > > thanks for the testcase, however I'm unable to reproduce the failure > > with a recent unstable archive, nor do I see the apt-listchanges > > failures. > > I can confirm the apt-listchanges failure here, running unstable. The > only exceptional thing about my system that I think could be relevant is > that I'm running a non-Debian kernel from kernel.org (2.6.15.6). > > The error message itself is being printed by ld.so, which belongs to the > libc6 package. My libc6 version is "2.3.6-5". > > I've tried running the testcase with "LD_DEBUG=all" in the environment, > but the output wasn't very illuminating (attached). Perhaps someone not > showing symptoms can diff it against a run on their own system. > > Actually, valgrind screams with lots of errors in /lib/ld-2.3.6.so when > running the testcase, or any other affected program. Hmm. That would > explain its non-deterministic nature. Valgrind output also attached. Aurelian Jarno pointed out the following: only reproducible with 2.4 kernels or if you (re)move /lib/tls on a 2.6 kernel. Officially we don't support 2.4 kernels anymore, whatever "deprecated" means. See http://lists.debian.org/debian-devel-announce/2006/03/msg7.html Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
re: IGN KEYWORDS
I have asked someone to build a website for me as a way to market the published books I have written, and am in the processing of writing. I have been told that if I purchase a key word from IGetNet.com that hasn't already been purchased, I can get past other sites, giving me a marketing advantage. I am a writer of Christian material, clean humor, and interesting biographicals of celebrities I've known. I'd appreciate hearing from you. Fred Stoutland Frederick A. Stoutland Sr. [EMAIL PROTECTED] Why Wait? Move to EarthLink.
Bug#361024: Simple test case [Was: libstdc++.so.6: cannot handle TLS data]
On Thursday 06 April 2006 11:04, Matthias Klose wrote: > Sheplyakov Alexei writes: > > On Wed, 05 Apr 2006 18:41:05 -0600, Gordon Haverland wrote: > > > Traceback (most recent call last): > > > File "/usr/bin/apt-listchanges", line 30, in ? > > > import apt_pkg > > > ImportError: libstdc++.so.6: cannot handle TLS data > > > > I've seen many similar errors on my system too (I've got a > > bunch of home-brew Guile[1] modules written in C++). Such an > > error appears whenever a thread created by C code tries to > > dlopen(3) C++ shared library. I've managed to create > > (hopefully) simple test case (based on C++ dlopen > > mini-HOWTO), see the attached tarball (unpack and run > > `make'). I did not reported this before since I thought > > that's /me doing something wrong... > > thanks for the testcase, however I'm unable to reproduce the > failure with a recent unstable archive, nor do I see the > apt-listchanges failures. I know the last 3 apt-get upgrade's all did this, I am not sure how far back it happens. Is there something I can do on this end to get you more data? It seems consistent on this box (for now). Gord -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#361024: Simple test case [Was: libstdc++.so.6: cannot handle TLS data]
Matthias Klose wrote: > Aurelian Jarno pointed out the following: only reproducible with 2.4 > kernels or if you (re)move /lib/tls on a 2.6 kernel. I'm running it on a 2.6 kernel and my /lib/tls is right where it belongs. However, I note with interest that the following makes the bug go away: export LD_LIBRARY_PATH=/lib/tls /lib/tls isn't in my /etc/ld.so.conf. Should it be? When did that change? And what about the subdirectories under /lib/tls? What package is supposed to install/own/update the ld.so.conf? Nick Lewycky -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#361024: Simple test case [Was: libstdc++.so.6: cannot handle TLS data]
On Thu, Apr 06, 2006 at 10:36:43PM +0200, Matthias Klose wrote: > Nick Lewycky writes: > > Matthias Klose wrote: > > > thanks for the testcase, however I'm unable to reproduce the failure > > > with a recent unstable archive, nor do I see the apt-listchanges > > > failures. > > I can confirm the apt-listchanges failure here, running unstable. The > > only exceptional thing about my system that I think could be relevant is > > that I'm running a non-Debian kernel from kernel.org (2.6.15.6). > > The error message itself is being printed by ld.so, which belongs to the > > libc6 package. My libc6 version is "2.3.6-5". > > I've tried running the testcase with "LD_DEBUG=all" in the environment, > > but the output wasn't very illuminating (attached). Perhaps someone not > > showing symptoms can diff it against a run on their own system. > > Actually, valgrind screams with lots of errors in /lib/ld-2.3.6.so when > > running the testcase, or any other affected program. Hmm. That would > > explain its non-deterministic nature. Valgrind output also attached. > Aurelian Jarno pointed out the following: only reproducible with 2.4 > kernels or if you (re)move /lib/tls on a 2.6 kernel. > Officially we don't support 2.4 kernels anymore, whatever "deprecated" > means. > See http://lists.debian.org/debian-devel-announce/2006/03/msg7.html We still have to support installing etch glibc on sarge kernels for upgrade purposes! -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
re: IGN KEYWORDS
Jay Williams: I sent an e-mail to debian about wanting to have certain words used by Internet users searching to be referred to me. I'm having a website developed to promote my books and wondered if you could help me get more hits by using your services. please advise. Fred Stoutland Frederick A. Stoutland Sr. [EMAIL PROTECTED] Why Wait? Move to EarthLink.
Bug#361024: Simple test case [Was: libstdc++.so.6: cannot handle TLS data]
Nick Lewycky writes: > Matthias Klose wrote: > > Aurelian Jarno pointed out the following: only reproducible with 2.4 > > kernels or if you (re)move /lib/tls on a 2.6 kernel. > > I'm running it on a 2.6 kernel and my /lib/tls is right where it > belongs. However, I note with interest that the following makes the bug > go away: > > export LD_LIBRARY_PATH=/lib/tls > > /lib/tls isn't in my /etc/ld.so.conf. Should it be? When did that > change? And what about the subdirectories under /lib/tls? What package > is supposed to install/own/update the ld.so.conf? Does /etc/ld.so.nohwcap exist? What happens if you (re)move it? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#361024: Simple test case [Was: libstdc++.so.6: cannot handle TLS data]
Matthias Klose wrote: > Does /etc/ld.so.nohwcap exist? What happens if you (re)move it? No it doesn't. I do have an /etc/ld.so.hwcappkgs, if that's related. It contains: libc6 2.3.6-5 libc6-i686 2.3.6-5 Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#361024: Simple test case [Was: libstdc++.so.6: cannot handle TLS data]
I did another apt-get upgrade today, and as expected, this bug was present again (at least 4 in a row now). From suggestions in this thread, I ran it under LD_DEBUG=all, and captured stdout/stderr. This captured output is 481713 lines long, with the TLS error on line 26074 of that file. I really don't think submitting a 36 MB file is the thing to do, so I leave it to you guys as to whether this is of any use. Gord
[Bug c++/26757] [4.1 regression] ICE (Segmentation fault) building 3ddesktop source
--- Comment #10 from amacleod at redhat dot com 2006-04-06 21:05 ---
using the program from comment #5, I get IL for load_background_image that
looks like:
void load_background_image() ()
{
int D.1767;
int D.1766;
struct Config * cfg.2;
int D.1764;
int D.1763;
struct Config * cfg.1;
:
cfg.1 = cfg;
D.1763 = cfg.1->bg_size;
D.1764 = D.1763 + 1;
cfg.1->bg_size = D.1764;
cfg.2 = cfg;
D.1766 = cfg.2->autoacquire;
D.1767 = D.1766 + 1;
cfg.2->autoacquire = D.1767;
return;
}
THe two assignments of cfg into temps, (cfg.1 and cfg.2) are using DIFFERENT
cfg variables (ie, different addresses) on the RHS with the same UID. very
bad. either they should be the same var_decl (which I presume is what is
intended), or they should have different UIDs.
This patchlet provides an assert the triggers when it happens:
Index: tree-dfa.c
===
*** tree-dfa.c (revision 112248)
--- tree-dfa.c (working copy)
*** referenced_var_insert (unsigned int uid,
*** 610,615
--- 610,619
h->uid = uid;
h->to = to;
loc = htab_find_slot_with_hash (referenced_vars, h, uid, INSERT);
+ /* This assert can only trigger is a variable with the same UID has been
+ inserted already, but has a different pointer value. ie, we have 2
+ different variables with the same UID. Bug 26757. */
+ gcc_assert ((*(struct int_tree_map **)loc) == NULL);
*(struct int_tree_map **) loc = h;
}
what happens is that the referenced_var list hashes based on the UID of a
variable. referenced_var_insert is only called when a new variable is
discovered, so it presumes that the hash slot is already empty.
add_referenced_var calls referenced_var_insert when it sees a new variable, and
it determines a variable is new by hashing on the address of the variable in
the walk_state->vars_found table.
since there are 2 different 'cfg' vars, referenced_var_insert overwrote the
first 'cfg''s address when it looked up the UID.
WHen we go out of ssa, delete_tree_ssa removes all the var annotations of
referenced vars. The original 'cfg' no longer occurs in the referenced var
list, so it is not cleared.
Along comes the next function, and it is using the original 'cfg', and voila,
it still has a var_annotation, complete with current_def and lots of fun things
set.
I havent tracked down where the cfg variable is created, but Im willing to bet
a C++ front end person knows right off the bat by looking at the function.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26757
--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
gcc-4.1 4.1.0-1 MIGRATED to testing
FYI: The status of the gcc-4.1 source package in Debian's testing distribution has changed. Previous version: (not in testing) Current version: 4.1.0-1 -- This email is automatically generated; [EMAIL PROTECTED] is responsible. See http://people.debian.org/~henning/trille/ for more information. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#361024: Simple test case [Was: libstdc++.so.6: cannot handle TLS data]
Ugh. I found my problem. Checking "ldconfig -p" showed that /lib/libc.so.6 => /lib/libc.so.6 with no hwcap specific entries at all. It seems I had a local diversion of /sbin/ldconfig and have been running one from March 15, 2000 for the past six years. I'm more than a little surprised. Anyways, running the modern ldconfig fixes my problem and allows the apps to find the proper libraries. Sorry for the confusion. Thanks, Nick Lewycky -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
