Re: Who is still here?
Like many, I came to Debian GNU/kFreeBSD when it was a way I could get Debian and ZFS together. Early on I contributed some patches (improved thread debugging in gdb, and a working valgrind port being the two that I recall offhand in which I had a great deal of pride at the time) which unfortunately have languished on bugs.debian.org. At this point, I am making plans to transition the data and services on my lone kfreebsd machine to a fresh GNU/Linux install on new hardware. I really appreciate all the time that people have willingly spent on the kfreebsd port, it has served me well. But in my case it is clear that it is a closing chapter in my life as a Debian user and sometime contributor. All the best, Jeff
Bug#781161: dovecot-core: Can't log in via imap on kFreeBSD amd64 (Auth request missing a file descriptor)
Package: dovecot-core
Version: 1:2.2.15-1
Severity: important
Dear Maintainer,
After upgrading my Debian kFreeBSD machine from Wheezy to Jessie,
dovecot imap stopped working. The version from experiemental was also
broken in the same way.
After I attempt to sign in with valid information, the following messages
are logged:
dovecot: imap: Error: Auth request missing a file descriptor
dovecot: imap-login: Error: read(imap) failed: Remote closed connection
(service's process_limit reached?)
When direcly invoking imap (mutt's set tunnel=/usr/lib/dovecot/imap),
all is well. When I attempt to sign in with invalid information, the
incorrect password is diagnosed. So this problem is not actually with
authentication.
I was not able to determine the exact cause of the problem, but I did
determine that the problems pertains to the fd-passing code, fd_send() /
fd_read(). In the imap process, fd_read succeeds but CHECK_CMSG(cmsg)
is false.
Neither defining BUGGY_CMSG_MACROS nor redefining CHECK_CMSG as for
LINUX20 resolved the problem; doing the latter caused read_fd to fill
out *fd with an invalid file number. Anyway, fdpass.c looks
substantially similar from 2.1 to 2.2 so perhaps the problem lies
elsewhere and this was a red herring.
[most information below pertains to the *working version*,
1:2.1.7-7+deb7u1]
-- Package-specific info:
dovecot configuration
-
# 2.1.7: /etc/dovecot/dovecot.conf
# OS: GNU/kFreeBSD 10.1-0-amd64 x86_64
auth_verbose = yes
debug_log_path = /tmp/dovecot.debug
disable_plaintext_auth = no
lda_mailbox_autocreate = yes
mail_location = maildir:~/Maildir
namespace inbox {
inbox = yes
location =
mailbox Drafts {
special_use = \Drafts
}
mailbox Junk {
special_use = \Junk
}
mailbox Sent {
special_use = \Sent
}
mailbox Sent Messages {
special_use = \Sent
}
mailbox Trash {
special_use = \Trash
}
prefix =
}
passdb {
args = failure_show_msg=yes
driver = pam
}
passdb {
args = /etc/dovecot/extra.passwd
driver = passwd-file
}
postmaster_address = postmas...@unpythonic.net
protocols = imap
ssl = required
ssl_cert = /etc/dovecot/ssl/dovecot.cert
ssl_key = /etc/dovecot/ssl/dovecot.key
userdb {
driver = passwd
}
userdb {
args = /etc/dovecot/extra.passwd
driver = passwd-file
}
verbose_ssl = yes
-- System Information:
Debian Release: 8.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 10.1-0-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages dovecot-core depends on:
ii adduser 3.113+nmu3
ii libbz2-1.0 1.0.6-7+b2
ii libc0.1 2.19-15
ii libpam-runtime 1.1.8-3.1
ii libpam0g1.1.8-3.1
ii libssl1.0.0 1.0.1k-1
ii openssl 1.0.1k-1
ii ucf 3.0030
ii zlib1g 1:1.2.8.dfsg-2+b1
dovecot-core recommends no packages.
Versions of packages dovecot-core suggests:
pn dovecot-gssapinone
ii dovecot-imapd 1:2.1.7-7+deb7u1
pn dovecot-ldap none
pn dovecot-lmtpd none
pn dovecot-managesieved none
pn dovecot-mysql none
pn dovecot-pgsql none
pn dovecot-pop3d none
pn dovecot-sieve none
pn dovecot-solr none
pn dovecot-sqlitenone
ii ntp 1:4.2.6.p5+dfsg-5
Versions of packages dovecot-core is related to:
ii dovecot-core [dovecot-common] 1:2.1.7-7+deb7u1
pn dovecot-dbgnone
pn dovecot-devnone
pn dovecot-gssapi none
ii dovecot-imapd 1:2.1.7-7+deb7u1
pn dovecot-ldap none
pn dovecot-lmtpd none
pn dovecot-managesieved none
pn dovecot-mysql none
pn dovecot-pgsql none
pn dovecot-pop3d none
pn dovecot-sieve none
pn dovecot-sqlite none
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150325132651.30624.15231.reportbug@localhost
Bug#779467: dpkg: start-stop-daemon sometimes exits with _cpu_tick_frequency: no such symbol on kFreeBSD
Package: dpkg Version: 1.17.23+local1 Severity: important Tags: patch On a Debian Jessie kFreeBSD system, start-stop-daemon sometimes exits with an odd error: $ sudo service nfsd restart start-stop-daemon: _cpu_tick_frequency: no such symbol The specific command invocation which was reliably printing the error for me was: # start-stop-daemon --stop --quiet --retry=USR1/30/KILL/5 --name nfsd start-stop-daemon: _cpu_tick_frequency: no such symbol This turns out to be due to file descriptor exhaustion due to calls to kvm_openfiles without balancing calls to kvm_close, which is fixed by the attached patch. -- System Information: Debian Release: 8.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 10.1-0-amd64 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages dpkg depends on: ii libbz2-1.0 1.0.6-7+b2 ii libc0.1 2.19-15 ii libkvm6 10.1~svn273304-1 ii liblzma55.1.1alpha+20120614-2+b3 ii tar 1.27.1-2+b1 ii zlib1g 1:1.2.8.dfsg-2+b1 dpkg recommends no packages. Versions of packages dpkg suggests: ii apt 1.0.9.6 -- no debconf information diff -Nru dpkg-1.17.23/debian/changelog dpkg-1.17.23+nmu1/debian/changelog --- dpkg-1.17.23/debian/changelog 2014-12-27 16:44:47.0 -0600 +++ dpkg-1.17.23+nmu1/debian/changelog 2015-02-28 17:56:33.0 -0600 @@ -1,3 +1,10 @@ +dpkg (1.17.23+nmu1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix kvm_open file descriptor leak + + -- jep...@communitycrops.org Sat, 28 Feb 2015 17:56:19 -0600 + dpkg (1.17.23) unstable; urgency=low [ Guillem Jover ] diff -Nru dpkg-1.17.23/utils/start-stop-daemon.c dpkg-1.17.23+nmu1/utils/start-stop-daemon.c --- dpkg-1.17.23/utils/start-stop-daemon.c 2014-12-13 16:07:23.0 -0600 +++ dpkg-1.17.23+nmu1/utils/start-stop-daemon.c 2015-02-28 18:05:26.0 -0600 @@ -1374,11 +1374,13 @@ char buf[_POSIX2_LINE_MAX]; char **pid_argv_p; char *start_argv_0_p, *end_argv_0_p; + bool result = false; kd = ssd_kvm_open(); + if(kd 0) return false; + kp = ssd_kvm_get_procs(kd, KERN_PROC_PID, pid, NULL); - if (kp == NULL) - return false; + if (kp == NULL) goto exit; pid_argv_p = kvm_getargv(kd, kp, argv_len); if (pid_argv_p == NULL) @@ -1403,9 +1405,12 @@ } if (stat(start_argv_0_p, sb) != 0) - return false; + goto exit; - return (sb.st_dev == esb-st_dev sb.st_ino == esb-st_ino); + result = (sb.st_dev == esb-st_dev sb.st_ino == esb-st_ino); +exit: + kvm_close(kd); + return result; } #endif @@ -1460,11 +1465,12 @@ kvm_t *kd; struct kinfo_proc *kp; pid_t proc_ppid; + int result = false; kd = ssd_kvm_open(); kp = ssd_kvm_get_procs(kd, KERN_PROC_PID, pid, NULL); if (kp == NULL) - return false; + goto exit; #if defined(OSFreeBSD) proc_ppid = kp-ki_ppid; @@ -1476,7 +1482,10 @@ proc_ppid = kp-kp_proc.p_ppid; #endif - return proc_ppid == ppid; + result = proc_ppid == ppid; +exit: + kvm_close(kd); + return result; } #endif @@ -1518,11 +1527,12 @@ kvm_t *kd; uid_t proc_uid; struct kinfo_proc *kp; + bool result = false; kd = ssd_kvm_open(); kp = ssd_kvm_get_procs(kd, KERN_PROC_PID, pid, NULL); if (kp == NULL) - return false; + goto exit; #if defined(OSFreeBSD) proc_uid = kp-ki_ruid; @@ -1535,10 +1544,13 @@ kvm_read(kd, (u_long)(kp-kp_proc.p_cred-p_ruid), proc_uid, sizeof(uid_t)); else - return false; + goto exit; #endif - return (proc_uid == (uid_t)uid); + result = (proc_uid == (uid_t)uid); +exit: + kvm_close(kd); + return result; } #endif @@ -1602,11 +1614,12 @@ kvm_t *kd; struct kinfo_proc *kp; char *process_name; + bool result = false; kd = ssd_kvm_open(); kp = ssd_kvm_get_procs(kd, KERN_PROC_PID, pid, NULL); if (kp == NULL) - return false; + goto exit; #if defined(OSFreeBSD) process_name = kp-ki_comm; @@ -1618,7 +1631,10 @@ process_name = kp-kp_proc.p_comm; #endif - return (strcmp(name, process_name) == 0); + result = (strcmp(name, process_name) == 0); +exit: + kvm_close(kd); + return result; } #endif
Re: Memory debugging tools for kFreeBSD
On Wed, Feb 11, 2015 at 05:36:16PM -0600, Jeff Epler wrote: Some time ago I prepared patches that allowed me to build and use [...] Adam, I tried to Cc: you on this response, but your mail server rejected the message: This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: ad...@zombino.com SMTP error from remote mail server after end of data: host mail.galsoft.net [88.198.34.156]: 554 5.7.0 Reject, id=01321-13 - spam and reviewing the message made me realize that I omitted the URL of the debian bug report I was referring to: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702729 I don't know whether this message will reach you either, but hey, I tried. Jeff -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150212130432.ga45...@unpythonic.net
Re: Memory debugging tools for kFreeBSD
Some time ago I prepared patches that allowed me to build and use valgrind on kFreeBSD. Unfortunately, this has not been incorporated into the Debian package. I feel like I still haven't managed to figure out how to effectively collaborate within the Debian project. I also have no idea whether the patch is still applicable to the current valgrind version. Jeff -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150211233615.ga13...@unpythonic.net
Re: Please help building bwa on freebsd [nore...@buildd.debian.org: failed kfreebsd-amd64 build of bwa 0.7.12-1]
On Debian kFreeBSD, uname -s says GNU/kFreeBSD. so perhaps you want a second stanza in the Makefile ifeq ($(shell uname -s),GNU/kFreeBSD) LIBS += -lrt endif Jeff -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150209130437.gf21...@unpythonic.net
Re: Please help building bwa on freebsd [nore...@buildd.debian.org: failed kfreebsd-amd64 build of bwa 0.7.12-1]
The solution may simply be to link with -lrt.
$ cat shmopen.c
#include sys/mman.h
#include stdio.h
int main() { printf(%p\n, shm_open); return 0; }
$ gcc shmopen.c
/tmp/ccRPQFME.o: In function `main':
shmopen.c:(.text+0x5): undefined reference to `shm_open'
collect2: error: ld returned 1 exit status
$ gcc shmopen.c -lrt ./a.out
0x400540
$ lsb_release -d
Description:Debian GNU/kFreeBSD 8.0 (jessie)
$ dpkg-query -S /usr/lib/x86_64-kfreebsd-gnu/librt.so
libc0.1-dev:kfreebsd-amd64: /usr/lib/x86_64-kfreebsd-gnu/librt.so
$ apt-cache policy libc0.1-dev | head -2
libc0.1-dev:
Installed: 2.19-13
Jeff
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150206142806.gd21...@unpythonic.net
Re: _PC_VDISABLE cpp problem
According to http://pubs.opengroup.org/onlinepubs/7908799/xsh/unistd.h.html _POSIX_VDISABLE is either undefined, or defined to a value other than -1. As far as I can tell, no text requires that it be defined to a valid *preprocessor* number. In fact, http://standards.ieee.org/findstds/interps/1003-1-90_int/pasc-1003.1-27.html states that Interpretation Response The standard does not require that _POSIX_VDISABLE be a preprocessor number. The standard does not require that _POSIX_VDISABLE be usable in numeric comparisons in the preprocessor. Therefore, I would change the check in ost.c to #if defined(_POSIX_VDISABLE) if defense against the forbidden integer value -1 is truly required because of some other POSIX-violating target platform, it must be done as a runtime test (though such an if() with a constant condition is likely to be optimized away by gcc under any nonzero optimization level) Jeff -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140606125327.ga34...@unpythonic.net
Re: NFS?
I have a kfreebsd (debian 7 / kernel 9.0) system serving zfs file systems over nfsv3 to linux (debian 7). It seems to work well, though there are some user reports of problems using Libre Office document recovery that I haven't looked into yet. I also failed to use nfsv4. I manually maintain /etc/exports. I think that is the only impact of the mountd isn't supported error. Jeff -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140520194105.ga9...@unpythonic.net
Re: Bug#628383: [kfreebsd-*] test failure: test-secmem
Apparently freebsd kernels 9.2 and later have security.bsd.unprivileged_mlock, which appears to default to permitted. http://www.freebsd.org/cgi/man.cgi?query=mlocksektion=2manpath=FreeBSD+9.2-RELEASE http://marc.info/?l=freebsd-archm=134617193210756 Is this test failure happening with kernel 9.2? I can't see that in the buildd logs. I only have a 9.0 kernel to test on... Jeff -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140518193803.ga61...@unpythonic.net
Re: Init system for non-Linux ports
I'm only a kFreeBSD user and don't have any official standing within the Debian project, but all the same my preferences are 614253 where 6. is the proposed alternative to switch to Upstart if Linux uses it, otherwise sysvinit. Jeff -- 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/20140129160233.gb12...@unpythonic.net
Re: Bug#736202: undeterministic output when running egrep repeatedly with the same input
Could it be http://www.freebsd.org/cgi/query-pr.cgi?pr=164445 ? It looks like that fix from reply 3 is not in kernel 9.0-10+deb70 which is what I'm running (but I have Wheezy userspace, so I haven't reproduced a problem either) Jeff -- 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/20140121023824.ga47...@unpythonic.net
Re: grub on ZRaid2
You might consider doing what I did: Make two zfs partitions per disk. Create a mirrored zpool from the first, smaller partitions; place files needed for booting there. Create a raidz(2) pool from the bigger partitions and use it for bulk storage. In fact, I've convinced myself that the additional redundancy in the boot pool is a feature. Jeff -- 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/20131022030552.ga2...@unpythonic.net
Bug#726664: radvd FTBFS on kfreebsd
Package: radvd Version: 1:1.9.1-1.1 Severity: normal Tags: patch Dear Maintainer, I noticed that the radvd package was unavailable on kfreebsd. 1.8.5-1 built just fine on my system, and works fine. When I pursued the problem, I found that it failed to build on the buildds. The reason that 1.9.1 fails is that the existing kfreebsd patch modifies configure.ac but configure is shipped and not rebuilt. The following patch makes it build on my mongrel (mostly stable) system, though I am not sufficiently conversant with debian packaging to know whether I've gotten all the details right: diff -Nru radvd-1.9.1/debian/changelog radvd-1.9.1/debian/changelog --- radvd-1.9.1/debian/changelog2013-06-07 04:10:07.0 -0500 +++ radvd-1.9.1/debian/changelog2013-10-17 15:38:34.0 -0500 @@ -1,3 +1,10 @@ +radvd (1:1.9.1-1.2) UNRELEASED; urgency=low + + * Non-maintainer upload. + * Use autoreconf, as the kfreebsd patch requires rebuilding configure + + -- Jeff Epler jep...@unpythonic.net Thu, 17 Oct 2013 15:38:15 -0500 + radvd (1:1.9.1-1.1) unstable; urgency=low * Non-maintainer upload with maintainer approval. diff -Nru radvd-1.9.1/debian/control radvd-1.9.1/debian/control --- radvd-1.9.1/debian/control 2013-06-07 04:10:38.0 -0500 +++ radvd-1.9.1/debian/control 2013-10-17 15:43:39.0 -0500 @@ -5,7 +5,8 @@ Standards-Version: 3.9.3 Build-Depends: autotools-dev, debhelper (= 9), flex, bison, pkg-config, - libdaemon-dev + libdaemon-dev, + dh-autoreconf Package: radvd Architecture: any diff -Nru radvd-1.9.1/debian/rules radvd-1.9.1/debian/rules --- radvd-1.9.1/debian/rules2013-06-07 04:11:26.0 -0500 +++ radvd-1.9.1/debian/rules2013-10-17 15:37:00.0 -0500 @@ -3,7 +3,7 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all %: - dh $@ + dh $@ --with autoreconf override_dh_autobuild: cp debian/copyright.in COPYRIGHT -- System Information: Debian Release: 7.1 APT prefers stable APT policy: (990, 'stable'), (1, 'experimental') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 9.0-2-amd64 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages radvd depends on: ii adduser 3.113+nmu3 ii libc0.1 2.13-38 radvd recommends no packages. radvd suggests no packages. -- no debconf information -- 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/20131017204829.27065.26988.reportbug@localhost
Re: This platform lacks a functioning sem_open implementation
On Thu, May 02, 2013 at 04:26:23PM +0200, Petr Salinger wrote:
Not really. We do not support named semaphores (sem_open),
but we do support (unnamed semaphores) (sem_init).
The named only functions returns ENOSYS.
In Wheezy on kfreebsd? The implementation of sem_open in
eglibc-2.13/linuxthreads/semaphore.c simply always returns ENOSYS.
(2.13-38)
193 sem_t *sem_open(const char *name, int oflag, ...)
194 {
195 __set_errno (ENOSYS);
196 return SEM_FAILED;
197 }
sem_open is the function checked by Python's configure.
Jeff
signature.asc
Description: Digital signature
Re: Bug#707733: pygobject: FTBFS on kfreebsd
OK, this seems crazy to me but I feel obliged to note it: When I build 3.8.1-3 in /usr/src or /tmp/wat, I can observe the failure when I subsequently 'make check' in build-2.7/tests. When I build it in /tmp or /tmp/wat/frugal-bonasfrarfsarfasrfasrf/pygobject-3.8.1 I do not. However, I also note that I never saw a hang in 3.8.2-1 under a variety of directory names. When either version complets the testsuite, there is an unexpected failure, though. == FAIL: test_main_loop (test_glib.TestGLib) -- Traceback (most recent call last): File /tmp/wat/pygobject-3.8.1/tests/test_glib.py, line 95, in test_main_loop self.assertFalse(context.iteration(False)) AssertionError: True is not false -- Ran 877 tests in 10.171s FAILED (failures=1, expected failures=4) Jeff signature.asc Description: Digital signature
Re: Bug#707733: pygobject: FTBFS on kfreebsd
valgrind (helgrind) on linux (sid amd64 chroot on wheezy amd64) didn't turn up anything that looked too useful. There were a number of diagnostics of this general form: ==12158== Lock at 0x603E5C0 was first observed ==12158==at 0x4C2EB32: pthread_mutex_init (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so) ==12158==by 0x6A644F6: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.1) ==12158==by 0x6A64594: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.1) ==12158==by 0x6A647C8: g_mutex_lock (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.1) ==12158==by 0x67BDA97: g_type_create_instance (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3600.1) ==12158==by 0x67A2757: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3600.1) ==12158==by 0x67A4210: g_object_newv (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3600.1) ==12158==by 0x67A485B: g_object_new (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3600.1) ==12158==by 0x6568A48: ??? (in /usr/lib/libgirepository-1.0.so.1.0.0) ==12158==by 0x6568F58: g_irepository_get_default (in /usr/lib/libgirepository-1.0.so.1.0.0) ==12158==by 0x633BEEF: _wrap_g_irepository_get_default (pygi-repository.c:72) ==12158==by 0x4B73E9: PyEval_EvalFrameEx (ceval.c:4005) ==12158== ==12158== Possible data race during read of size 4 at 0xD2C3910 by thread #3 ==12158== Locks held: none ==12158==at 0x6A64BA9: g_private_set (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.1) ==12158==by 0x6A48EF7: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.1) ==12158==by 0x4C2E93D: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so) ==12158==by 0x4E3DE0D: start_thread (pthread_create.c:311) ==12158== ==12158== This conflicts with a previous write of size 4 by thread #1 ==12158== Locks held: 1, at address 0x603E5C0 ==12158==at 0x67BD9E0: g_type_create_instance (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3600.1) ==12158==by 0x67A2757: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3600.1) ==12158==by 0x67A4210: g_object_newv (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3600.1) ==12158==by 0x67A485B: g_object_new (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3600.1) ==12158==by 0xC718EAA: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.400.2) ==12158==by 0x67BD93E: g_type_create_instance (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3600.1) ==12158==by 0x67A2757: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3600.1) ==12158==by 0x67A4210: g_object_newv (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3600.1) ==12158== ==12158== Address 0xD2C3910 is 0 bytes inside a block of size 4 alloc'd ==12158==at 0x4C2BEAB: malloc (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so) ==12158==by 0x6A6443D: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.1) ==12158==by 0x6A64BA8: g_private_set (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.1) ==12158==by 0x6A48EF7: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.1) ==12158==by 0x4C2E93D: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so) ==12158==by 0x4E3DE0D: start_thread (pthread_create.c:311) I don't know enough about the structure of glib to speculate as to whether this is expected or indicative of bad behavior. and some of this general form: ==12158== Thread #1: pthread_cond_destroy: destruction of unknown cond var ==12158==at 0x4C2D342: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so) ==12158==by 0x6A64A0B: g_cond_clear (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.1) ==12158==by 0x73670E8: ??? (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.3600.1) ==12158==by 0x67A2577: g_object_unref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3600.1) ==12158==by 0x6A21DD7: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.1) ==12158==by 0x6A22356: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.1) ==12158==by 0x6A24F6F: g_main_context_dispatch (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.1) ==12158==by 0x6A25267: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.1) ==12158==by 0x6A256D9: g_main_loop_run (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.1) ==12158==by 0xC8213B4: gtk_main (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.400.2) ==12158==by 0x7648E27: ffi_call_unix64 (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.1) ==12158==by 0x764878F: ffi_call (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.1) which may be a known bug in valgrind: https://bugs.kde.org/show_bug.cgi?id=307082 If it's not a valgrind false positive, I do believe pthread_cond_destroy on a cond variable already in an undefined state is undefined behavior (but I couldn't find chapter and verse, just e.g., reports like this one http://sourceware.org/bugzilla/show_bug.cgi?id=1473 where responders to the bug say it is undefined behavior). On the other hand, doing this in a simple
Re: Bug#707733: pygobject: FTBFS on kfreebsd
Another bug that may be similar: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671785 In that bug I remark that a problem with pthread_mutex_unlock can be observed on linux with valgrind --tool=helgrind. I haven't tried to determine whether it's a similar problem here, but it might be worth valgrinding it on Linux. (unfortunately I can't do this at the moment; if I get a chance I'll report the results here) Jeff signature.asc Description: Digital signature
Bug#705126: Tried but failed to reproduce
Since the reported trigger was an ssh flood, I tried ssh -T -o 'PreferredAuthentications hostbased' localhost (which on my system will result in a quick failed ssh because hostbased authentication is not enabled in the server) in a tight, parallelized loop with this construct: for i in `seq 10`; do echo localhost ; done \ | xargs -d '\n' -n1 -P8 --verbose sh -c \ ssh -T -o 'PreferredAuthentications hostbased' localhost || exit 1 The '|| exit 1' construct is needed because otherwise ssh exits with code 255, which causes xargs to stop running jobs. However, I did not encounter the kernel maxproc error during my test. My maxproc is the default as far as I'm aware: $ sysctl -a | grep maxproc kern.maxproc: 6164 kern.maxprocperuid: 5547 and it's very likely that my test is getting nowhere near this limit. kfreebsd-image-9-amd64: Installed: 9.0-10 Candidate: 9.0-10 Version table: *** 9.0-10 0 500 http://ftp.us.debian.org/debian/ wheezy/main kfreebsd-amd64 Packages 100 /var/lib/dpkg/status openssh-server: Installed: 1:6.0p1-4 Candidate: 1:6.0p1-4 Version table: 1:6.1p1-4 0 1 http://ftp.us.debian.org/debian/ experimental/main kfreebsd-amd64 Packages *** 1:6.0p1-4 0 500 http://ftp.us.debian.org/debian/ wheezy/main kfreebsd-amd64 Packages 100 /var/lib/dpkg/status libc0.1: Installed: 2.13-38 Candidate: 2.13-38 Version table: *** 2.13-38 0 500 http://ftp.us.debian.org/debian/ wheezy/main kfreebsd-amd64 Packages 100 /var/lib/dpkg/status Jeff signature.asc Description: Digital signature
Re: Bug#702729: valgrind: build on kfreebsd-amd64
On Thu, Mar 14, 2013 at 06:30:43PM +0100, Alessandro Ghedini wrote: I'll have a look as soon as I have some free time. I was also thinking that the patch may be applied only in the kfreebsd builds, so it wouldn't interfere with the linux builds. That sounds great, but I do not yet have the debian expertise to know how to express this in debian/rules (or whereever the appropriate location is) What did you do to see if the build actually works? I ran some very simple (certainly by comparison to iceweasel or libreoffice), non-interactive programs of my own. A simple stress-test for the MemCheck tool would be to run it on firefox/iceaweasel and libreoffice and see what happens. Unfortunately, firefox doesn't work, possibly due to an unimplemented syscall. --51670-- WARNING: unhandled syscall: 330 --51670-- You may be able to write your own handler. --51670-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --51670-- Nevertheless we consider this a bug. Please report --51670-- it at http://valgrind.org/support/bug_reports.html. this is apparently SYS_sched_getscheduler, so its dear neighbor SYS_sched_setscheduler will probably also need implementation. I'll try to devote some time to this item this weekend. Also, does it work on kfreebsd-i386 too? I have not tested this. I suspect it at least has the sysarch(I386_SET_GSBASE) problem in addition to any problems in the amd64 build. I don't have a kfreebsd-i386 installation at the moment, and due to some compile-time bug I encountered, the kfreebsd-amd64 build is 64bitonly. Anyway, as I mentioned on the debian-bsd list the real problem here is not really the patch itself, but finding someone willing to maintain it in the future (at least until it gets merged upstream) since I'm not qualified (nor really interested) in the kfreebsd ports. So would you be willing to continue to maintain the patch in the future? If so you are welcome to push your changes to the collab-maint git repository where valgrind is maintained [0] in a separate branch called, say, kfreebsd (possibily without the d/changelog changes). I have some level of committment to doing software development on debian-kfreebsd, and I find valgrind to be a useful tool. That being the case I have some stake in whether it works or not. I'm not yet a DD so I can't yet do things like push branches onto anonscm.debian.org, but it's becoming clear that I should go ahead and become one. I assume that for the moment it's appropriate to attach any updated patches to this bug report. If that's inappropriate, please let me know. Thanks, Jeff -- 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/20130315123010.gd4...@unpythonic.net
Bug#703061: mongodb: Enable building on kfreebsd
Source: mongodb
Version: 2.0.6-1
Severity: normal
Tags: upstream patch
Dear Maintainer,
I have modified mongodb so that it builds on kfreebsd-amd64 and probably
on kfreebsd-i386. I have not made serious use of this package yet, but
as I noticed tests are run during the package building process I guess
this provides some level of confidence in the result.
Please consider my patch for a future release of mongodb.
Thanks,
Jeff Epler jep...@unpythonic.net
-- System Information:
Debian Release: 7.0
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 9.0-2-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru mongodb-2.0.6/debian/changelog mongodb-2.0.6/debian/changelog
--- mongodb-2.0.6/debian/changelog 2012-06-05 12:53:16.0 -0500
+++ mongodb-2.0.6/debian/changelog 2013-03-14 14:21:56.0 -0500
@@ -1,3 +1,10 @@
+mongodb (1:2.0.6-1.1) UNRELEASED; urgency=low
+
+ * Non-maintainer upload.
+ * Enable building on kfreebsd-*
+
+ -- Jeff Epler jep...@unpythonic.net Thu, 14 Mar 2013 13:37:54 -0500
+
mongodb (1:2.0.6-1) unstable; urgency=low
* New upstream release 2.0.6
diff -Nru mongodb-2.0.6/debian/control mongodb-2.0.6/debian/control
--- mongodb-2.0.6/debian/control 2012-06-05 12:53:16.0 -0500
+++ mongodb-2.0.6/debian/control 2013-03-14 13:48:02.0 -0500
@@ -10,7 +10,7 @@
Homepage: http://www.mongodb.org
Package: mongodb
-Architecture: i386 amd64
+Architecture: i386 amd64 kfreebsd-i386 kfreebsd-amd64
Depends: mongodb-server, mongodb-dev, ${shlibs:Depends}, ${misc:Depends}
Description: object/document-oriented database (metapackage)
MongoDB is a high-performance, open source, schema-free
@@ -33,7 +33,7 @@
This is a metapackage that depends on all the mongodb parts.
Package: mongodb-server
-Architecture: i386 amd64
+Architecture: i386 amd64 kfreebsd-i386 kfreebsd-amd64
Depends: mongodb-clients, ${shlibs:Depends}, ${misc:Depends}, adduser
Replaces: mongodb (= 1:1.4.2-2)
Description: object/document-oriented database (server package)
@@ -57,7 +57,7 @@
This package contains the server itself.
Package: mongodb-clients
-Architecture: i386 amd64
+Architecture: i386 amd64 kfreebsd-i386 kfreebsd-amd64
Depends: ${shlibs:Depends}, ${misc:Depends}
Replaces: mongodb (= 1:1.4.2-2)
Description: object/document-oriented database (client apps)
@@ -82,7 +82,7 @@
Package: mongodb-dev
Section: libdevel
-Architecture: i386 amd64
+Architecture: i386 amd64 kfreebsd-i386 kfreebsd-amd64
Depends: libboost-dev, ${shlibs:Depends}, ${misc:Depends}
Suggests: mongodb-server
Replaces: mongodb (= 1:1.4.2-2)
diff -Nru mongodb-2.0.6/debian/patches/0004-enable-build-on-kfreebsd.patch mongodb-2.0.6/debian/patches/0004-enable-build-on-kfreebsd.patch
--- mongodb-2.0.6/debian/patches/0004-enable-build-on-kfreebsd.patch 1969-12-31 18:00:00.0 -0600
+++ mongodb-2.0.6/debian/patches/0004-enable-build-on-kfreebsd.patch 2013-03-14 14:21:19.0 -0500
@@ -0,0 +1,59 @@
+Subject: Enable build on kfreebsd
+Author: Jeff Epler jep...@unpythonic.net
+Forwarded: no
+
+Just a few things prevent mongodb from building and passing its
+smoketests on kfreebsd-amd64. Luckily enough, it seems that kfreebsd
+can be treated just like linux.
+
+--- a/SConstruct
b/SConstruct
+@@ -394,7 +394,7 @@
+
+ if os.path.exists( util/processinfo_ + os.sys.platform + .cpp ):
+ processInfoFiles += [ util/processinfo_ + os.sys.platform + .cpp ]
+-elif os.sys.platform == linux3:
++elif os.sys.platform in ('linux3', 'gnukfreebsd8', 'gnukfreebsd9'):
+ processInfoFiles += [ util/processinfo_linux2.cpp ]
+ else:
+ processInfoFiles += [ util/processinfo_none.cpp ]
+@@ -523,7 +523,7 @@
+ env.Append( CPPPATH=filterExists([/sw/include , /opt/local/include]) )
+ env.Append( LIBPATH=filterExists([/sw/lib/, /opt/local/lib]) )
+
+-elif linux2 == os.sys.platform or linux3 == os.sys.platform:
++elif os.sys.platform in ('linux2', 'linux3', 'gnukfreebsd8', 'gnukfreebsd9'):
+ linux = True
+ platform = linux
+
+--- a/distsrc/client/SConstruct
b/distsrc/client/SConstruct
+@@ -41,7 +41,7 @@
+ if darwin == os.sys.platform:
+ addExtraLibs( /opt/local/ )
+ nix = True
+-elif linux2 == os.sys.platform or linux3 == os.sys.platform:
++elif os.sys.platform in ('linux2', 'linux3', 'gnukfreebsd8', 'gnukfreebsd9'):
+ nix = True
+ linux = True
+
+--- a/db/nonce.cpp
b/db/nonce.cpp
+@@ -37,7 +37,7 @@
+ if( _initialized ) return;
+ _initialized = true;
+
+-#if defined(__linux__) || defined(__sunos__) || defined(__APPLE__)
++#if defined(__linux__) || defined(__sunos__) || defined(__APPLE__) || defined(__FreeBSD_kernel__)
+ _devrandom = new ifstream(/dev/urandom, ios::binary|ios::in);
+ massert( 10353 , can't open dev/urandom, _devrandom-is_open() );
+ #elif defined(_WIN32)
+@@ -55,7 +55,7 @@
+ nonce64
Re: Porting valgrind to Debian/kFreeBSD
It looks like freebsd9 ports has valgrind-snapshot which is based off of valgrind 3.8.0: http://cdn.bitbucket.org/stass/valgrind-freebsd/downloads/valgrind-freebsd-3.8.0.tar.bz2 There are a lot more changes than I would expect between this and the upstream 3.8.0 tarball: valgrind-3.8.0/FAQ.txt | 405 - valgrind-3.8.0/Makefile.all.am | 14 + valgrind-3.8.0/Makefile.am |1 + valgrind-3.8.0/Makefile.in | 262 +- valgrind-3.8.0/Makefile.tool.am| 22 + valgrind-3.8.0/Makefile.vex.in | 123 +- valgrind-3.8.0/README.android_emulator | 73 + valgrind-3.8.0/README_FREEBSD | 14 + valgrind-3.8.0/VEX/Makefile-gcc| 376 + valgrind-3.8.0/VEX/Makefile-icc| 261 + valgrind-3.8.0/VEX/TODO.txt| 55 + valgrind-3.8.0/VEX/nanoarm.orig| 19 + valgrind-3.8.0/VEX/orig_amd64/Compare.hs | 63 + valgrind-3.8.0/VEX/orig_amd64/SortedToOrig.hs | 29 + valgrind-3.8.0/VEX/orig_amd64/test1.orig | 5281 + valgrind-3.8.0/VEX/orig_amd64/test1.sorted | 1318 + valgrind-3.8.0/VEX/orig_amd64/test2.orig |23917 + valgrind-3.8.0/VEX/orig_amd64/test2.sorted | 5978 + valgrind-3.8.0/VEX/orig_arm/nanoarm|7 + valgrind-3.8.0/VEX/orig_arm/nanoarm.orig | 19 + valgrind-3.8.0/VEX/orig_ppc32/date.orig|138635 ++ valgrind-3.8.0/VEX/orig_ppc32/loadsafp.orig|22354 + valgrind-3.8.0/VEX/orig_ppc32/morefp.orig | 6944 + valgrind-3.8.0/VEX/orig_ppc32/return0.orig |60452 +++ valgrind-3.8.0/VEX/orig_x86/exit42.orig|12580 + valgrind-3.8.0/VEX/orig_x86/fpu_mmx_sse.orig |35448 ++ valgrind-3.8.0/VEX/orig_x86/manyfp.orig| 9635 + valgrind-3.8.0/VEX/pub/libvex_guest_offsets.h | 118 - valgrind-3.8.0/VEX/switchback/Makefile | 10 + valgrind-3.8.0/VEX/switchback/binary_switchback.pl | 431 + valgrind-3.8.0/VEX/switchback/linker.c | 1483 + valgrind-3.8.0/VEX/switchback/linker.h |5 + valgrind-3.8.0/VEX/switchback/switchback.c | 1170 + valgrind-3.8.0/VEX/switchback/test_bzip2.c | 6117 + valgrind-3.8.0/VEX/switchback/test_emfloat.c | 1944 + valgrind-3.8.0/VEX/switchback/test_hello.c | 20 + valgrind-3.8.0/VEX/switchback/test_ppc_jm1.c | 4613 + valgrind-3.8.0/VEX/switchback/test_simple.c| 12 + valgrind-3.8.0/VEX/test/fldenv.c | 32 + valgrind-3.8.0/VEX/test/fp1.c | 17 + valgrind-3.8.0/VEX/test/fp1.s | 52 + valgrind-3.8.0/VEX/test/fpconst.c | 77 + valgrind-3.8.0/VEX/test/fpgames.s | 103 + valgrind-3.8.0/VEX/test/fpspeed.c | 29 + valgrind-3.8.0/VEX/test/fpucw.c| 43 + valgrind-3.8.0/VEX/test/frstor.c | 82 + valgrind-3.8.0/VEX/test/fsave.c| 68 + valgrind-3.8.0/VEX/test/fstenv.c | 22 + valgrind-3.8.0/VEX/test/fxsave.c | 136 + valgrind-3.8.0/VEX/test/mmxtest.c | 605 + valgrind-3.8.0/VEX/test/mxcsr.c| 45 + valgrind-3.8.0/VEX/test/rounderr.c | 97 + valgrind-3.8.0/VEX/test/test-amd64-muldiv.h| 74 + valgrind-3.8.0/VEX/test/test-amd64-shift.h | 178 + valgrind-3.8.0/VEX/test/test-amd64.c | 1709 + valgrind-3.8.0/VEX/test/test-amd64.h | 227 + valgrind-3.8.0/VEX/test/test-i386-muldiv.h | 56 + valgrind-3.8.0/VEX/test/test-i386-shift.h | 161 + valgrind-3.8.0/VEX/test/test-i386.c| 1668 + valgrind-3.8.0/VEX/test/test-i386.h| 210 + valgrind-3.8.0/VEX/test/x87fxam.c | 44 + valgrind-3.8.0/VEX/test/x87tst.c | 27 + valgrind-3.8.0/VEX/test_main.c | 2716 + valgrind-3.8.0/VEX/test_main.h | 35 + valgrind-3.8.0/VEX/test_main.h.base| 35 + valgrind-3.8.0/VEX/unused/arena.h | 47 + valgrind-3.8.0/VEX/unused/dispatch.c | 97 + valgrind-3.8.0/VEX/unused/linker.c | 1422 + valgrind-3.8.0/VEX/useful/cpuid.c | 62 + valgrind-3.8.0/VEX/useful/fp_80_64.c | 636 + valgrind-3.8.0/VEX/useful/fpround.c| 13 + valgrind-3.8.0/VEX/useful/fspill.c | 19 + valgrind-3.8.0/VEX/useful/gradual_underflow.c | 15 + valgrind-3.8.0/VEX/useful/hd_fpu.c | 1707 + valgrind-3.8.0/VEX/useful/show_fp_state.c | 184 + valgrind-3.8.0/VEX/useful/smchash.c| 324 + valgrind-3.8.0/VEX/useful/x87_to_vex_and_back.c| 291 +
Re: Porting valgrind to Debian/kFreeBSD
I cleaned up the freebsd diffs, added some magic from this thread, and filed a debbug about it (702729). I'm not 100% confident it won't cause some debian/linux regression or that it's complete, but it's a step in the right direction, particularly as it builds off of the version of valgrind presently in unstable instead of an older version such as 3.5. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702729 Jeff -- 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/20130310195622.ga1...@unpythonic.net
Re: xfce, lightdm
On Wed, Mar 06, 2013 at 01:10:42PM -0600, Mark Johnson wrote: I used the kFreeBSD debian installer (wheezy RC1) and I installed the default desktop (xfce lightdm). Which is currently the most stable desktop: xfce, kde, gnome, etc? Lightdm is utilizing one of my cores at 100%. I saw this (lightdm @ 100% CPU) too, but didn't report it or look for an existing bug about it. I switched to slim as login manager and retained xfce as desktop. Jeff -- 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/20130307153531.ge31...@unpythonic.net
Re: Porting valgrind to Debian/kFreeBSD
Valgrind does appear to be aware of sysarch, implementing sysarch(AMD64_SET_FSBASE) in coregrind/m_syswrap/syswrap-amd64-freebsd.c. Jeff -- 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/20130307154038.gf31...@unpythonic.net
Re: Porting valgrind to Debian/kFreeBSD
On Thu, Mar 07, 2013 at 09:40:38AM -0600, Jeff Epler wrote:
Valgrind does appear to be aware of sysarch, implementing
sysarch(AMD64_SET_FSBASE) in
coregrind/m_syswrap/syswrap-amd64-freebsd.c.
Aha. eglibc is testing that the syscall succeeds, which is indicated by
setting RAX to 0.
/* do the syscall ourselves; the kernel never sees it */
SET_STATUS_Success2((ULong)*p, tst-arch.vex.guest_RDX );
+ SET_STATUS_Success2(0, tst-arch.vex.guest_RAX );
I was just able to get a useful valgrind run on my Debian/kFreeBSD amd64
system:
jepler@zaphod:/store/src/valgrind-freebsd$ ./vg-in-place ./a.out
==84159== Memcheck, a memory error detector
==84159== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==84159== Using Valgrind-3.8.0 and LibVEX; rerun with -h for copyright info
==84159== Command: ./a.out
==84159==
==84159== Invalid write of size 2
==84159==at 0x40055C: main (in /store/src/valgrind-freebsd/a.out)
==84159== Address 0x1556044 is 0 bytes after a block of size 4 alloc'd
==84159==at 0x10056CE: malloc (vg_replace_malloc.c:274)
==84159==by 0x40054D: main (in /store/src/valgrind-freebsd/a.out)
==84159==
==84159==
==84159== HEAP SUMMARY:
==84159== in use at exit: 4 bytes in 1 blocks
==84159== total heap usage: 1 allocs, 0 frees, 4 bytes allocated
==84159==
==84159== LEAK SUMMARY:
==84159==definitely lost: 4 bytes in 1 blocks
==84159==indirectly lost: 0 bytes in 0 blocks
==84159== possibly lost: 0 bytes in 0 blocks
==84159==still reachable: 0 bytes in 0 blocks
==84159== suppressed: 0 bytes in 0 blocks
==84159== Rerun with --leak-check=full to see details of leaked memory
==84159==
==84159== For counts of detected and suppressed errors, rerun with: -v
==84159== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 7 from 7)
This is very exciting!
Jeff
PS test program was
int main() {
char *buf = malloc(4);
strcpy(buf, hello);
return 0;
}
--
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/20130307155629.gg31...@unpythonic.net
Re: Porting valgrind to Debian/kFreeBSD
On Thu, Mar 07, 2013 at 05:49:55PM +0100, Petr Salinger wrote: Valgrind does appear to be aware of sysarch, implementing sysarch(AMD64_SET_FSBASE) in coregrind/m_syswrap/syswrap-amd64-freebsd.c. Aha. eglibc is testing that the syscall succeeds, which is indicated by setting RAX to 0. The standard kernel in a success case sets RAX to zero and clears carry flag. In error case the carry flag is set and RAX contains error number. It probably should be SET_STATUS_Success2((0L, tst-arch.vex.guest_RDX ); As you suggest, this change also works (replacement of my earlier change, not cumulative with it): - SET_STATUS_Success2((ULong)*p, tst-arch.vex.guest_RDX ); + SET_STATUS_Success2(0, tst-arch.vex.guest_RDX ); Jeff -- 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/20130307185153.gh31...@unpythonic.net
Re: Bug#701832: doxygen consistently segfaults on kfreebsd-i386 when building opendnssec documentation
On Sun, Mar 03, 2013 at 12:20:57PM +, Steven Chamberlain wrote:
#5 0x000800d21f2c in *__GI___libc_free (mem=optimized out) at
malloc.c:3736
ar_ptr = 0x800ff3240
p = optimized out
#6 0x000800844a79 in gvFreeContext () from /usr/lib/libgvc.so.5
No symbol table info available.
#7 0x00400fd8 in ?? ()
No symbol table info available.
#8 0x00080389bf04 in __pthread_sighandler
As many of you are probably aware, it's not permitted in POSIX to call free()
in signal handler context without some additional guarantees about what the
interrupted function may be.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html
(search for async-signal-safe)
It looks like this is what will happen when sending ctrl-c, though.
That's why a hang can be provoked in this way.
static void intr(int s)
{
/* if interrupted we try to produce a partial rendering before exiting */
if (G)
gvRenderJobs(Gvc, G);
/* Note that we don't call gvFinalize() so that we don't start event-driven
* devices like -Tgtk or -Txlib */
exit (gvFreeContext(Gvc));
}
... and in main():
signal(SIGINT, intr);
for that matter, whatever gvRenderJobs is intended to do is likely hard
to guarantee to be only doing async-signal-safe things (let alone things that
are data-structure safe). Indeed, I got a sigsegv when sending SIGINT exactly
when the first free inside gvLayoutJobs is holding the lock:
Breakpoint 3, 0x000800843b50 in gvLayoutJobs () from /usr/lib/libgvc.so.5
(gdb) ena 2
(gdb) c
Continuing.
Breakpoint 2, *__GI___libc_free (mem=0x61d940) at malloc.c:3736
3736in malloc.c
(gdb) signal 2
Continuing with signal SIGINT.
Program received signal SIGSEGV, Segmentation fault.
0x000800867778 in ?? () from /usr/lib/libgvc.so.5
(gdb) where
#0 0x000800867778 in ?? () from /usr/lib/libgvc.so.5
#1 0x000800870811 in ?? () from /usr/lib/libgvc.so.5
#2 0x000800873efd in emit_graph () from /usr/lib/libgvc.so.5
#3 0x000800875c9a in gvRenderJobs () from /usr/lib/libgvc.so.5
#4 0x00400fcc in ?? ()
#5 0x00080389bf04 in __pthread_sighandler (signo=6550134, _code=0,
_sg=0x80063f276, ctx=0xa) at sighandler.c:39
#6 0x7083 in ?? ()
#7 0x00080389be60 in ?? () at internals.h:545
from /lib/x86_64-kfreebsd-gnu/libpthread.so.0
#8 0x in ?? ()
possibly getting the segv is more common than the hang? I haven't managed to
get the hang once using this break-and-signal-in-gdb methodology (amd64
kfreebsd sid/wheezy).
Jeff
--
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/20130305032640.gd31...@unpythonic.net
Re: some support for debugging threads in gdb on kfreebsd
On Thu, Feb 28, 2013 at 01:20:18PM -0800, Christoph Egger wrote: If Jeff doesn't submit it to gdb mainline himself, I'll take care of that as a kFreeBSD Porter. Thank you. Jeff -- 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/20130302155723.gb31...@unpythonic.net
Re: some support for debugging threads in gdb on kfreebsd
On Mon, Feb 04, 2013 at 03:00:14PM -0800, Christoph Egger wrote:
Hi!
Thanks for your patch. However gdb with the patch applied dies for me:
I must have attached a wrong patch, or you're applying it to a different gdb.
(I started with 7.4.1-3)
It looks like you're probably dying here, but in my gdb source tree the message
is on a different line:
692 void
693 _initialize_signals (void)
694 {
695 if (strcmp (signals[TARGET_SIGNAL_LAST].string, TARGET_SIGNAL_MAGIC) !=
0)
696 internal_error (__FILE__, __LINE__, failed internal consistency
check);
697 }
In the patch I sent I don't think I could have disturbed
TARGET_SIGNAL_LAST/TARGET_SIGNAL_MAGIC (no entries were added or removed from
signals.def)..
Anyway, sorry it didn't work out for you. If I discover anything further I'll
be sure to note it on-list.
Jeff
--
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/20130204232443.gc18...@unpythonic.net
Re: libvirt build failure on kfreebsd
It looks like the problem is the value of MAXHOSTNAMELEN from
sys/param.h--this program prints 64 on linux but 256 on kfreebsd:
#include sys/param.h
#include fcntl.h
#include stdio.h
int main() {
printf(%d\n, (int) MAXHOSTNAMELEN);
return 0;
}
As you can see, the structure sizes won't work out if MAXHOSTNAMELEN is
256...
So I'd first try unconditionally defining MAXHOSTNAMELEN to 64.
Jeff
--
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/20130203213702.ga18...@unpythonic.net
Re: Bug#698102: eglibc: initgroups changes egid on kfreebsd
Michael, For now it sounds like there's no consensus that this is a bug in initgroups(3) in eglibc or setgroups(2) in kfreebsd. If you're aware of this leading to a bug in a specific Debian package (particularly if it is a bug with a security impact), please file a bug against that package. Jeff -- 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/20130130032258.ga6...@unpythonic.net
Re: debugging with gdb - Program received signal 32, LinuxThreads restart signal.
On Mon, Jan 14, 2013 at 04:46:39PM -0800, Christoph Egger wrote: (gdb) run Program received signal 32, LinuxThreads restart signal. __pthread_sigsuspend () at ../ports/sysdeps/unix/bsd/bsd4.4/kfreebsd/linuxthreads/pt-sigsuspend.S:24 24 ../ports/sysdeps/unix/bsd/bsd4.4/kfreebsd/linuxthreads/pt-sigsuspend.S: No such file or directory. (gdb) c warning: Signal 32 does not exist on this system. I've see this myself and reported it at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698200 I have an initial patch which at least prevents the debugged program hanging after 'continue' but is probably not really complete as it doesn't make it possible to direct the debugger to not stop for these signals. Jeff -- 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/20130115155253.ga14...@unpythonic.net
some support for debugging threads in gdb on kfreebsd
This is not yet complete or debugged, but it improves things.
The signals.c patch makes gdb not be confused by the signals that
LinuxThreads(sic) uses internally; you can even 'handle LTRESTART
nostop' if you prefer (you probably do so prefer). This is a slightly
different version of a patch that I attached to bug #698200 in that it
gives these signals names that you can pass to 'handle' (the numbers
didn't work)
Even so, this doesn't make 'info threads' work. That's what the
inf-ptrace.c patch does. Unfortunately, the main thread is listed twice
and I haven't found out how to avoid that yet. Also, it makes me wonder
why PT_LWPINFO and friends are commented out in sys/ptrace.h; they
seem to work just fine. Also, this may belong in amd64bsd-nat.c or some
other more system-specific file than inf-ptrace.c.
And this doesn't make the 'thread' command work, either. For that to
work, it's necessary to use the TID (instead of the PID) in many (most?
all?) ptrace calls. The middle patch, to amd64bsd-nat.c, does this
enough to make 'thread 2' and 'thread apply all bt' work.
The main problems I've observed so far are the dual-listing of the main
thread, and a repeatable crash when listing threads when not in the main
thread:
(gdb) thread 2
[Switching to thread 2 (process 15205)]
#0 syscall () at
../ports/sysdeps/unix/bsd/bsd4.4/kfreebsd/x86_64/syscall.S:27
27 ../ports/sysdeps/unix/bsd/bsd4.4/kfreebsd/x86_64/syscall.S: No such
file or directory.
(gdb) info threads
Program received signal SIGSEGV, Segmentation fault.
0x004efdf1 in add_thread_object (tp=0x10720a0)
at /store/src/gdb-7.4.1/gdb/python/py-inferior.c:247
247 entry-next = inf_obj-threads;
(top-gdb)
I don't know what this is about yet, but it seems to mean that debugging
threads is likely to still be a minefield.
oh, and I just noticed another oddity, threads don't become known until
you 'info thread':
(gdb) thread 2
Thread ID 2 not known.
(gdb) info thread
[New process 19492]
[New process 19492]
[New process 19492]
Id Target Id Frame
4process 19492 __pthread_sigsuspend () at
../ports/sysdeps/unix/bsd/bsd4.4/kfreebsd/linuxthreads/pt-sigsuspend.S:24
3process 19492 0x000800b083e9 in poll () at
../sysdeps/unix/syscall-template.S:82
2process 19492 pthread_start_thread (arg=0x6041a0) at
manager.c:260
* 1process 19492 __pthread_sigsuspend () at
../ports/sysdeps/unix/bsd/bsd4.4/kfreebsd/linuxthreads/pt-sigsuspend.S:24
(gdb) thread 2
[Switching to thread 2 (process 19492)]
... hmmm
Anyway, the patches (against gdb-7.4.1-3) (phew, the same in sid, so I
haven't been wasting my time.. I forgot to check until now):
--- a/gdb/common/signals.c
+++ b/gdb/common/signals.c
@@ -600,6 +600,15 @@
return SIGINFO;
#endif
+#if defined(__GLIBC__) defined(__FreeBSD_kernel__)
+case TARGET_SIGNAL_LINUXTHREADS_RESTART:
+ return 32;
+case TARGET_SIGNAL_LINUXTHREADS_CANCEL:
+ return 33;
+case TARGET_SIGNAL_LINUXTHREADS_DEBUG:
+ return 34;
+#endif
+
default:
#if defined (REALTIME_LO)
retsig = 0;
--- a/include/gdb/signals.def
+++ b/include/gdb/signals.def
@@ -194,9 +194,9 @@
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)
+SET (TARGET_SIGNAL_LINUXTHREADS_RESTART, 151, LTRESTART, LinuxThreads
restart signal)
+SET (TARGET_SIGNAL_LINUXTHREADS_CANCEL, 152, LTCANCEL, LinuxThreads cancel
signal)
+SET (TARGET_SIGNAL_LINUXTHREADS_DEBUG, 153, LTDEBUG, LinuxThreads debug
signal)
/* If you are adding a new signal, add it just above this comment. */
--- a/gdb/amd64bsd-nat.c
+++ b/gdb/amd64bsd-nat.c
@@ -35,6 +35,8 @@
#include inf-ptrace.h
+#define TPIDGET(x) (TIDGET(x) ? TIDGET(x) : PIDGET(x))
+
/* Fetch register REGNUM from the inferior. If REGNUM is -1, do this
for all registers (including the floating-point registers). */
@@ -48,7 +50,7 @@
{
struct reg regs;
- if (ptrace (PT_GETREGS, PIDGET (inferior_ptid),
+ if (ptrace (PT_GETREGS, TPIDGET (inferior_ptid),
(PTRACE_TYPE_ARG3) regs, 0) == -1)
perror_with_name (_(Couldn't get registers));
@@ -61,7 +63,7 @@
{
struct fpreg fpregs;
- if (ptrace (PT_GETFPREGS, PIDGET (inferior_ptid),
+ if (ptrace (PT_GETFPREGS, TPIDGET (inferior_ptid),
(PTRACE_TYPE_ARG3) fpregs, 0) == -1)
perror_with_name (_(Couldn't get floating point status));
@@ -82,13 +84,13 @@
{
struct reg regs;
- if (ptrace (PT_GETREGS, PIDGET (inferior_ptid),
+ if (ptrace (PT_GETREGS,
Bug#698199: freebsd-utils: kdump incorrectly prints delivery of signals = 32
Package: freebsd-utils
Version: 9.0+ds1-9
Severity: normal
Tags: patch
Dear Maintainer,
While yak shaving, I noticed that kdumping the progress of a pthreads program
printed things like
25935 a.outPSIG SIG(null) caught
when the signal number was 32 or 33. The attached patch fixes the immediate
problem, though it might be preferable to show the names of these signals.
-- System Information:
Debian Release: 7.0
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 9.0-2-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages freebsd-utils depends on:
ii libbsd0 0.4.2-1
ii libc0.1 2.13-37
ii libcam6 9.0+ds1-4
ii libgeom19.0+ds1-4
ii libjail19.0+ds1-4
ii libkiconv4 9.0+ds1-4
ii libkvm0 9.0+ds1-4
ii libsbuf69.0+ds1-4
ii libtirpc1 0.2.2-5
ii lsb-base4.1+Debian8
ii zlib1g 1:1.2.7.dfsg-13
freebsd-utils recommends no packages.
Versions of packages freebsd-utils suggests:
pn freebsd-hackedutils none
ii kbdcontrol 9.0+ds1-9
ii vidcontrol 9.0+ds1-9
-- no debconf information
diff -Nru freebsd-utils-9.0+ds1/debian/changelog freebsd-utils-9.0+ds1/debian/changelog
--- freebsd-utils-9.0+ds1/debian/changelog 2012-12-29 18:08:30.0 -0600
+++ freebsd-utils-9.0+ds1/debian/changelog 2013-01-14 20:45:07.0 -0600
@@ -1,3 +1,10 @@
+freebsd-utils (9.0+ds1-9.1) UNRELEASED; urgency=low
+
+ * Non-maintainer upload.
+ * Improve reporting of signals = 32
+
+ -- Jeff Epler jepler@localhost Mon, 14 Jan 2013 20:44:54 -0600
+
freebsd-utils (9.0+ds1-9) unstable; urgency=low
[ Steven Chamberlain ]
diff -Nru freebsd-utils-9.0+ds1/debian/patches/series freebsd-utils-9.0+ds1/debian/patches/series
--- freebsd-utils-9.0+ds1/debian/patches/series 2012-12-29 18:10:18.0 -0600
+++ freebsd-utils-9.0+ds1/debian/patches/series 2013-01-14 20:34:34.0 -0600
@@ -49,3 +49,4 @@
045_implicit-declaration.diff
devd_link_c++_statically.diff
stablerestart-fhs-compliance.diff
+signames.diff
diff -Nru freebsd-utils-9.0+ds1/debian/patches/signames.diff freebsd-utils-9.0+ds1/debian/patches/signames.diff
--- freebsd-utils-9.0+ds1/debian/patches/signames.diff 1969-12-31 18:00:00.0 -0600
+++ freebsd-utils-9.0+ds1/debian/patches/signames.diff 2013-01-14 20:40:55.0 -0600
@@ -0,0 +1,26 @@
+When tracing pthreads programs, kdump prints messages like
+ 25935 a.outPSIG SIG(null) caught ...
+this is actually signal 32, which is used internally by the LinuxThreads
+implementation. Signal 33 is also used, which is beyond the signames[]
+array's limit. Instead of relying on a relationship between NSIG and
+signames[], use the size of the signames array as the limit.
+
+--- a/usr.bin/kdump/kdump.c
b/usr.bin/kdump/kdump.c
+@@ -1128,13 +1128,14 @@
+ PIPE, ALRM, TERM, URG, STOP, TSTP, /* 13 - 18 */
+ CONT, CHLD, TTIN, TTOU, IO, XCPU, /* 19 - 24 */
+ XFSZ, VTALRM, PROF, WINCH, 29, USR1, /* 25 - 30 */
+- USR2, NULL, /* 31 - 32 */
++ USR2, /* 31 */
+ };
++#define NSIGNAMES (sizeof(signames) / sizeof(signames[0]))
+
+ void
+ ktrpsig(struct ktr_psig *psig)
+ {
+- if (psig-signo 0 psig-signo NSIG)
++ if (psig-signo 0 psig-signo NSIGNAMES)
+ (void)printf(SIG%s , signames[psig-signo]);
+ else
+ (void)printf(SIG %d , psig-signo);
Re: Workaround for kFreeBSD crash in reportbug
On Sun, Dec 30, 2012 at 05:34:10PM -0800, Christoph Egger wrote: However, I still believe that the problem is either in python-gtk2 or python-gtk2's FAQ advice on how to use gtk.gdk.threads_init(). Can you be a bit more verbose about that? Also the FAQ might well be right and what we are seeing yet another bug in kfreebsd's pthread implementation. My diagnosis that this is a pygtk bug rather than a kfreebsd bug basically boils down to the fact that on linux, helgrind is giving a diagnostic at the very place that kfreebsd is crashing. Basically, after gdk_enable_threads(), any gtk call must be made with the global lock held (gdk_threads_enter()). In the case of gtk_main(), it very soon calls gtk_threads_leave(), which is the spot where a not-locked pthread mutex is unlocked. That being the case, I suspect that the pygtk faq item is just omitting the gtk.gdk.threads_enter() call before gtk_main for the sake of brevity (but maybe because the error passes silently on Linux). But whether that is the case or not, pygtk really can't impose the additional requirement on users of raw_input() that they have to manipulate a gdk lock before the call; whatever it's doing had better be transparent to users of raw_input. However, on reading the glibc and posix manpages on pthread_mutex_unlock, it should simply return nonzero and set errno to EPERM in the case of unlocking a not-locked mutex, so it is probably equally sensible to pursue this as a bug in the pthreads implementation in debian kfreebsd's userspace... Unfortunately, I've failed to distill what I think gtk is doing into a simple program that segfaults on kfreebsd. Jeff -- 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/20121231022130.ga7...@unpythonic.net
Re: Bug#685625: libgeom: may cause segfault of grub-probe
If it's a question of minimal impact to fix the specific crash that
grub-probe encounters, then there are two more minimal ways to fix this
specific problem that come to mind:
replace reallocf with realloc---but in the unlikely case that realloc
fails, it doesn't deallocate the argument (this is the point of
reallocf)
explicitly declare reallocf instead of using the bsd/ header:
void *reallocf(void *, size_t)
however, I don't think either of these is better than the approach I
originally proposed, to add a #include directive that matches the one in
the reallocf manpage that debian ships.
(dropping the -Werror= flag addition would of course make it a bit more
minimal; it might avoid an FTBFS in the future, but if it's an FTBFS
that would point right at another crashing bug, well, it might be a
bonus rather than a detriment to FTBFS)
Being unfamiliar with the culture and practices of Debian, I can't speak
to whether a more invasive ('overlay') approach is appropriate or not in
light of the present freeze, but it seems that Guillem Jover has
concerns about doing that at this moment.
The machine where I originally encountered the trouble isn't yet in
production, so if there's an alternate fix proposed soon I'll be happy
to test it out. On the other hand, I think the presence or absence of
the implicit declaration warning is enough to indicate whether the bug
is present under any given fix...
Jeff
--
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/20121229154328.ga13...@unpythonic.net
Workaround for kFreeBSD crash in reportbug
This patch lets me start reportbug's text ui. It sidesteps the python-gtk2 problem with readline and threads by requesting that the readline hook be uninstalled. However, I still believe that the problem is either in python-gtk2 or python-gtk2's FAQ advice on how to use gtk.gdk.threads_init(). diff -Nru reportbug-6.4.3/debian/changelog reportbug-6.4.3+nmu1/debian/changelog --- reportbug-6.4.3/debian/changelog2012-08-18 15:50:08.0 -0500 +++ reportbug-6.4.3+nmu1/debian/changelog 2012-12-22 10:38:40.0 -0600 @@ -1,3 +1,11 @@ +reportbug (6.4.3+nmu1) UNRELEASED; urgency=low + + * Non-maintainer upload. + * Avoid a kFreeBSD crash by telling python-gtk not to hook readline +Closes: #671785 + + -- Jeff Epler jepler@localhost Sat, 22 Dec 2012 10:35:25 -0600 + reportbug (6.4.3) unstable; urgency=low * reportbug/debbugs.py diff -Nru reportbug-6.4.3/reportbug/ui/gtk2_ui.py reportbug-6.4.3+nmu1/reportbug/ui/gtk2_ui.py --- reportbug-6.4.3/reportbug/ui/gtk2_ui.py 2012-08-18 15:50:08.0 -0500 +++ reportbug-6.4.3+nmu1/reportbug/ui/gtk2_ui.py2012-12-22 10:35:19.0 -0600 @@ -35,6 +35,7 @@ except: has_spell = False +gtk.set_interactive (0) gtk.gdk.threads_init () import sys -- 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/20121222173709.gl13...@unpythonic.net
Bug#685625: implicit declaration of function ‘reallocf’
It looks like this is the problem, and it exists repeatedly in freebsd-libs-9.0+ds1-7 geom_getxml.c: In function ‘geom_getxml’: geom_getxml.c:59:2: warning: implicit declaration of function ‘reallocf’ [-Wimplicit-function-declaration] geom_getxml.c:59:2: warning: return makes pointer from integer without a cast [enabled by default] On kfreebsd-amd64 systems, the consequence of this is that the top 32 bits of a pointer returned by reallocf are discarded. In fact, adding this include appears to fix the specific crash in grub-probe: #include string.h +#include bsd/stdlib.h Based on this information, I hope to be able to submit a patch soon. Jeff -- 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/20121221184507.gf13...@unpythonic.net
Bug#685625: [PATCH] Re: Bug#685625: implicit declaration of function ‘reallocf’
Control: tags -1 + patch I believe the attached patch fixes the problem; it does on my system. Because the impact of this bug is the inability to install or update the bootloader (including, potentially, during initial installation), I believe the severity should be increased to critical. However, I am not modifying the priority myself as I'm not yet familiar with the culture around changing bug severity, particularly when escalating it. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 9.0-2-amd64 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libgeom1 depends on: ii libbsd00.4.2-1 ii libc0.12.13-37 ii libexpat1 2.1.0-1 ii libsbuf6 9.0+ds1-3 libgeom1 recommends no packages. libgeom1 suggests no packages. -- no debconf information diff -Nru freebsd-libs-9.0+ds1/debian/changelog freebsd-libs-9.0+ds1/debian/changelog --- freebsd-libs-9.0+ds1/debian/changelog 2012-05-25 11:37:58.0 -0500 +++ freebsd-libs-9.0+ds1/debian/changelog 2012-12-21 13:21:53.0 -0600 @@ -1,3 +1,13 @@ +freebsd-libs (9.0+ds1-3.1) UNRELEASED; urgency=low + + * Non-maintainer upload. + * Fix 'warning: implicit declaration of function 'reallocf' +(and several other functions) (Closes: 685625) + * Make that warning an error so that it does not pass silently +in the future + + -- Jeff Epler jep...@unpythonic.net Fri, 21 Dec 2012 13:20:44 -0600 + freebsd-libs (9.0+ds1-3) unstable; urgency=low [ Robert Millan ] diff -Nru freebsd-libs-9.0+ds1/debian/patches/implicit-declaration freebsd-libs-9.0+ds1/debian/patches/implicit-declaration --- freebsd-libs-9.0+ds1/debian/patches/implicit-declaration1969-12-31 18:00:00.0 -0600 +++ freebsd-libs-9.0+ds1/debian/patches/implicit-declaration2012-12-21 13:26:04.0 -0600 @@ -0,0 +1,70 @@ +Description: Fix crashes due to undeclared functions + The consequence of at least one of these (in geom_getxml.c) was a crash + when there was a lot of data in kern.geom.confdml. + . + freebsd-libs (9.0+ds1-3.1) UNRELEASED; urgency=low + . + * Fix 'warning: implicit declaration of function 'reallocf' + (and several other functions) (Closes: 685625) +Author: Jeff Epler jep...@unpythonic.net +Bug-Debian: http://bugs.debian.org/685625 + +--- +The information above should follow the Patch Tagging Guidelines, please +checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here +are templates for supplementary fields that you might want to add: + +Forwarded: no +Last-Update: 2012-12-21 + +--- freebsd-libs-9.0+ds1.orig/lib/libdevstat/devstat.c freebsd-libs-9.0+ds1/lib/libdevstat/devstat.c +@@ -34,6 +34,7 @@ __FBSDID($FreeBSD$); + #include sys/errno.h + #include sys/resource.h + #include sys/queue.h ++#include bsd/stdlib.h + + #include ctype.h + #include err.h +--- freebsd-libs-9.0+ds1.orig/lib/libusbhid/usage.c freebsd-libs-9.0+ds1/lib/libusbhid/usage.c +@@ -36,6 +36,7 @@ __FBSDID($FreeBSD$); + #include stdio.h + #include stdlib.h + #include string.h ++#include bsd/stdio.h + + #include usbhid.h + +--- freebsd-libs-9.0+ds1.orig/lib/libgeom/geom_ctl.c freebsd-libs-9.0+ds1/lib/libgeom/geom_ctl.c +@@ -39,6 +39,7 @@ + #include string.h + #include stdlib.h + #include paths.h ++#include bsd/stdlib.h + + #include sys/queue.h + +--- freebsd-libs-9.0+ds1.orig/lib/libgeom/geom_getxml.c freebsd-libs-9.0+ds1/lib/libgeom/geom_getxml.c +@@ -33,6 +33,8 @@ + #include sys/sysctl.h + #include stdlib.h + #include string.h ++#include bsd/stdlib.h ++ + #include libgeom.h + + char * +--- freebsd-libs-9.0+ds1.orig/sys/netinet/libalias/alias_db.c freebsd-libs-9.0+ds1/sys/netinet/libalias/alias_db.c +@@ -157,6 +157,7 @@ __FBSDID($FreeBSD$); + #include sys/errno.h + #include sys/time.h + #include unistd.h ++#include bsd/stdlib.h + #endif + + #include sys/socket.h diff -Nru freebsd-libs-9.0+ds1/debian/patches/series freebsd-libs-9.0+ds1/debian/patches/series --- freebsd-libs-9.0+ds1/debian/patches/series 2012-05-19 07:26:07.0 -0500 +++ freebsd-libs-9.0+ds1/debian/patches/series 2012-12-21 13:23:09.0 -0600 @@ -18,3 +18,4 @@ libusb_backward.diff libbsd_nlist.diff kvm_size_t_kludge.diff +implicit-declaration diff -Nru freebsd-libs-9.0+ds1/debian/rules freebsd-libs-9.0+ds1/debian/rules --- freebsd-libs-9.0+ds1/debian/rules 2012-05-25 11:34:52.0 -0500 +++ freebsd-libs-9.0+ds1/debian/rules 2012-12-21 12:44:17.0 -0600 @@ -18,7 +18,8 @@ revision := $(shell echo $(full_version) | sed -e 's/^[^+-]*//g') CFLAGS = -Wall -g -pipe -fPIC -I. -I$(CURDIR)/sys -D_GNU_SOURCE \ - -D__va_list=__builtin_va_list + -D__va_list=__builtin_va_list \ +-Werror=implicit-function-declaration ifneq (,$(filter noopt,$(DEB_BUILD_OPTIONS))) CFLAGS += -O0
Re: Bug#685625: implicit declaration of function ‘reallocf’
[snipped astute observations about the size of the xml data being important] On Fri, Dec 21, 2012 at 10:02:45PM +, Steven Chamberlain wrote: And I'm worried about some of the other packages mentioned, where the error shows on kfreebsd-* or maybe hurd-*, but not on other arches. Should they really all be doing this: ++#include bsd/stdlib.h Or should we be trying to fix this elsewhere, in GNU/kFreeBSD headers maybe? I don't know the right fix. I chose to #include bsd/stdlib.h because the manpage (on debian-kFreeBSD) lists that as the proper header: debian-kFreeBSD$ man reallocf MALLOC(3)BSD Library Functions ManualMALLOC(3) NAME reallocf — general purpose memory allocation functions LIBRARY Utility functions from BSD systems (libbsd, -lbsd) SYNOPSIS #include bsd/stdlib.h void * reallocf(void *ptr, size_t size); I notice now that the guidance in the FreeBSD project's manpage is to simply include stdlib.h for the declaration of reallocf: http://www.freebsd.org/cgi/man.cgi?query=reallocf Unless you were going to put reallocf in eglibc I don't think you want it in stdlib.h, since on debian-kFreeBSD use of reallocf will result in a link error without -lbsd. You can't simply make the bsd header be included via #include stdlib.h, as -I/usr/include/bsd on the gcc commandline leads to a recursive inclusion error. Jeff -- 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/20121221225848.gi13...@unpythonic.net
Treat adaN devices as SCSI (cam) devices; improve detection
Control: tags -1 + patch
As noted earlier, the problem is that devices like ada0 are
incorrectly being treated as IDE devices (ad0), not SCSI (cam) devices
(da0); subsequent ioctls specific to IDE devices (such as IOCATAGPARM)
would fail.
I believe the attached change (debdiff) resolves the problem.
I only tested on an installed system, but believe it would equally well
fix the problem as seen in the installer.
However, I do not have any true scsi devices to test it on, nor do I
have a freebsd 8 kernel to test it on (reportedly, the problem I'm
solving occurs only on the freebsd 9 kernel)
Also, I experienced a little feature creep as I noticed that 'model' was
blank and 'sector size' was not right for AF drives. These are
corrected as well.
Jeff
diff -u parted-2.3/debian/changelog parted-2.3/debian/changelog
--- parted-2.3/debian/changelog
+++ parted-2.3/debian/changelog
@@ -1,3 +1,12 @@
+parted (2.3-11.1) UNRELEASED; urgency=low
+
+ * Non-maintainer upload.
+ * Treat adaN devices as SCSI (cam) devices (Closes: #693510)
+ * Fill out the drive model information for ata adaN devices
+ * Fill out the physical sector size information for ata adaN devices
+
+ -- Jeff Epler jep...@unpythonic.net Wed, 19 Dec 2012 20:41:04 -0600
+
parted (2.3-11) unstable; urgency=medium
* Non-maintainer upload to fix partitioned md devices (bug #684713)
diff -u parted-2.3/debian/patches/series parted-2.3/debian/patches/series
--- parted-2.3/debian/patches/series
+++ parted-2.3/debian/patches/series
@@ -30,0 +31 @@
+freebsd-cam.diff
only in patch2:
unchanged:
--- parted-2.3.orig/debian/patches/freebsd-cam.diff
+++ parted-2.3/debian/patches/freebsd-cam.diff
@@ -0,0 +1,105 @@
+Index: b/libparted/arch/freebsd.c
+===
+--- a/libparted/arch/freebsd.c
b/libparted/arch/freebsd.c
+@@ -60,6 +60,7 @@
+
+ struct _FreeBSDSpecific {
+ int fd;
++ long long phys_sector_size;
+ };
+
+ static char* _device_get_part_path (PedDevice* dev, int num);
+@@ -108,7 +109,9 @@
+ }
+ np += 1; /* advance past '/' */
+
+- if(strncmp(np, ad, 2) == 0) {
++ if(strncmp(np, ada, 3) == 0) {
++ dev-type = PED_DEVICE_SCSI;
++ } else if(strncmp(np, ad, 2) == 0) {
+ dev-type = PED_DEVICE_IDE;
+ } else if (strncmp(np, da, 2) == 0) {
+ dev-type = PED_DEVICE_SCSI;
+@@ -146,6 +149,9 @@
+ dev-sector_size = (long long)sector_size;;
+ }
+
++ if (arch_specific-phys_sector_size)
++ dev-phys_sector_size = arch_specific-phys_sector_size;
++
+ if (sector_size != PED_SECTOR_SIZE_DEFAULT) {
+ ped_exception_throw (
+ PED_EXCEPTION_WARNING,
+@@ -288,7 +294,8 @@
+ int fd;
+ char result[64];
+
+- if (sscanf (dev-path, /dev/%2s%u, ccb.cgdl.periph_name, ccb.cgdl.unit_number) != 2)
++ if (sscanf (dev-path, /dev/%2s%u, ccb.cgdl.periph_name, ccb.cgdl.unit_number) != 2
++ sscanf (dev-path, /dev/%3s%u, ccb.cgdl.periph_name, ccb.cgdl.unit_number) != 2)
+ goto error;
+
+ if ((fd = open(/dev/xpt0, O_RDWR)) 0)
+@@ -308,9 +315,33 @@
+ return NULL;
+ }
+
++// NB should pull this in from libcam
++static uint32_t
++local_ata_logical_sector_size(struct ata_params *ident_data)
++{
++if ((ident_data-pss 0xc000) == 0x4000
++(ident_data-pss ATA_PSS_LSSABOVE512)) {
++return ((u_int32_t)ident_data-lss_1 |
++((u_int32_t)ident_data-lss_2 16));
++}
++return (512);
++}
++
++static uint64_t
++local_ata_physical_sector_size(struct ata_params *ident_data)
++{
++if ((ident_data-pss 0xc000) == 0x4000
++(ident_data-pss ATA_PSS_MULTLS)) {
++return ((uint64_t)local_ata_logical_sector_size(ident_data) *
++(1 (ident_data-pss ATA_PSS_LSPPS)));
++}
++return (512);
++}
++
+ static int
+ init_scsi (PedDevice* dev)
+ {
++ FreeBSDSpecific* arch_specific = FREEBSD_SPECIFIC (dev);
+ PedExceptionOption ex_status;
+ struct stat dev_stat;
+ char* pass_dev;
+@@ -391,10 +422,16 @@
+ break;
+ }
+ } else {
+- dev-model = (char*) ped_malloc (8 + 16 + 2);
++ size_t model_length = (8 + 16 + 2);
++ dev-model = (char*) ped_malloc (model_length);
+ if (!dev-model)
+ goto error_close_fd_dev;
+- sprintf (dev-model, %.8s %.16s, ccb.cgd.inq_data.vendor, ccb.cgd.inq_data.product);
++ if (ccb.cgd.protocol == PROTO_ATA *ccb.cgd.ident_data.model) {
++ snprintf (dev-model, model_length, %s, ccb.cgd.ident_data.model);
++ arch_specific-phys_sector_size = local_ata_physical_sector_size(ccb.cgd.ident_data);
++ } else {
++ snprintf (dev-model, model_length, %.8s %.16s, ccb.cgd.inq_data.vendor, ccb.cgd.inq_data.product);
++ }
+ }
+
+ if (!_device_probe_geometry (dev))
+@@ -534,6 +571,8 @@
+ if (!dev-arch_specific)
+ goto error_free_path;
+
++ memset(dev-arch_specific, 0, sizeof(FreeBSDSpecific));
++
+ dev-open_count = 0;
+ dev-read_only = 0;
+ dev-external_mode = 0;
Bug#696119: `zpool status` incorrectly names raidz vdevs
Package: libzfs1
Version: 9.0-3
Severity: normal
Tags: patch
zpool status incorrectly prints raidz vdevs as -0 instead of
raidz1-0, e.g.
$ zpool status mpool
pool: mpool
state: ONLINE
scan: scrub repaired 0 in 0h52m with 0 errors on Sun Dec 16 12:43:40 2012
config:
NAMESTATE READ WRITE CKSUM
mpool ONLINE 0 0 0
-0ONLINE 0 0 0
ada0p3 ONLINE 0 0 0
ada1p3 ONLINE 0 0 0
ada2p3 ONLINE 0 0 0
should be
$ LD_LIBRARY_PATH=debian/libzfs1/lib zpool status mpool
pool: mpool
state: ONLINE
scan: scrub repaired 0 in 0h52m with 0 errors on Sun Dec 16 12:43:40 2012
config:
NAMESTATE READ WRITE CKSUM
mpool ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
ada0p3 ONLINE 0 0 0
ada1p3 ONLINE 0 0 0
ada2p3 ONLINE 0 0 0
I investigated the problem and it turns out to be bad use of snprintf (the
output buffer is the same as one of the positional arguments); Solaris and
possibly FreeBSD libc behave differently than glibc in this case. (FreeBSD 9.0
doesn't exhibit the problem)
I have a patch derived from the zfsonlinux project, where they have also
fixed the bug. My patch is simply a combination of these two patches:
https://github.com/zfsonlinux/zfs/commit/858219cc4e44
https://github.com/zfsonlinux/zfs/commit/fc24f7c887a0
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 9.0-2-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libzfs1 depends on:
ii libbsd0 0.4.2-1
ii libc0.1 2.13-37
ii libgeom19.0+ds1-3
ii libnvpair1 9.0-3
ii libumem19.0-3
ii libuutil1 9.0-3
libzfs1 recommends no packages.
Libzfs1 suggests no packages.
-- no debconf information
Index: zfsutils-9.0/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c
===
--- zfsutils-9.0.orig/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c
2012-12-16 12:15:18.0 -0600
+++ zfsutils-9.0/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c
2012-12-16 13:11:34.171723989 -0600
@@ -3087,6 +3087,8 @@
(void) ioctl(zhp-zpool_hdl-libzfs_fd, ZFS_IOC_VDEV_SETPATH, zc);
}
+#definePATH_BUF_LEN64
+
/*
* Given a vdev, return the name to display in iostat. If the vdev has a path,
* we use that, stripping off any leading /dev/dsk/; if not, we use the type.
@@ -3108,7 +3110,8 @@
{
char *path, *devid;
uint64_t value;
- char buf[64];
+ char buf[PATH_BUF_LEN];
+ char tmpbuf[PATH_BUF_LEN];
vdev_stat_t *vs;
uint_t vsc;
int have_stats;
@@ -3204,6 +3207,7 @@
* If it's a raidz device, we need to stick in the parity level.
*/
if (strcmp(path, VDEV_TYPE_RAIDZ) == 0) {
+
verify(nvlist_lookup_uint64(nv, ZPOOL_CONFIG_NPARITY,
value) == 0);
(void) snprintf(buf, sizeof (buf), %s%llu, path,
@@ -3220,9 +3224,9 @@
verify(nvlist_lookup_uint64(nv, ZPOOL_CONFIG_ID,
id) == 0);
- (void) snprintf(buf, sizeof (buf), %s-%llu, path,
- (u_longlong_t)id);
- path = buf;
+ (void) snprintf(tmpbuf, sizeof (tmpbuf), %s-%llu,
+ path, (u_longlong_t)id);
+ path = tmpbuf;
}
}
--
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/20121216224055.ga18...@unpythonic.net
Bug#653929: Bug #696119 probably has the fix to this bug
Tags: patch
Today I filed a bug about this same problem, having found this earlier
report too late. I believe the patch on bug #696119 will address this
problem (which is not seen on freebsd due to libc differences).
As I'm a newbie at the debian bugtracker I'm not sure how to merge the
two bugs, or even if that's how it's done here. I hope I'm not doing
ill by repeating my patch here.
Index: zfsutils-9.0/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c
===
--- zfsutils-9.0.orig/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c
2012-12-16 12:15:18.0 -0600
+++ zfsutils-9.0/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c
2012-12-16 13:11:34.171723989 -0600
@@ -3087,6 +3087,8 @@
(void) ioctl(zhp-zpool_hdl-libzfs_fd, ZFS_IOC_VDEV_SETPATH, zc);
}
+#definePATH_BUF_LEN64
+
/*
* Given a vdev, return the name to display in iostat. If the vdev has a path,
* we use that, stripping off any leading /dev/dsk/; if not, we use the type.
@@ -3108,7 +3110,8 @@
{
char *path, *devid;
uint64_t value;
- char buf[64];
+ char buf[PATH_BUF_LEN];
+ char tmpbuf[PATH_BUF_LEN];
vdev_stat_t *vs;
uint_t vsc;
int have_stats;
@@ -3204,6 +3207,7 @@
* If it's a raidz device, we need to stick in the parity level.
*/
if (strcmp(path, VDEV_TYPE_RAIDZ) == 0) {
+
verify(nvlist_lookup_uint64(nv, ZPOOL_CONFIG_NPARITY,
value) == 0);
(void) snprintf(buf, sizeof (buf), %s%llu, path,
@@ -3220,9 +3224,9 @@
verify(nvlist_lookup_uint64(nv, ZPOOL_CONFIG_ID,
id) == 0);
- (void) snprintf(buf, sizeof (buf), %s-%llu, path,
- (u_longlong_t)id);
- path = buf;
+ (void) snprintf(tmpbuf, sizeof (tmpbuf), %s-%llu,
+ path, (u_longlong_t)id);
+ path = tmpbuf;
}
}
--
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/20121217020004.gb18...@unpythonic.net
Bug#653929: Bug #696119 probably has the fix to this bug
On Mon, Dec 17, 2012 at 02:24:42AM +, Steven Chamberlain wrote: Originally in #653929 it was said that this bug breaks GRUB in some way, and could prevent use of RAID-Z as a root filesystem; do you know if that is true? Unfortunately, I don't know the answer to this. I am booting from a mirrored pool and storing most of my data on a raidz pool. (in part because I thought raidz booting was not supported) I have never tried to boot from a raidz pool in freebsd or with grub. However, I note that booting from raidz is in the NEWS file for grub2 2.00-7 (sid) but not 1.99-23 (squeeze), so I think that trouble booting from raidz probably stems from grub, not from this problem in zpool / libzfs. To the original poster I'd suggest seeing whether grub2 2.00-7 from sid enables booting from raidz... Jeff -- 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/20121217033042.gc18...@unpythonic.net
