issue with libthr?
Hi, I'm getting a ton of core dumps from Python and any software that uses Python, ie has USE_PYTHON_BUILD=yes in Makefile. hundreds of msgs in dmesg: pid 36637 (seamonkey), uid 1001: exited on signal 11 (core dumped) pid 36986 (seamonkey), uid 1001: exited on signal 11 (core dumped) pid 37054 (seamonkey), uid 1001: exited on signal 11 (core dumped) pid 51780 (seamonkey), uid 1001: exited on signal 11 (core dumped) pid 83350 (python2.7), uid 0: exited on signal 6 (core dumped) from gdb it seems to me to be libthr related? I've noticed a couple updates in May.. wonder if it's related? I've only noticed this issue in the past week, after a complete rebuild and updated. > uname -a FreeBSD dx.burplex.com 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r25: Wed May 29 16:44:31 PDT 2013 r...@dx.burplex.com:/usr/obj/usr/src/sys/FURAHA amd64 gdb: seamonkey (gdb) bt #0 0x0008011ee8ca in thr_kill () from /lib/libc.so.7 #1 0x00080316b585 in XRE_InstallX11ErrorHandler () from /usr/local/lib/seamonkey/libxul.so #2 0x000800f73286 in swapcontext () from /lib/libthr.so.3 #3 0x000800f72e89 in sigaction () from /lib/libthr.so.3 #4 0x71d3 in ?? () #5 0x000800f72d70 in sigaction () from /lib/libthr.so.3 Previous frame inner to this frame (corrupt stack?) python (gdb) bt #0 0x00080100d8ca in thr_kill () from /lib/libc.so.7 #1 0x0008010d2e9c in abort () from /lib/libc.so.7 #2 0x000803e4f05b in free () from /usr/local/lib/python2.7/lib-dynload/_ctypes.so #3 0x000800d9319f in pthread_mutex_destroy () from /lib/libthr.so.3 #4 0x0008010269ff in closedir () from /lib/libc.so.7 #5 0x004b545c in initposix () #6 0x0047fb75 in PyEval_EvalFrameEx () #7 0x0047d824 in PyEval_EvalCodeEx () #8 0x00484256 in _PyEval_SliceIndex () #9 0x004810cd in PyEval_EvalFrameEx () #10 0x0047d824 in PyEval_EvalCodeEx () #11 0x004d5f56 in PyFunction_SetClosure () #12 0x0041ffeb in PyObject_Call () #13 0x00482085 in PyEval_EvalFrameEx () #14 0x0047d824 in PyEval_EvalCodeEx () #15 0x00484256 in _PyEval_SliceIndex () #16 0x004810cd in PyEval_EvalFrameEx () #17 0x0047d824 in PyEval_EvalCodeEx () #18 0x00484256 in _PyEval_SliceIndex () #19 0x004810cd in PyEval_EvalFrameEx () #20 0x0047d824 in PyEval_EvalCodeEx () #21 0x00484256 in _PyEval_SliceIndex () #22 0x004810cd in PyEval_EvalFrameEx () #23 0x004841f2 in _PyEval_SliceIndex () #24 0x004810cd in PyEval_EvalFrameEx () #25 0x004841f2 in _PyEval_SliceIndex () #26 0x004810cd in PyEval_EvalFrameEx () #27 0x004841f2 in _PyEval_SliceIndex () #28 0x004810cd in PyEval_EvalFrameEx () #29 0x004841f2 in _PyEval_SliceIndex () #30 0x004810cd in PyEval_EvalFrameEx () #31 0x004841f2 in _PyEval_SliceIndex () #32 0x004810cd in PyEval_EvalFrameEx () #33 0x0047d824 in PyEval_EvalCodeEx () #34 0x0047d156 in PyEval_EvalCode () #35 0x004a1361 in PyRun_FileExFlags () #36 0x004a0eb1 in PyRun_SimpleFileExFlags () #37 0x00417549 in Py_Main () #38 0x0041692f in main () Any help/pointers much appreciated. Thank you, -- Waitman Gobble San Jose California USA +1.5108307875 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: "make buildworld" fails
Craig Rodrigues writes:
> > > > sh /usr/src/tools/install.sh -o root -g wheel -m 555 make
> > > > /usr/obj/usr/src/make.amd64/make
> > > > usage: make [-BeikNnqrstWX]
> > > > [-C directory] [-D variable] [-d flags] [-f makefile]
> > > > [-I directory] [-J private] [-j max_jobs] [-m directory]
> > [-T
> > > > file]
> > > > [-V variable] [variable=value] [target ...]
> > > > *** [buildworld] Error code 2
> > > >
> > > > Stop in /usr/src.
> > >
> > > See this post:
> > > http://lists.freebsd.org/pipermail/freebsd-current/2013-May/041976.html
> >
> > Seen it and all all following.
> >
> > > and see if removing /usr/obj/usr/src/make.amd64/make helps.
> >
> > It does not.
>
> If you do:
>
> make -d l buildworld
>
> Does that give more debugging output of the exact command which
> is failing during the build?
Output is appended.
Robert Huff
(cd /usr/src && make bmake)
echo
echo "--"
--
echo ">>> Building an up-to-date make(1)"
>>> Building an up-to-date make(1)
echo "--"
--
cd /usr/src/usr.bin/bmake; MAKEOBJDIRPREFIX=/usr/obj/usr/src/make.amd64
DESTDIR= INSTALL="sh /usr/src/tools/install.sh" make -D_UPGRADING -DNOMAN
-DNO_MAN -DNOSHARED -DNO_SHARED -DNO_CPU_CFLAGS -DNO_WERROR obj &&
MAKEOBJDIRPREFIX=/usr/obj/usr/src/make.amd64 DESTDIR= INSTALL="sh
/usr/src/tools/install.sh" make -D_UPGRADING -DNOMAN -DNO_MAN -DNOSHARED
-DNO_SHARED -DNO_CPU_CFLAGS -DNO_WERROR depend &&
MAKEOBJDIRPREFIX=/usr/obj/usr/src/make.amd64 DESTDIR= INSTALL="sh
/usr/src/tools/install.sh" make -D_UPGRADING -DNOMAN -DNO_MAN -DNOSHARED
-DNO_SHARED -DNO_CPU_CFLAGS -DNO_WERROR all &&
MAKEOBJDIRPREFIX=/usr/obj/usr/src/make.amd64 DESTDIR= INSTALL="sh
/usr/src/tools/install.sh" make -D_UPGRADING -DNOMAN -DNO_MAN -DNOSHARED
-DNO_SHARED -DNO_CPU_CFLAGS -DNO_WERROR install
DESTDIR=/usr/obj/usr/src/make.amd64 BINDIR=
if ! test -d /usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake/; then mkdir -p
/usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake; if ! test -d
/usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake/; then echo "Unable to
create /usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake."; exit 1; fi; echo
"/usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake created for
/usr/src/usr.bin/bmake"; fi
/usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake created for
/usr/src/usr.bin/bmake
set -e; for entry in unit-tests; do if test -d
/usr/src/usr.bin/bmake/${entry}.amd64; then echo "===> ${entry}.amd64 (obj)";
edir=${entry}.amd64; cd /usr/src/usr.bin/bmake/${edir}; else echo "===>
$entry (obj)"; edir=${entry}; cd /usr/src/usr.bin/bmake/${edir}; fi; make
obj DIRPRFX=$edir/; done
===> unit-tests (obj)
if ! test -d /usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake/unit-tests/;
then mkdir -p /usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake/unit-tests;
if ! test -d /usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake/unit-tests/;
then echo "Unable to create
/usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake/unit-tests."; exit 1; fi;
echo "/usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake/unit-tests created for
/usr/src/usr.bin/bmake/unit-tests"; fi
/usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake/unit-tests created for
/usr/src/usr.bin/bmake/unit-tests
rm -f .depend
mkdep -f .depend -a-DNO_PWD_OVERRIDE -I/usr/src/usr.bin/bmake -DUSE_META
-DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DUSE_META -DMAKE_NATIVE
-DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I.
-I/usr/src/contrib/bmake -DMAKE_NATIVE -std=gnu99
/usr/src/contrib/bmake/arch.c /usr/src/contrib/bmake/buf.c
/usr/src/contrib/bmake/compat.c /usr/src/contrib/bmake/cond.c
/usr/src/contrib/bmake/dir.c /usr/src/contrib/bmake/for.c
/usr/src/contrib/bmake/hash.c /usr/src/contrib/bmake/job.c
/usr/src/contrib/bmake/main.c /usr/src/contrib/bmake/make.c
/usr/src/contrib/bmake/make_malloc.c /usr/src/contrib/bmake/meta.c
/usr/src/contrib/bmake/parse.c /usr/src/contrib/bmake/str.c
/usr/src/contrib/bmake/strlist.c /usr/src/contrib/bmake/suff.c
/usr/src/contrib/bmake/targ.c /usr/src/contrib/bmake/trace.c
/usr/src/contrib/bmake/util.c /usr/src/contrib/bmake/var.c
/usr/src/contrib/bmake/lst.lib/lstAppend.c
/usr/src/contrib/bmake/lst.lib/lstAtEnd.c /usr/src/contrib/bmake/lst.
lib/lstAtFront.c /usr/src/contrib/bmake/lst.lib/lstClose.c
/usr/src/contrib/bmake/lst.lib/lstConcat.c
/usr/src/contrib/bmake/lst.lib/lstDatum.c
/usr/src/contrib/bmake/lst.lib/lstDeQueue.c
/usr/src/contrib/bmake/lst.lib/lstDestroy.c
/usr/src/contrib/bmake/lst.lib/lstDupl.c
/usr/src/contrib/bmake/lst.lib/lstEnQueue.c
/usr/src/contrib/bmake/lst.lib/lstFind.c
/
Re: Supermicro 6027R-N3RF+head, usb trouble
On Thu, May 30, 2013 at 07:15:39AM -0500, Bryan Drewery wrote: > On 5/30/2013 12:07 AM, Konstantin Belousov wrote: > > On Wed, May 29, 2013 at 07:45:39AM -0500, Bryan Drewery wrote: > >> On 5/29/2013 7:16 AM, Bryan Drewery wrote: > >>> On 5/29/2013 12:33 AM, Sergey V. Dyatko wrote: > On Tue, 28 May 2013 13:20:53 -0500 > Bryan Drewery wrote: > > > On 4/21/2013 2:38 PM, Sergey V. Dyatko wrote: > >> Hi, > >> > >> Can anybody explain why USB keyboard (and keyboard from > >> integrated IPKVM) doesn't work when I boot with 'C606 > >> chipset Dual 4-Port SATA/SAS Storage Control Unit' enabled in bios? > >> Also I can't boot that box from usb memstick and > >> FreeBSD-10.0-CURRENT-amd64-20130413-r249439-release.iso They both > >> loose(?) device and can't find root If I disable controller in bios > >> system can't see any sata hdd connected to it:( > >> booting with hw.usb.ehci.no_hs=1, kern.cam.boot_delay="1" > >> and debug.acpi.disabled="hostres" without success. I setup dhcpd, > >> tftp, nfs on my laptop and finally I install fbsd on that box, but > >> question with kbd is open - It doesn't work.. > >> dmesg: > >> http://svn.freebsd.by/files/dmesg_N3RF.txt > >> pciconf -lv: > >> http://svn.freebsd.by/files/pciconf_N3RF.txt > >> > >> I would appreciate any hints > >> > > > > I'm having this exact problem on HEAD r250991 as well. 9.1-RELEASE > > (disc1) seems ok though. > > > > Did you get this figured out? > > > > I added to loader.conf > kern.maxbcache="128M" > >> > >> ^ This setting is all that was needed. The VFS change was not needed. > >> > >> > vfs.maxbufspace=134217728 > also I create /boot.config with '-v' > I don't know what exactly help, but now usb kbd (ipkvm) works fine > for me. > p.s. It is smbios.system.product="X9DRW" > > >>> > >>> Yes! This fix of limiting the size worked for me. USB worked on boot, kb > >>> works remotely in the IP KVM and locally as well now. > >>> > >>> For the record, this is a DELL C1100 with 72GB of ram. The symptoms > >>> match the previous posts though and the delay settings did not help. > >>> > >>> This was working on 9.1-R, something must have changed on HEAD. > >>> > >>> This is not a production system, I'm willing to try any patches or > >>> settings to help get this fixed by default. > >>> > > > > Could you get the values of sysctl kern.nbuf, kern.bio_transient_maxcnt > > from the boot without any tuning of the KVA usage ? > > > > # sysctl kern.nbuf kern.bio_transient_maxcnt kern.maxbcache > kern.nbuf: 472300 > kern.bio_transient_maxcnt: 1024 > kern.maxbcache: 0 > > For reference, with limiting maxbcache: > > # sysctl kern.nbuf kern.bio_transient_maxcnt kern.maxbcache > kern.nbuf: 7372 > kern.bio_transient_maxcnt: 102 > kern.maxbcache: 134217728 You did not tuned BKVASIZE nor MAXPHYS ? This is somewhat unexpected, but indeed reasonable. The buffer cache dutifully tried to allocate 1/10 of the RAM size for the buffer KVA. Please try the following tweak. diff --git a/sys/kern/vfs_bio.c b/sys/kern/vfs_bio.c index 7bd8d7e..2f92cde 100644 --- a/sys/kern/vfs_bio.c +++ b/sys/kern/vfs_bio.c @@ -560,7 +560,8 @@ kern_vfs_bio_buffer_alloc(caddr_t v, long physmem_est) nbuf += min((physmem_est - 4096) / factor, 65536 / factor); if (physmem_est > 65536) - nbuf += (physmem_est - 65536) * 2 / (factor * 5); + nbuf += min((physmem_est - 65536) * 2 / (factor * 5), + 32 * 1024 * 1024 / (factor * 5)); if (maxbcache && nbuf > maxbcache / BKVASIZE) nbuf = maxbcache / BKVASIZE; pgpusC8xLR4_g.pgp Description: PGP signature
Re: "make buildworld" fails
On Sat, Jun 1, 2013 at 8:06 AM, Robert Huff wrote: > > > (cd /usr/src && make bmake) > echo > > echo "--" > -- > echo ">>> Building an up-to-date make(1)" > >>> Building an up-to-date make(1) > echo "--" > -- > > sh /usr/src/tools/install.sh -o root -g wheel -m 555 make > /usr/obj/usr/src/make.amd64/make > cd /usr/src; PATH=/sbin:/bin:/usr/sbin:/usr/bin `if [ -x > /usr/obj/usr/src/make.amd64/make ]; then echo > /usr/obj/usr/src/make.amd64/make; else echo make; fi` -m /usr/src/share/mk > -f Makefile.inc1 TARGET=amd64 TARGET_ARCH=amd64 buildworld > usage: make [-BeikNnqrstWX] > [-C directory] [-D variable] [-d flags] [-f makefile] > [-I directory] [-J private] [-j max_jobs] [-m directory] [-T > file] > [-V variable] [variable=value] [target ...] > *** [buildworld] Error code 2 > > Stop in /usr/src. > Thank you for providing the output of make -d l buildworld. Without touching anything in your tree, can you provide some more information: (1) What is the output of /usr/bin/make -V MAKE_VERSION (2) What is the output of /usr/obj/usr/src/make.amd64/make -V MAKE_VERSION (3) How did you update your source tree (svn, svnup, cvs, csup,?) (4) What is the GRN version of your tree? If you updated with svn directly, you can find out with "svn info /usr/src" -- Craig ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: issue with libthr?
On Sat, Jun 01, 2013 at 12:54:14AM -0700, Waitman Gobble wrote: > > Hi, > > I'm getting a ton of core dumps from Python and any software that uses Python, > ie has USE_PYTHON_BUILD=yes in Makefile. > > hundreds of msgs in dmesg: > pid 36637 (seamonkey), uid 1001: exited on signal 11 (core dumped) > pid 36986 (seamonkey), uid 1001: exited on signal 11 (core dumped) > pid 37054 (seamonkey), uid 1001: exited on signal 11 (core dumped) > pid 51780 (seamonkey), uid 1001: exited on signal 11 (core dumped) > pid 83350 (python2.7), uid 0: exited on signal 6 (core dumped) > > from gdb it seems to me to be libthr related? I've noticed a couple updates in > May.. wonder if it's related? I've only noticed this issue in the past week, > after a complete rebuild and updated. > > > uname -a > FreeBSD dx.burplex.com 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r25: Wed May > 29 16:44:31 PDT 2013 r...@dx.burplex.com:/usr/obj/usr/src/sys/FURAHA > amd64 > > gdb: > > seamonkey > > (gdb) bt > #0 0x0008011ee8ca in thr_kill () from /lib/libc.so.7 > #1 0x00080316b585 in XRE_InstallX11ErrorHandler () >from /usr/local/lib/seamonkey/libxul.so > #2 0x000800f73286 in swapcontext () from /lib/libthr.so.3 > #3 0x000800f72e89 in sigaction () from /lib/libthr.so.3 > #4 0x71d3 in ?? () > #5 0x000800f72d70 in sigaction () from /lib/libthr.so.3 > Previous frame inner to this frame (corrupt stack?) > > > python > > (gdb) bt > #0 0x00080100d8ca in thr_kill () from /lib/libc.so.7 > #1 0x0008010d2e9c in abort () from /lib/libc.so.7 > #2 0x000803e4f05b in free () >from /usr/local/lib/python2.7/lib-dynload/_ctypes.so > #3 0x000800d9319f in pthread_mutex_destroy () from /lib/libthr.so.3 > #4 0x0008010269ff in closedir () from /lib/libc.so.7 > #5 0x004b545c in initposix () > #6 0x0047fb75 in PyEval_EvalFrameEx () > #7 0x0047d824 in PyEval_EvalCodeEx () > #8 0x00484256 in _PyEval_SliceIndex () > #9 0x004810cd in PyEval_EvalFrameEx () > #10 0x0047d824 in PyEval_EvalCodeEx () > #11 0x004d5f56 in PyFunction_SetClosure () > #12 0x0041ffeb in PyObject_Call () > #13 0x00482085 in PyEval_EvalFrameEx () > #14 0x0047d824 in PyEval_EvalCodeEx () > #15 0x00484256 in _PyEval_SliceIndex () > #16 0x004810cd in PyEval_EvalFrameEx () > #17 0x0047d824 in PyEval_EvalCodeEx () > #18 0x00484256 in _PyEval_SliceIndex () > #19 0x004810cd in PyEval_EvalFrameEx () > #20 0x0047d824 in PyEval_EvalCodeEx () > #21 0x00484256 in _PyEval_SliceIndex () > #22 0x004810cd in PyEval_EvalFrameEx () > #23 0x004841f2 in _PyEval_SliceIndex () > #24 0x004810cd in PyEval_EvalFrameEx () > #25 0x004841f2 in _PyEval_SliceIndex () > #26 0x004810cd in PyEval_EvalFrameEx () > #27 0x004841f2 in _PyEval_SliceIndex () > #28 0x004810cd in PyEval_EvalFrameEx () > #29 0x004841f2 in _PyEval_SliceIndex () > #30 0x004810cd in PyEval_EvalFrameEx () > #31 0x004841f2 in _PyEval_SliceIndex () > #32 0x004810cd in PyEval_EvalFrameEx () > #33 0x0047d824 in PyEval_EvalCodeEx () > #34 0x0047d156 in PyEval_EvalCode () > #35 0x004a1361 in PyRun_FileExFlags () > #36 0x004a0eb1 in PyRun_SimpleFileExFlags () > #37 0x00417549 in Py_Main () > #38 0x0041692f in main () > > > Any help/pointers much appreciated. You cannot even guess what is going on without a proper debug information. Recompile and reinstall the libc/libthr/rtld with the debugging symbols to get proper backtraces. Anyway, two backtraces you demostrated, although not giving much useful data, look very different. More, the second backtrace suggests that there is either a bug in python interposing of malloc or memory corruption. pgpU8hECIHAeC.pgp Description: PGP signature
Re: "make buildworld" fails
Craig Rodrigues writes: > Without touching anything in your tree, can you provide some more > information: > > (1) What is the output of /usr/bin/make -V MAKE_VERSION 10201205300 > (2) What is the output of /usr/obj/usr/src/make.amd64/make -V MAKE_VERSION 20130520 > (4) What is the GRN version of your tree? If you updated with svn > directly, > you can find out with "svn info /usr/src" Working Copy Root Path: /usr/src URL: svn://svn0.us-east.freebsd.org/base/head Repository Root: svn://svn0.us-east.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 251213 Node Kind: directory Schedule: normal Last Changed Author: np Last Changed Rev: 251213 Last Changed Date: 2013-05-31 22:07:37 -0400 (Fri, 31 May 2013) Robert Huff ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: issue with libthr?
On Sat, 1 Jun 2013 20:44:00 +0300, Konstantin Belousov
wrote:
>
>
>
>You cannot even guess what is going on without a proper debug information.
>Recompile and reinstall the libc/libthr/rtld with the debugging symbols
>to get proper backtraces.
>
>Anyway, two backtraces you demostrated, although not giving much useful
>data, look very different. More, the second backtrace suggests that
>there is either a bug in python interposing of malloc or memory corruption.
Thanks so much for your help, I'll rebuild with debug on next.
One thing I can get an instant crash is building midori, so I've been
experimenting to see where it's breaking.
It seems two things in the build script cause it wreck python:
the midori build reconstitutes a binary coded file within the script, it's a
file t.bz, which is uncompressed to become wafadmin,
inside that is a file Tools/config_c.py
there's
p.Utils.pproc.Popen in 'cmd_and_log' function
it returns:
p:
{'_child_created': True, 'returncode': 1, 'stdout': ',
mode 'rb' at 0x8037e92e0>, 'stdin': None, 'pid': 62571, 'stderr': ', mode 'rb' at 0x8037e8b60>, 'universal_newlines': False}
the '1' returncode causes build to fail..
Also, function def validate_c(self,kw)
*always* causes python to crash
for example, when it calls
conf.check (header_name='unistd.h')
..core dump...
Maybe this isn't useful information.. Next I'll rebuild with debug and see
about getting more info from gdb.
Thanks,
--
Waitman Gobble
San Jose California USA
+1.5108307875
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: "make buildworld" fails
On Sat, Jun 1, 2013 at 10:47 AM, Robert Huff wrote: > > Craig Rodrigues writes: > > Without touching anything in your tree, can you provide some more > > information: > > > > (1) What is the output of /usr/bin/make -V MAKE_VERSION > > 10201205300 > > > (2) What is the output of /usr/obj/usr/src/make.amd64/make -V > MAKE_VERSION > > 20130520 > > > (4) What is the GRN version of your tree? If you updated with svn > > directly, > > you can find out with "svn info /usr/src" > > Working Copy Root Path: /usr/src > URL: svn://svn0.us-east.freebsd.org/base/head > Repository Root: svn://svn0.us-east.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 251213 > Node Kind: directory > Schedule: normal > Last Changed Author: np > Last Changed Rev: 251213 > Last Changed Date: 2013-05-31 22:07:37 -0400 (Fri, 31 May 2013) > Thanks for providing the information. This looks related to the latest change to switch to bmake. I don't understand how all the pieces of the puzzle fit together to 100% diagnose the problem, but an you try the following: (1) Completely blow away the obj tree with: rm -fr /usr/obj (2) Update the source tree under /usr/src to the latest revision with "svn update" (3) Try again: make -d l buildworld -- Craig ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: mounting root from NFS via ROOTDEVNAME
Lars Eggert wrote:
> Hi,
>
> to conclude this thread, the patch below allows one to specify an nfs
> rootfs via the ROOTDEVNAME kernel option, which will be mounted when
> BOOTP does not return a root-path option.
>
> Lars
>
My only concern with this (mainly because I don't understand the rules
applied to boot alternatives well enough) is that a few arm configs have
both BOOTP, BOOTP_NFSROOT and ROOTDEVNAME specified, where ROOTDEVNAME
is set to "ufs:...". I don't think this patch will break them, since I
think they'll use NFS and ignore the ROOTDEVNAME, but I'm not completely
sure. Does someone else know how HL201 boots, for example?
Lars, if you have a src commit, you can consider this reviewed by me. If
not, maybe Craig can review it and then I'll commit it.
Thanks for doing this, rick
>
> diff --git a/sys/nfs/bootp_subr.c b/sys/nfs/bootp_subr.c
> index 2c57a91..972fb12 100644
> --- a/sys/nfs/bootp_subr.c
> +++ b/sys/nfs/bootp_subr.c
> @@ -45,6 +45,7 @@ __FBSDID("$FreeBSD$");
>
> #include "opt_bootp.h"
> #include "opt_nfs.h"
> +#include "opt_rootdevname.h"
>
> #include
> #include
> @@ -870,8 +871,20 @@ bootpc_call(struct bootpc_globalcontext *gctx,
> struct thread *td)
> rtimo = time_second +
> BOOTP_SETTLE_DELAY;
> printf(" (got root path)");
> - } else
> + } else {
> printf(" (no root path)");
> +#ifdef ROOTDEVNAME
> + /*
> + * If we'll mount rootfs from
> + * ROOTDEVNAME, we can accept
> + * offers without root paths.
> + */
> + gotrootpath = 1;
> + rtimo = time_second +
> + BOOTP_SETTLE_DELAY;
> + printf(" (ROOTDEVNAME)");
> +#endif
> + }
> printf("\n");
> }
> } /* while secs */
> @@ -1440,6 +1453,16 @@ bootpc_decode_reply(struct nfsv3_diskless *nd,
> struct bootpc_ifcontext *ifctx,
>
> p = bootpc_tag(&gctx->tag, &ifctx->reply, ifctx->replylen,
> TAG_ROOT);
> +#ifdef ROOTDEVNAME
> + /*
> + * If there was no root path in BOOTP, use the one in ROOTDEVNAME.
> + */
> + if (p == NULL) {
> + p = strdup(ROOTDEVNAME, M_TEMP);
> + if (strcmp(strsep(&p, ":"), "nfs") != 0)
> + panic("ROOTDEVNAME is not an NFS mount point");
> + }
> +#endif
> if (p != NULL) {
> if (gctx->setrootfs != NULL) {
> printf("rootfs %s (ignored) ", p);
>
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
nvidia-driver 310.44 w/ -current
Could I have any pointer or suggestions to fix the following problem? I updated to -current, May 30 and tried to start Xorg on nvidia.GeForce 650 display. I got "Fatal server error: failed to create root window" that seemingly tells nothing for fix, and I have no idea to run xorg... Thank you in advance. Ken Yamada === Xorg.0.log === X.Org X Server 1.7.7 Release Date: 2010-05-04 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 10.0-CURRENT amd64 Current Operating System: FreeBSD tyd3.sub.tydfam.jp 10.0-CURRENT FreeBSD 10.0-CURRENT #3 r251220M: Sun Jun 2 07:22:30 JST 2013 root@:/usr/obj/usr/src/sys/TYD3 amd64 Build Date: 01 June 2013 06:13:09PM Current version of pixman: 0.28.2 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Sat Jun 1 23:07:25 2013 (++) Using config file: "/root/xorg.conf.new" (==) ServerLayout "X.org Configured" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "Card0" (**) |-->Input Device "Mouse0" (**) |-->Input Device "Keyboard0" (==) Automatically adding devices (==) Automatically enabling devices (**) FontPath set to: /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/, /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/ (**) ModulePath set to "/usr/local/lib/xorg/modules" (WW) AllowEmptyInput is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled. (WW) Disabling Mouse0 (WW) Disabling Keyboard0 (II) Loader magic: 0x7b6a50 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 6.0 X.Org XInput driver : 7.0 X.Org Server Extension : 2.0 (--) Using syscons driver with X support (version 2.0) (--) using VT number 9 (--) PCI:*(0:1:0:0) 10de:0fc6:10de:0973 NVIDIA Corporation GK107 [GeForce GTX 650] rev 161, Mem @ 0xfa00/16777216, 0xc000/268435456, 0xd000/33554432, I/O @ 0xe000/128, BIOS @ 0x/65536 (II) "extmod" will be loaded. This was enabled by default and also specified in the config file. (II) "dbe" will be loaded. This was enabled by default and also specified in the config file. (II) "glx" will be loaded. This was enabled by default and also specified in the config file. (II) "record" will be loaded. This was enabled by default and also specified in the config file. (II) "dri" will be loaded. This was enabled by default and also specified in the config file. (II) "dri2" will be loaded. This was enabled by default and also specified in the config file. (II) LoadModule: "extmod" (II) Loading /usr/local/lib/xorg/modules/extensions/libextmod.so (II) Module extmod: vendor="X.Org Foundation" compiled for 1.7.7, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "record" (II) Loading /usr/local/lib/xorg/modules/extensions/librecord.so (II) Module record: vendor="X.Org Foundation" compiled for 1.7.7, module version = 1.13.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension RECORD (II) LoadModule: "dbe" (II) Loading /usr/local/lib/xorg/modules/extensions/libdbe.so (II) Module dbe: vendor="X.Org Foundation" compiled for 1.7.7, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "dri" (II) Loading /usr/local/lib/xorg/modules/extensions/libdri.so (II) Module dri: vendor="X.Org Foundation" compiled for 1.7.7, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension XFree86-DRI (II) LoadModule: "dri2" (II) Loading /usr/local/lib/xorg/modules/extensions/libdri2.so (II) Module dri2: vendor="X.Org Foundation" compiled for 1.7.7, module version = 1.1.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DRI2 (II) LoadModule: "glx" (II) Loading /usr/local/lib/xorg/modules/extensions/libglx.so (II) Module glx: vendor="NVIDIA Corporation" compiled for 4.0.2, module version = 1.0.0 Module class: X.Org Server Extension (II) NVIDIA GLX Module 310.44 Wed Mar 27 15:00:45 PDT 2013 (II) Loading extension GLX (II) LoadModule: "nvidia" (II) Loading /usr/local/lib/x
Undesirable bmake behavior
Hi, today I got confronted with this little curiosity from bmake. I have built and installed the world, and after reboot I ran 'make delete-old' as root to get rid of accumulated stale files. This is what I got back: >>> Removing old files (only deletes safe to delete libs) >>> Old files removed >>> Removing old directories >>> Old directories removed To remove old libraries run '/usr/obj/usr/src/make.amd64/make delete-old-libs'. It turns out that somehow running make in src tree finds and tries to run a copy from .OBJDIR, if one is present, unconditionally now. I do not think this that is a particularly desirable and even sane behaviour - once buildworld has finished, no tool should ever try to run _anything_ from what is essentially a scratch space. Bootstrap and cross tools should only be used during corresponding stages of buildworld and by default. -- Alexander Kabaev signature.asc Description: PGP signature
Re: issue with libthr?
On Sat, 1 Jun 2013 11:14:46 -0700 (PDT), Waitman Gobble wrote: > >On Sat, 1 Jun 2013 20:44:00 +0300, Konstantin Belousov >wrote: >> >> >> >>You cannot even guess what is going on without a proper debug information. >>Recompile and reinstall the libc/libthr/rtld with the debugging symbols >>to get proper backtraces. >> >>Anyway, two backtraces you demostrated, although not giving much useful >>data, look very different. More, the second backtrace suggests that >>there is either a bug in python interposing of malloc or memory corruption. > > >Thanks so much for your help, I'll rebuild with debug on next. > Hello, Perhaps a better backtrace, from python2.7.core created when trying to install www/midori #0 thr_kill () at thr_kill.S:3 #1 0x000801184ecc in abort () at /usr/src/lib/libc/stdlib/abort.c:65 #2 0x00080464aca1 in free (mem=0x8065015b0) at /usr/ports/lang/python27/work/Python-2.7.5/Modules/_ctypes/libffi/src/dlmalloc.c:4350 #3 0x000800e4c1af in _pthread_mutex_destroy (mutex=) at /usr/src/lib/libthr/thread/thr_mutex.c:273 #4 0x0008010e0def in closedir (dirp=0x803b2dda0) at /usr/src/lib/libc/gen/closedir.c:65 #5 0x0053d482 in posix_listdir (self=0x0, args=0x806425ae0) at ./../Modules/posixmodule.c:2543 #6 0x0057fa6e in PyCFunction_Call (func=0x801920080, arg=0x806425ae0, kw=0x0) at ./../Objects/methodobject.c:81 #7 0x004e40dd in call_function (pp_stack=0x7fff9388, oparg=1) at ./../Python/ceval.c:4021 #8 0x004dffcd in PyEval_EvalFrameEx (f=0x801a8f9a0, throwflag=0) at ./../Python/ceval.c:2666 snipped, complete backtrace at https://dx.burplex.com/backtrace.txt all ports have been rebuilt, lib_pkgchk returns no missing libraries. running FreeBSD 10.0-CURRENT #0 r251216: Sat Jun 1 03:21:48 PDT 2013 It seems that any program using Python crashes. also, Seamonkey. I do not so far notice any other issues with this system. It was working great until an update about a week ago. seamonkey (gdb) bt #0 thr_kill () at thr_kill.S:3 #1 0x00080316b585 in XRE_InstallX11ErrorHandler () from /usr/local/lib/seamonkey/libxul.so #2 0x000800f75286 in handle_signal (actp=, sig=11, info=0x7fffb7f0, ucp=0x7fffb480) at /usr/src/lib/libthr/thread/thr_sig.c:237 #3 0x000800f74e89 in thr_sighandler (sig=11, info=, _ucp=) at /usr/src/lib/libthr/thread/thr_sig.c:182 #4 0x71d3 in ?? () #5 0x000800f74d70 in sigaction () at /usr/src/lib/libthr/thread/thr_sig.c:574 Previous frame inner to this frame (corrupt stack?) Current language: auto; currently asm Thank you. -- Waitman Gobble San Jose California USA +1.5108307875 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: issue with libthr?
On 2/06/2013 2:03 PM, Waitman Gobble wrote: > On Sat, 1 Jun 2013 11:14:46 -0700 (PDT), Waitman Gobble > wrote: >> >> On Sat, 1 Jun 2013 20:44:00 +0300, Konstantin Belousov > >> wrote: >>> >>> >>> >>> You cannot even guess what is going on without a proper debug information. >>> Recompile and reinstall the libc/libthr/rtld with the debugging symbols >>> to get proper backtraces. >>> >>> Anyway, two backtraces you demostrated, although not giving much useful >>> data, look very different. More, the second backtrace suggests that >>> there is either a bug in python interposing of malloc or memory > corruption. >> >> >> Thanks so much for your help, I'll rebuild with debug on next. >> > > > Hello, > > Perhaps a better backtrace, from python2.7.core created when trying to install > www/midori > > #0 thr_kill () at thr_kill.S:3 > #1 0x000801184ecc in abort () at /usr/src/lib/libc/stdlib/abort.c:65 > #2 0x00080464aca1 in free (mem=0x8065015b0) > at > /usr/ports/lang/python27/work/Python-2.7.5/Modules/_ctypes/libffi/src/dlmalloc.c:4350 > #3 0x000800e4c1af in _pthread_mutex_destroy (mutex= out>) > at /usr/src/lib/libthr/thread/thr_mutex.c:273 > #4 0x0008010e0def in closedir (dirp=0x803b2dda0) > at /usr/src/lib/libc/gen/closedir.c:65 > #5 0x0053d482 in posix_listdir (self=0x0, args=0x806425ae0) > at ./../Modules/posixmodule.c:2543 > #6 0x0057fa6e in PyCFunction_Call (func=0x801920080, arg=0x806425ae0, > > kw=0x0) at ./../Objects/methodobject.c:81 > #7 0x004e40dd in call_function (pp_stack=0x7fff9388, oparg=1) > at ./../Python/ceval.c:4021 > #8 0x004dffcd in PyEval_EvalFrameEx (f=0x801a8f9a0, throwflag=0) > at ./../Python/ceval.c:2666 > > snipped, complete backtrace at https://dx.burplex.com/backtrace.txt > > > all ports have been rebuilt, lib_pkgchk returns no missing libraries. > running FreeBSD 10.0-CURRENT #0 r251216: Sat Jun 1 03:21:48 PDT 2013 > > It seems that any program using Python crashes. also, Seamonkey. I do not so > far notice > any other issues with this system. It was working great until an update about > a week ago. > > seamonkey > (gdb) bt > #0 thr_kill () at thr_kill.S:3 > #1 0x00080316b585 in XRE_InstallX11ErrorHandler () >from /usr/local/lib/seamonkey/libxul.so > #2 0x000800f75286 in handle_signal (actp=, sig=11, > > info=0x7fffb7f0, ucp=0x7fffb480) > at /usr/src/lib/libthr/thread/thr_sig.c:237 > #3 0x000800f74e89 in thr_sighandler (sig=11, info=, > > _ucp=) at /usr/src/lib/libthr/thread/thr_sig.c:182 > #4 0x71d3 in ?? () > #5 0x000800f74d70 in sigaction () > at /usr/src/lib/libthr/thread/thr_sig.c:574 > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently asm > > > Thank you. I wonder if Pythons regression test picks anything up: ./python -m test.regrtest Run that in $WRKSRC/portbld.static/ after building ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: issue with libthr?
On 2/06/2013 2:32 PM, Kubilay Kocak wrote: > I wonder if Pythons regression test picks anything up: > > ./python -m test.regrtest > > Run that in $WRKSRC/portbld.static/ after building Infact, run this instead: ./python -bb -E -Wd -m test.regrtest -r -w -uall [1] http://docs.python.org/devguide/runtests.html ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: issue with libthr?
On Sat, Jun 01, 2013 at 09:03:01PM -0700, Waitman Gobble wrote: > On Sat, 1 Jun 2013 11:14:46 -0700 (PDT), Waitman Gobble > wrote: > > > >On Sat, 1 Jun 2013 20:44:00 +0300, Konstantin Belousov > > >wrote: > >> > >> > >> > >>You cannot even guess what is going on without a proper debug information. > >>Recompile and reinstall the libc/libthr/rtld with the debugging symbols > >>to get proper backtraces. > >> > >>Anyway, two backtraces you demostrated, although not giving much useful > >>data, look very different. More, the second backtrace suggests that > >>there is either a bug in python interposing of malloc or memory > corruption. > > > > > >Thanks so much for your help, I'll rebuild with debug on next. > > > > > Hello, > > Perhaps a better backtrace, from python2.7.core created when trying to install > www/midori > > #0 thr_kill () at thr_kill.S:3 > #1 0x000801184ecc in abort () at /usr/src/lib/libc/stdlib/abort.c:65 > #2 0x00080464aca1 in free (mem=0x8065015b0) > at > /usr/ports/lang/python27/work/Python-2.7.5/Modules/_ctypes/libffi/src/dlmalloc.c:4350 > #3 0x000800e4c1af in _pthread_mutex_destroy (mutex= out>) > at /usr/src/lib/libthr/thread/thr_mutex.c:273 > #4 0x0008010e0def in closedir (dirp=0x803b2dda0) > at /usr/src/lib/libc/gen/closedir.c:65 > #5 0x0053d482 in posix_listdir (self=0x0, args=0x806425ae0) > at ./../Modules/posixmodule.c:2543 > #6 0x0057fa6e in PyCFunction_Call (func=0x801920080, arg=0x806425ae0, > > kw=0x0) at ./../Objects/methodobject.c:81 > #7 0x004e40dd in call_function (pp_stack=0x7fff9388, oparg=1) > at ./../Python/ceval.c:4021 > #8 0x004dffcd in PyEval_EvalFrameEx (f=0x801a8f9a0, throwflag=0) > at ./../Python/ceval.c:2666 > > snipped, complete backtrace at https://dx.burplex.com/backtrace.txt This seems to confirm that python interposed the free() function. Also, the python' version of free() raised an assert, which caused the coredump. I have no idea why it did this, and what condition check failed. This is probably a subject to talk with python maintainers. > > > all ports have been rebuilt, lib_pkgchk returns no missing libraries. > running FreeBSD 10.0-CURRENT #0 r251216: Sat Jun 1 03:21:48 PDT 2013 > > It seems that any program using Python crashes. also, Seamonkey. I do not so > far notice > any other issues with this system. It was working great until an update about > a week ago. > > seamonkey > (gdb) bt > #0 thr_kill () at thr_kill.S:3 > #1 0x00080316b585 in XRE_InstallX11ErrorHandler () >from /usr/local/lib/seamonkey/libxul.so > #2 0x000800f75286 in handle_signal (actp=, sig=11, > > info=0x7fffb7f0, ucp=0x7fffb480) > at /usr/src/lib/libthr/thread/thr_sig.c:237 > #3 0x000800f74e89 in thr_sighandler (sig=11, info=, > > _ucp=) at /usr/src/lib/libthr/thread/thr_sig.c:182 > #4 0x71d3 in ?? () > #5 0x000800f74d70 in sigaction () > at /usr/src/lib/libthr/thread/thr_sig.c:574 > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently asm This one is only the past some event, the backtrace shows the internal work of the libthr handling of the signal. Why signal was raised is up to the application. pgpde6yDi0Toi.pgp Description: PGP signature
Re: issue with libthr?
On Sun, 02 Jun 2013 14:45:31 +1000, Kubilay Kocak wrote: > >On 2/06/2013 2:32 PM, Kubilay Kocak wrote: >> I wonder if Pythons regression test picks anything up: >> >> ./python -m test.regrtest >> >> Run that in $WRKSRC/portbld.static/ after building > >Infact, run this instead: > > ./python -bb -E -Wd -m test.regrtest -r -w -uall > >[1] http://docs.python.org/devguide/runtests.html > Hi, Thanks for your reply, I appreciate it. Here are some errors.. [1053] > ./python -bb -E -Wd -m test.regrtest -r -w -uall == CPython 2.7.5 (default, Jun 1 2013, 22:09:55) [GCC 4.2.1 Compatible FreeBSD Clang 3.3 (trunk 178860)] == FreeBSD-10.0-CURRENT-amd64-64bit-ELF little-endian == /usr/ports/lang/python27/work/Python-2.7.5/build/test_python_98332 Testing with flags: sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=1, tabcheck=0, verbose=0, unicode=0, bytes_warning=2, hash_randomization=0) Using random seed 1989961 test_global ... test_rfc822 test_file test_decimal Abort (core dumped) test_dis test_memoryio test_importhooks test_netrc test_univnewlines2k test_codecencodings_tw test_property test_zipimport_support : /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h:942: Failed assertion: "arena_mapbits_allocated_get(chunk, pageind) != 0" Abort (core dumped) test_distutils : /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h:942: Failed assertion: "arena_mapbits_allocated_get(chunk, pageind) != 0" Abort (core dumped) test_threading test test_threading failed -- Traceback (most recent call last): File "/usr/ports/lang/python27/work/Python-2.7.5/Lib/test/test_threading.py", line 307, in test_finalize_runnning_thread self.assertEqual(rc, 42) AssertionError: -10 != 42 -- Waitman Gobble San Jose California USA +1.5108307875 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: issue with libthr?
On 2/06/2013 3:33 PM, Waitman Gobble wrote: > On Sun, 02 Jun 2013 14:45:31 +1000, Kubilay Kocak > wrote: >> >> On 2/06/2013 2:32 PM, Kubilay Kocak wrote: >>> I wonder if Pythons regression test picks anything up: >>> >>> ./python -m test.regrtest >>> >>> Run that in $WRKSRC/portbld.static/ after building >> >> Infact, run this instead: >> >> ./python -bb -E -Wd -m test.regrtest -r -w -uall >> >> [1] http://docs.python.org/devguide/runtests.html >> > > Hi, > > Thanks for your reply, I appreciate it. > > Here are some errors.. > > > > [1053] > ./python -bb -E -Wd -m test.regrtest -r -w -uall > == CPython 2.7.5 (default, Jun 1 2013, 22:09:55) [GCC 4.2.1 Compatible FreeBSD > Clang 3.3 (trunk 178860)] > == FreeBSD-10.0-CURRENT-amd64-64bit-ELF little-endian > == /usr/ports/lang/python27/work/Python-2.7.5/build/test_python_98332 > Testing with flags: sys.flags(debug=0, py3k_warning=0, division_warning=0, > division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, > no_user_site=0, no_site=0, ignore_environment=1, tabcheck=0, verbose=0, > unicode=0, bytes_warning=2, hash_randomization=0) > Using random seed 1989961 > test_global > ... > test_rfc822 > test_file > test_decimal > Abort (core dumped) > > test_dis > test_memoryio > test_importhooks > test_netrc > test_univnewlines2k > test_codecencodings_tw > test_property > test_zipimport_support > : > /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h:942: > Failed assertion: "arena_mapbits_allocated_get(chunk, pageind) != 0" > Abort (core dumped) > > test_distutils > : > /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h:942: > Failed assertion: "arena_mapbits_allocated_get(chunk, pageind) != 0" > Abort (core dumped) > > > test_threading > test test_threading failed -- Traceback (most recent call last): > File > "/usr/ports/lang/python27/work/Python-2.7.5/Lib/test/test_threading.py", line > 307, in test_finalize_runnning_thread > self.assertEqual(rc, 42) > AssertionError: -10 != 42 > > > > -- > Waitman Gobble > San Jose California USA > +1.5108307875 > > That last failure in test_threading I can reproduce on 10.0-CURRENT but I don't think its related. Those coredumps on the other hand. Incidentally, what OPTIONS did you build Python with? I ask cause WITH_PYMALLOC is the port and upstream default -- Ta, koobs ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
