Re: dpkg bus error on sparc/unstable: Re: Bits from the RM
On Tue, Aug 26, 2003 at 12:29:09PM -0500, Adam Heath wrote: Well, if I compile lib/myopt.c and lib/startup.c, without -O2, I get no bus error. Maybe this is a gcc issue? It's probably a good idea to try gcc-snapshot and see if this has been fixed already. In the worst cases, gcc hackers sometimes use binary searches of the CVS repository to find out when something broke, or when something was fixed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg bus error on sparc/unstable: Re: Bits from the RM
On Tue, Aug 26, 2003 at 12:29:09PM -0500, Adam Heath wrote: vore:~ dpkg Bus error Well, if I compile lib/myopt.c and lib/startup.c, without -O2, I get no bus error. Maybe this is a gcc issue? FWIW, the comment here http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11366#c8 originally dealing with the XDM-AUTHORIZATION cookie issue, applies equally well to these sorts of situation. If someone works it down to a flag, or a combination of flags, and a preprocessed source file, then GCC's upstream can hack on it. -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian W. Kernighan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the RM
On Fri, 22 Aug 2003, GOTO Masanori wrote: It was reported by joshk on IRC, but I'm not still clear where this problem come from. Example: ultra30:~ dpkg -s libc6 | grep Version Version: 2.3.2-3 ultra30:~ dpkg -s dpkg | grep Version Version: 1.10.10 ultra30:~ dpkg Bus error dpkg works well with some options, but only typing `dpkg' breaks with bus error. It's not related with the existence of libc6-sparc64. From tracking with gdb, dpkg breaks setjmp()/longjmp(). The mysterious thing is that it works fine to compile gcc-3.2/gcc-3.3 without -O2 optimization. It's also ok with glibc 2.3.1-17, IIRC. Hmm. I'm reminded of a problem on s390x. 64-bit arch, but when dpkg was initializing some variable, it only did it to the lower(or upper, can't recall) 32 bits. Later, it blew up. It's too bad valgrind doesn't work on non-i386. Is there a debian machine I can access that has this problem? The last 2 times some odd issue came up like this, one turned out to be a dpkg bug(s390x), and one was a multi-year old bug in libc6 assem(memcpy error, at the end of the buffer, when using mmap, on alpha). In both cases, it didn't take me long to track down(not more than half a day). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the RM
On Tue, 2003-08-26 at 01:01, Adam Heath wrote: Is there a debian machine I can access that has this problem? Yes. You can use vore, unstable chroot. p. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the RM
At Mon, 25 Aug 2003 19:01:14 -0500 (CDT), Adam Heath wrote: On Fri, 22 Aug 2003, GOTO Masanori wrote: It was reported by joshk on IRC, but I'm not still clear where this problem come from. Example: ultra30:~ dpkg -s libc6 | grep Version Version: 2.3.2-3 ultra30:~ dpkg -s dpkg | grep Version Version: 1.10.10 ultra30:~ dpkg Bus error dpkg works well with some options, but only typing `dpkg' breaks with bus error. It's not related with the existence of libc6-sparc64. From tracking with gdb, dpkg breaks setjmp()/longjmp(). The mysterious thing is that it works fine to compile gcc-3.2/gcc-3.3 without -O2 optimization. It's also ok with glibc 2.3.1-17, IIRC. Hmm. I'm reminded of a problem on s390x. 64-bit arch, but when dpkg was initializing some variable, it only did it to the lower(or upper, can't recall) 32 bits. Later, it blew up. dpkg works fine with trex.debian.org dchroot unstable + my self built 2.3.2-1 (2003-07-08 cvs) using LD_LIBRARY_PATH, so it seems other issue. It's too bad valgrind doesn't work on non-i386. Is there a debian machine I can access that has this problem? The last 2 times some odd issue came up like this, one turned out to be a dpkg bug(s390x), and one was a multi-year old bug in libc6 assem(memcpy error, at the end of the buffer, when using mmap, on alpha). In both cases, it didn't take me long to track down(not more than half a day). Yes, you can check on vore.debian.org dchroot unstable. vore:~ dpkg Bus error Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
dpkg bus error on sparc/unstable: Re: Bits from the RM
On Tue, 26 Aug 2003, GOTO Masanori wrote: At Mon, 25 Aug 2003 19:01:14 -0500 (CDT), Adam Heath wrote: On Fri, 22 Aug 2003, GOTO Masanori wrote: It was reported by joshk on IRC, but I'm not still clear where this problem come from. Example: ultra30:~ dpkg -s libc6 | grep Version Version: 2.3.2-3 ultra30:~ dpkg -s dpkg | grep Version Version: 1.10.10 ultra30:~ dpkg Bus error dpkg works well with some options, but only typing `dpkg' breaks with bus error. It's not related with the existence of libc6-sparc64. From tracking with gdb, dpkg breaks setjmp()/longjmp(). The mysterious thing is that it works fine to compile gcc-3.2/gcc-3.3 without -O2 optimization. It's also ok with glibc 2.3.1-17, IIRC. Hmm. I'm reminded of a problem on s390x. 64-bit arch, but when dpkg was initializing some variable, it only did it to the lower(or upper, can't recall) 32 bits. Later, it blew up. dpkg works fine with trex.debian.org dchroot unstable + my self built 2.3.2-1 (2003-07-08 cvs) using LD_LIBRARY_PATH, so it seems other issue. It's too bad valgrind doesn't work on non-i386. Is there a debian machine I can access that has this problem? The last 2 times some odd issue came up like this, one turned out to be a dpkg bug(s390x), and one was a multi-year old bug in libc6 assem(memcpy error, at the end of the buffer, when using mmap, on alpha). In both cases, it didn't take me long to track down(not more than half a day). Yes, you can check on vore.debian.org dchroot unstable. vore:~ dpkg Bus error Well, if I compile lib/myopt.c and lib/startup.c, without -O2, I get no bus error. Maybe this is a gcc issue? -- (unstable)[EMAIL PROTECTED]:~/dpkg-1.10.10$ gcc -v Reading specs from /usr/lib/gcc-lib/sparc-linux/3.3.2/specs Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib --with-cpu=v7 --enable-objc-gc sparc-linux Thread model: posix gcc version 3.3.2 20030812 (Debian prerelease) (unstable)[EMAIL PROTECTED]:~/dpkg-1.10.10$ dpkg -s libc6 Version: 2.3.2-3 -- dpkg is 1.10.10. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg bus error on sparc/unstable: Re: Bits from the RM
On Tue, 26 Aug 2003, Adam Heath wrote: Well, if I compile lib/myopt.c and lib/startup.c, without -O2, I get no bus error. Maybe this is a gcc issue? gcc 3.2 also fails, but 2.95 works fine, no errors. doogie lib/myopt.c(loadcfgfile) mrvn doogie: Did that ever stop anything from breaking? doogie with -O2, it fails in that function, on the last free doogie when I remove -O2, it fails in lib/startup.c:standard_startup doogie removing -O2 from that file, and it works(I don't know where it failed in that function) ps: compiling statically with 2.95 and libc 2.3.2-2 fails, with: gcc-2.95 -L../lib -L../optlib -static -o md5sum-static md5sum.o -ldpkg -lopt /usr/lib/gcc-lib/sparc-linux/2.95.4/libgcc.a(_udivdi3.o)(.text+0xac): In function `__udivdi3': : undefined reference to `.udiv' /usr/lib/gcc-lib/sparc-linux/2.95.4/libgcc.a(_umoddi3.o)(.text+0xac): In function `__umoddi3': : undefined reference to `.udiv' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the RM
At Thu, 21 Aug 2003 00:17:27 +1000, Anthony Towns wrote: [1 text/plain; us-ascii (quoted-printable)] On Wed, Aug 20, 2003 at 08:49:33AM -0400, Matt Zimmerman wrote: On Tue, Aug 19, 2003 at 04:49:25PM +1000, Anthony Towns wrote: Also make sure to include some leg room if you depend on packages that have a tendency to be buggy (glibc, for example). The new glibc has already stalled the progress into testing of a large number of packages, and the number of RC bugs still seems to be going up. How are we going to manage to produce a release in 6 months the face of this obstacle? The last time there was this sort of breakage, it took many months just to get glibc itself it sorted out. Yup. The difference is that this time we have a Glibc maintenance team that's able to work together effectively, has some experience with the package, and has a better understanding how important it is to get it fixed quickly. AFAIK, the unresolved difficult bugs are: (1) hppa build (2) dpkg (setjmp/longjmp) on sparc (3) NIS (will be fixed?) (4) misterious apache on ia64 bug. Note that (3) becomes ok to revert patches, (4) may be non-glibc bug. Well, they are still something hard work. :-) My concern is (1) hppa build. If we can't get hppa glibc, we may need to drop it finally... Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the RM
On Thu, Aug 21, 2003 at 05:52:32PM +0900, GOTO Masanori wrote: AFAIK, the unresolved difficult bugs are: (1) hppa build (2) dpkg (setjmp/longjmp) on sparc (3) NIS (will be fixed?) (4) misterious apache on ia64 bug. Is there a bug# for (2)? If not, could someone forward the appropriate mails to the BTS for tracking, please? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the RM
On Thu, 21 Aug 2003, Anthony Towns wrote: On Thu, Aug 21, 2003 at 05:52:32PM +0900, GOTO Masanori wrote: AFAIK, the unresolved difficult bugs are: (1) hppa build (2) dpkg (setjmp/longjmp) on sparc (3) NIS (will be fixed?) (4) misterious apache on ia64 bug. Is there a bug# for (2)? If not, could someone forward the appropriate mails to the BTS for tracking, please? I'd be interested too. Haven't seen anything on -dpkg about it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the RM
At Thu, 21 Aug 2003 12:09:29 -0500 (CDT), Adam Heath wrote: On Thu, 21 Aug 2003, Anthony Towns wrote: On Thu, Aug 21, 2003 at 05:52:32PM +0900, GOTO Masanori wrote: AFAIK, the unresolved difficult bugs are: (1) hppa build (2) dpkg (setjmp/longjmp) on sparc (3) NIS (will be fixed?) (4) misterious apache on ia64 bug. Is there a bug# for (2)? If not, could someone forward the appropriate mails to the BTS for tracking, please? I'd be interested too. Haven't seen anything on -dpkg about it. It was reported by joshk on IRC, but I'm not still clear where this problem come from. Example: ultra30:~ dpkg -s libc6 | grep Version Version: 2.3.2-3 ultra30:~ dpkg -s dpkg | grep Version Version: 1.10.10 ultra30:~ dpkg Bus error dpkg works well with some options, but only typing `dpkg' breaks with bus error. It's not related with the existence of libc6-sparc64. From tracking with gdb, dpkg breaks setjmp()/longjmp(). The mysterious thing is that it works fine to compile gcc-3.2/gcc-3.3 without -O2 optimization. It's also ok with glibc 2.3.1-17, IIRC. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the RM
At 21 Aug 2003 17:29:16 +0100, Philip Blundell wrote: On Thu, 2003-08-21 at 09:52, GOTO Masanori wrote: My concern is (1) hppa build. If we can't get hppa glibc, we may need to drop it finally... I don't think the hppa glibc is as inscrutable as all that. The main problem seems to be that Carlos is the only person working on the bug, and he is only able to devote a limited amount of time to it. If and when we get to the point of hppa being the only outstanding glibc issue, we will just have to lean on some of the other PA guys to get involved. Indeed. My point is hppa is release architecture. So if toolchain and core library do not work well, then we can't release, or we drop it from release archs. The main problem that is concerning me at the moment is the large number of reports of binary incompatibility with older versions. It's all very well to dismiss the difficulties with non-free software as somebody else's problem, but the fact that so many of these issues are cropping up all at once does suggest that glibc itself is doing something wrong. However, in absence of a reliable way to reproduce the bug using only free software, it is hard to see a way forwards. I will have a play with that antique inn that seemed to be experiencing trouble, and see if I can get a handle on it like that. Yes, good point. I forgot to write about this binary incompatibility issue. It's numbered as (5) from my previous mail, and it's also concerned item. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
