Re: Bug#668794: reopen
severity 668794 important forwarded 668794 http://code.google.com/p/go/issues/detail?id=3533 thank you Hi Robert, (sorry for BTS juggling, I found your comment just after I sent the first email.) Anyway I agree that the problem needs to be fixed upstream, but I would suggest that we keep GNU/KFreeBSD build enabled for the moment and if this cannot be fixed before freeze, we can always disable it. It would be shame to disable this build right now, because there would be basically no push to make it work (if there is more stuff broken than just the tests). Thus I am downgrading the severity to important, so it doesn't block transition, and will take care of GNU/KFreeBSD builds somewhere around June. Is that ok with you? Ondrej On Mon, Apr 16, 2012 at 00:04, Robert Millan wrote: > found 668794 2:1-4 > thanks > > Hi Ondřej, > > I notice you disabled the golang testsuite because it hangs on > GNU/kFreeBSD. However, the problem is still present, and chances are > it makes golang unusable on that platform. > > I gave the source a look, and it seems that on GNU/kFreeBSD golang is > playing with thread primitives, bypassing libc. For example it > invokes thr_new() kernel call directly, and also calls sigprocmask() > to reset the signal mask in code that is clearly multithreaded [1]. > > This means that either golang intends to completely replace > libpthread, or it intends to play along with existing libpthread. I'm > not sure which one applies here, but in both cases there is a problem > that needs to be fixed in golang. > > So please don't disable the testsuite. If golang can't be built on > GNU/kFreeBSD, unless you know it's a bug in the system libraries the > problem needs to be fixed in golang. If nobody can spend the time to > fix it here, then you should consider not providing the package for > kfreebsd-*. > > [1] On multithreaded programs, use of sigprocmask() is reserved to > system libraries. > > -- > Robert Millan > > -- Ondřej Surý -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caljhhg_ncp_+svyx5wcajaxmgkxgzzdsjut-hr3f8v-t5qr...@mail.gmail.com
Re: Bug#668794: reopen
Hi Ondřej, Thanks for forwarding this upstream. It seems to me that it'll be best to get them involved. It takes either someone with a clear idea of golang codebase or a complete audit to properly resolve this. And we don't have time for a complete audit :-( El 16 d’abril de 2012 10:29, Ondřej Surý ha escrit: > Anyway I agree that the problem needs to be fixed upstream, but I would > suggest > that we keep GNU/KFreeBSD build enabled for the moment and if this cannot be > fixed before freeze, we can always disable it. It would be shame to disable > this > build right now, because there would be basically no push to make it > work (if there > is more stuff broken than just the tests). > > Thus I am downgrading the severity to important, so it doesn't block > transition, and > will take care of GNU/KFreeBSD builds somewhere around June. > > Is that ok with you? I'm worried that other packages could begin depending on golang on kfreebsd-*, and then it can be a mess if we have to pull it off. But I understand your interest in providing it. Please do keep in mind that we have very little manpower. -- Robert Millan -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caofdtxmmj-jchkxb+cbbtqg4hioi_vva6nzbpgwzkqavay-...@mail.gmail.com
Re: Bug#668794: reopen
On Mon, Apr 16, 2012 at 12:58, Robert Millan wrote: > I'm worried that other packages could begin depending on golang on > kfreebsd-*, and then it can be a mess if we have to pull it off. But > I understand your interest in providing it. Please do keep in mind > that we have very little manpower. I understand, but I think it will take some time before it will come to the point we will have packages depending on golang in the archive. Anyway I am prepared to clean the mess if there will be any. Anyway let's hope the upstream will take a look at this before freeze. O. -- Ondřej Surý -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CALjhHG9=pJiS0LLN7O43HcXde5+qT9QW+MNad=VD5nCS=dj...@mail.gmail.com
Bug#669043: Program received signal ?, Unknown signal.
Package: gdb
Version: 7.0.1-2+b1
Severity: normal
Tags: patch
User: debian-bsd@lists.debian.org
Usertags: kfreebsd
When debugged process receives signal 32, 33 or 34, gdb prints an error
message without actual signal information:
Program received signal ?, Unknown signal.
This happens because Glibc on GNU/kFreeBSD uses these signal numbers
internally (in LinuxThreads). As they have no associated macro name,
they need to be registered manually by their numbers. See attached
patch.
This is only temporary so please don't forward the patch upstream. When
we switch to NPTL we'll likely be able to use standarized macro names
from .
-- System Information:
Debian Release: 6.0.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 8.1-1-amd64
Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages gdb depends on:
ii libc0.1 2.11.3-2 Embedded GNU C Library: Shared lib
ii libexpat1 2.0.1-7 XML parsing C library - runtime li
ii libkvm0 8.1-5+squeeze1 FreeBSD kvm (kernel memory interfa
ii libncurses5 5.7+20100313-5 shared libraries for terminal hand
ii libpython2.62.6.6-8+b1 Shared Python runtime library (ver
ii libreadline66.1-3GNU readline and history libraries
ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime
gdb recommends no packages.
Versions of packages gdb suggests:
pn gdb-doc(no description available)
-- no debconf information
int
main ()
{
kill (getpid(), 34);
}
=== modified file 'gdb/common/signals.c'
--- gdb/common/signals.c 2012-04-16 11:24:47 +
+++ gdb/common/signals.c 2012-04-16 16:50:01 +
@@ -334,6 +334,15 @@ target_signal_from_host (int hostsig)
return TARGET_SIGNAL_INFO;
#endif
+#if defined(__GLIBC__) && defined(__FreeBSD_kernel__)
+ if (hostsig == 32)
+return TARGET_SIGNAL_LINUXTHREADS_RESTART;
+ if (hostsig == 33)
+return TARGET_SIGNAL_LINUXTHREADS_CANCEL;
+ if (hostsig == 34)
+return TARGET_SIGNAL_LINUXTHREADS_DEBUG;
+#endif
+
#if defined (REALTIME_LO)
if (hostsig >= REALTIME_LO && hostsig < REALTIME_HI)
{
=== modified file 'include/gdb/signals.def'
--- include/gdb/signals.def 2012-04-16 11:24:47 +
+++ include/gdb/signals.def 2012-04-16 16:51:18 +
@@ -194,7 +194,11 @@ SET (TARGET_EXC_EMULATION, 148, "EXC_EMU
SET (TARGET_EXC_SOFTWARE, 149, "EXC_SOFTWARE", "Software generated exception")
SET (TARGET_EXC_BREAKPOINT, 150, "EXC_BREAKPOINT", "Breakpoint")
+SET (TARGET_SIGNAL_LINUXTHREADS_RESTART, 151, "32", "LinuxThreads restart signal")
+SET (TARGET_SIGNAL_LINUXTHREADS_CANCEL, 152, "33", "LinuxThreads cancel signal")
+SET (TARGET_SIGNAL_LINUXTHREADS_DEBUG, 153, "34", "LinuxThreads debug signal")
+
/* If you are adding a new signal, add it just above this comment. */
/* Last and unused enum value, for sizing arrays, etc. */
-SET (TARGET_SIGNAL_LAST, 151, NULL, "TARGET_SIGNAL_MAGIC")
+SET (TARGET_SIGNAL_LAST, 154, NULL, "TARGET_SIGNAL_MAGIC")
about test_socket hang
Hi, I found something about test_socket hang. The problem I'm seeing looks like a race condition. kdump -H yields: 73334 100505 python CALL thr_kill(0x1884e,SIG(null)) 73334 100505 python RET thr_kill 0 73334 100505 python CALL thr_exit(0xccab78) 73334 100430 python CALL thr_kill(0x187f9,SIG(null)) 73334 100430 python RET thr_kill 0 73334 100430 python CALL poll(0xc6eee0,0x1,0x7d0) As you can see in this log, thread 100505 sends restart signal to thread 100430 *BEFORE* thread 100430 has started poll() kernel call. Then thread 100430 is stuck in poll() with nobody to restart it. If I hit ^Z, poll is interrupted, then "fg" makes it progress. By doing this a couple of times I managed to make test_socket finish. Alternatively, I patched glibc with this workaround (see attachment). This makes the test finish in about 16 seconds. Going back to the race between thr_kill() and poll(), any idea what could be causing this? To begin with I don't even know how to get a backtrace for the relevant calls :-/ -- Robert Millan workaround.diff Description: Binary data
Re: Updating w.d.o/{intro/organization#distribution,ports/}
[ Huge cross-post, sorry. Please, only respond to your port list and debian-www@l.d.o, or at least keep me CC if you drop debian-www ] Hi ports and ports-like team, Le 05/04/2012 16:27, David Prévot a écrit : > The ports and ports-like part of our organization page [1] might be > pretty outdated on the members side. Could you please confirm that the > members list of your team is still accurate, or provide an updated list. > Without any answer within a week, I'll drop the members name from this > page, but will keep the name of the port and a link to the mailing list > as main contact point. If you answer after a week, I'll also be happy to > update the page afterwards. It's been a long week… Thanks to Bill (Alpha), Dann (IA-64), Thorsten (m68k), Carlos and John (PA-RISC), Samuel and Svante (GNU/Hurd), and Christoph and Arno (GNU/kFreeBSD), the organization page [1] has just been updated. http://anonscm.debian.org/viewvc/webwml/webwml/english/intro/organization.data?r1=1.428&r2=1.429 If you have a second thought, please don't hesitate to reply so we can update the page [1]. > 1: http://www.debian.org/intro/organization#distribution > > If you have any update to propose about your port page [2], I'd also be > happy to update the respective page on your behalf, and would be even > happier if you do it yourself (please, ask for write access [3] if > you're not already a member of webwml). > > 2: http://www.debian.org/ports/ > 3: http://www.debian.org/devel/website/using_cvs#write-access The offer still stands ;-) > We also have one open bug report [4] about the www.d.o/ports/ part, > specific to amd64, any help to solve it would be welcome (closing it in > case it doesn't make sense could also be appropriate). > > 4: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611830 This one too… Regards David signature.asc Description: OpenPGP digital signature
