Re: amd64 base/head r284673 fails to build on amd64 base/head r284639, pilot error?
On Jun 21, 2015, at 1:05 PM, Garrett Cooper yaneurab...@gmail.com wrote: On Jun 21, 2015, at 3:16, Trond Endrestøl trond.endres...@fagskolen.gjovik.no wrote: Am I the only one who fails to build recent base/head (r284673) on pretty recent base/head (r284639)? This is on amd64 with ZFS and BEs. ... CC=clang CXX=clang++ CPP=clang-cpp You need to remove these lines. They shouldn’t have been set before or after the commits from projects/bmake . I hit the same build failure, and I don't have any of those lines in my /etc/make.conf. Mine is: STRIP= # added by use.perl 2013-01-21 16:11:13 PERL_VERSION=5.12.4 WITH_PKGNG=yes The STRIP= definition appears to have no impact with regard to the build failure. I routinely do multiple buildworld/installworld cycles when updating, so I am pretty sure that this is a self bootstrap failure; buildworld/installworld succeeds the first time, but not the second time. r283923 does not have the problem, so this was introduced sometime in the past three weeks. Jason ___ 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: Compilation error (pkgng)
On Jan 23, 2013, at 12:14 AM, Alie Tan wrote:
Seems this check-in causing compilation error:
http://freshbsd.org/commit/freebsd/r245828
-nonliteral -c /usr/src/usr.sbin/pkg_install/lib/pkgng.c -o pkgng.o
/usr/src/usr.sbin/pkg_install/lib/pkgng.c:53:45: error: expected ')'
rc = snprintf(pkgngpath, sizeof(pkgngpath) %s/local.sqlite,
pkgngdir);
^
/usr/src/usr.sbin/pkg_install/lib/pkgng.c:53:15: note: to match this '('
rc = snprintf(pkgngpath, sizeof(pkgngpath) %s/local.sqlite,
pkgngdir);
^
/usr/src/usr.sbin/pkg_install/lib/pkgng.c:54:9: warning: comparison of
integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
if (rc = sizeof(pkgngpath)) {
~~ ^ ~
1 warning and 1 error generated.
Fixed by r245837.
Thanks,
Jason
___
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: installworld fails
On Jan 21, 2013, at 10:13 PM, AN a...@neu.net wrote: FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #29 r245766: Tue Jan 22 00:49:02 EST 2013 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 Is anyone seeing this? install -l s usr/src/sys /sys install: /sys/sys: Directory not empty *** [distrib-dirs] Error code 71 Yes. I haven't tracked down the cause, but doing 'rm /sys' prior to installworld is an effective workaround. Jason ___ 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: possible je-malloc issue
On Aug 2, 2012, at 3:32 PM, Steve Kargl wrote:
Libc built today.
Start X with fvwm window manager.
Open xterm and su to root.
1. Use nedit to edit a file and close.
fvwm drops core. If fvwm does not drop core repeat 1 until
she does.
(gdb) bt
#0 0x4841e294 in __jemalloc_arena_mapbits_get (chunk=0x800, pageind=245)
at
/usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h:502
#1 0x4841e2c4 in __jemalloc_arena_mapbits_allocated_get (chunk=0x800,
pageind=245)
at
/usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h:581
#2 0x4841e739 in __jemalloc_arena_salloc (ptr=0x80f58e0, demote=false)
at
/usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h:902
#3 0x48423dd1 in __jemalloc_isalloc (ptr=0x800, demote=false)
at
/usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/jemalloc_internal.h:791
#4 0x4842408e in free (ptr=0x80f58e0) at jemalloc_jemalloc.c:1212
#5 0x48164b7d in XFree (data=0x80f58e0) at XlibInt.c:1701
#6 0x080c4f2f in FlocaleFreeNameProperty (ptext=0xbfbfcfb4) at Flocale.c:2363
#7 0x0806d3ab in HandlePropertyNotify (ea=0xbfbfd014) at events.c:3422
#8 0x0806c369 in dispatch_event (e=0xbfbfd044) at events.c:4135
#9 0x0806ca5f in HandleEvents () at events.c:4179
#10 0x0808e06e in main (argc=1, argv=0xbfbfd7ac) at fvwm.c:2591
(gdb) frame 4
#4 0x4842408e in free (ptr=0x80f58e0) at jemalloc_jemalloc.c:1212
1212usize = isalloc(ptr, config_prof);
(gdb) print *ptr
Attempt to dereference a generic pointer.
(gdb) up 1
#5 0x48164b7d in XFree (data=0x80f58e0) at XlibInt.c:1701
1701XlibInt.c: No such file or directory.
(gdb) print *data
Attempt to dereference a generic pointer.
(gdb) up 1
#6 0x080c4f2f in FlocaleFreeNameProperty (ptext=0xbfbfcfb4) at Flocale.c:2363
2363Flocale.c: No such file or directory.
(gdb) print *ptext
$5 = {name = 0x80f58e0 Untitled, name_list = 0x0}
jemalloc is asserting that the page which contains 0x80f58e0 is allocated
according to the containing chunk's page map, but the chunk header isn't even
mapped, and the attempted read causes a segfault. This is almost certainly a
result of calling free() with a bogus pointer.
Jason___
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: jemalloc() assumes DSS is aligned
On Jun 13, 2012, at 8:31 AM, John Baldwin wrote: I tracked down a weird bug at work on the older jemalloc in FreeBSD 8/9 that a co-worker tripped over. Specifically, if you build the program below and link it with gold, the program will have an _end symbol that is on an odd address (std::nothrow results in some single-byte symbol being added to the end of the BSS). This causes the first arena allocated by jemalloc to use an odd address, and the rbt_nil structures for that arena's embedded trees (like runs_avail) to be allocated on odd addresses. This interferes with the RB trees using the low bit to distinguish red vs black. Specifically, the program ends up setting the right node of rbt_nil to an incorrect pointer value (the low bit gets cleared) resulting in an eventual segfault. Looking at phkmalloc, it always applied round_page() to the results from sbrk(). I believe that for jemalloc only the very first allocation from the DSS needs to check for misalignment, and the patch below does fix the segfault on FreeBSD 8. I have a stab at porting the change to jemalloc 3.0.0 in HEAD, but I'm not sure if it is quite correct. Also, I only made the DSS align on the quantum boundary rather than a page boundary. BTW, I filed a bug with the binutils folks as I initially thought this was a gold bug. However, POSIX doesn't make any guarantees about the return value of sbrk(), so I think gold is not broken. Hi John, Your fix for FreeBSD 7/8/9 looks correct to me. I don't currently have any development machines running anything but 10-CURRENT, so I'd be grateful if you could commit the fix, assuming it isn't much trouble for you. (I'll set up additional development installations if needed.) I don't think this is an issue for HEAD's chunk_alloc_dss(), because there is logic to always insert enough padding to allocate on chunk alignment boundaries, and also base_alloc() no longer makes any attempt to use a partial dss 'chunk'. Thanks, Jason P.S. Sorry about putting off responding to your original email for too long.___ 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: Syntax error in malloc_np.h
On May 21, 2012, at 8:57 AM, Hartmut Brandt wrote:
it seems that there is a syntax error in malloc_np.h. It contains lines like:
int allocm(void **ptr, size_t *rsize, size_t size, int flags)
__attribute__(nonnull(1));
The problem is that the syntax of the attributes actually requires two
parenthesis:
__attribute__((nonnull(1)));
Our gcc seems to swallow either of both, but gcc47 chokes on the missing
'(' as does clang++.
Given that we have __nonnull(x) in cdefs.h I suppose the above is better
replaced with __nonnull(1)?
__nonnull(1) looks like the best fix to me. Let me know if you want me to make
the fix, otherwise I'll leave it to you.
Thanks,
Jason___
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: jemalloc: jemalloc_arena.c:182: Failed assertion: p[i] == 0
On May 9, 2012, at 12:01 AM, Stefan Farfeleder wrote: On Tue, May 08, 2012 at 03:59:42PM -0700, Jason Evans wrote: On May 8, 2012, at 2:58 PM, Stefan Farfeleder wrote: On Tue, May 08, 2012 at 02:47:59PM -0700, Jason Evans wrote: On May 8, 2012, at 2:37 PM, Stefan Farfeleder wrote: I hit the same assertion with r235052 and inkscape. I'm now using MALLOC_PRODUCTION and it works again. Was the assertion failure easily reproducible with inkscape? Yes, it crashed everytime before showing the GUI. The backtrace goes like this: [snip] sbrk() is being used rather than mmap(). Unless mmap() is failing (which would surprise me), this indicates that you are using a version of libc that's old enough to have the bug I fixed in r234569. I'm afraid the backtrace was somehow corrupted. Here's a new one from a libc compiled with -g: […] I received a similar report from Kevin Lo regarding bsdtar that proved easy to reproduce. The fix is part of the jemalloc 3.0.0 import I just did, and I expect it fixes the inkscape crashes as well. Thanks, Jason___ 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: jemalloc: jemalloc_arena.c:182: Failed assertion: p[i] == 0
On May 8, 2012, at 2:37 PM, Stefan Farfeleder wrote: On Tue, May 08, 2012 at 12:48:17PM -0400, Steve Wills wrote: On 05/08/12 00:46, Jason Evans wrote: How recent is your system? This problem should have been fixed by r234569, so if you're still seeing problems after that revision, there's another problem we need to figure out. (By the way, it's possible for an application to trigger this assertion, but unlikely.) My system is r235115. I hit the same assertion with r235052 and inkscape. I'm now using MALLOC_PRODUCTION and it works again. Was the assertion failure easily reproducible with inkscape? Thanks, Jason ___ 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: jemalloc: jemalloc_arena.c:182: Failed assertion: p[i] == 0
On May 8, 2012, at 2:58 PM, Stefan Farfeleder wrote: On Tue, May 08, 2012 at 02:47:59PM -0700, Jason Evans wrote: On May 8, 2012, at 2:37 PM, Stefan Farfeleder wrote: On Tue, May 08, 2012 at 12:48:17PM -0400, Steve Wills wrote: On 05/08/12 00:46, Jason Evans wrote: How recent is your system? This problem should have been fixed by r234569, so if you're still seeing problems after that revision, there's another problem we need to figure out. (By the way, it's possible for an application to trigger this assertion, but unlikely.) My system is r235115. I hit the same assertion with r235052 and inkscape. I'm now using MALLOC_PRODUCTION and it works again. Was the assertion failure easily reproducible with inkscape? Yes, it crashed everytime before showing the GUI. The backtrace goes like this: (gdb) bt #0 0x00080ad760ac in thr_kill () from /lib/libc.so.7 #1 0x00080ae22548 in abort () from /lib/libc.so.7 #2 0x00080ad9f57d in sbrk () from /lib/libc.so.7 #3 0x00080ada1c51 in sbrk () from /lib/libc.so.7 #4 0x00080ada3624 in sbrk () from /lib/libc.so.7 #5 0x00080ada3ffc in sbrk () from /lib/libc.so.7 #6 0x00080ada432d in sbrk () from /lib/libc.so.7 #7 0x00080ad9394f in syscall () from /lib/libc.so.7 #8 0x00080ad93d70 in syscall () from /lib/libc.so.7 #9 0x00080ada73a0 in malloc () from /lib/libc.so.7 #10 0x00080a6a283d in operator new () from /usr/lib/libstdc++.so.6 #11 0x007af660 in sigc::internal::typed_slot_repsigc::bind_functor-1, sigc::pointer_functor3SPObject*, SPObject*, SPStyle*, void, SPStyle*, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil ::dup () #12 0x0008033016b4 in sigc::slot_base::slot_base () from /usr/local/lib/libsigc-2.0.so.0 #13 0x006f0a77 in std::listsigc::slot_base, std::allocatorsigc::slot_base ::insert () #14 0x00080330084a in sigc::internal::signal_impl::insert () from /usr/local/lib/libsigc-2.0.so.0 #15 0x000803300893 in sigc::internal::signal_impl::connect () from /usr/local/lib/libsigc-2.0.so.0 #16 0x000803300a44 in sigc::signal_base::connect () #17 0x007a8635 in SPIPaint::read () […] sbrk() is being used rather than mmap(). Unless mmap() is failing (which would surprise me), this indicates that you are using a version of libc that's old enough to have the bug I fixed in r234569. Thanks, Jason___ 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: jemalloc: jemalloc_arena.c:182: Failed assertion: p[i] == 0
On May 7, 2012, at 12:19 PM, Steve Wills wrote:
On Apr 21, 2012, at 11:54 AM, David Wolfskill wrote:
After applying Dimitry Andric's patches to contrib/jemalloc and
replacing
/usr/bin/as with one built last Sunday, I was finally(!) able to rebuild
head as of 234536:
FreeBSD freebeast.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #797
234536M: Sat Apr 21 10:23:33 PDT 2012
r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386
However, as I was copying a /usr/obj hierarchy via tar -- e.g.:
root@freebeast:/common/home/david # (cd /var/tmp rm -fr obj mkdir
obj) (cd /usr tar cpf - obj) | (cd /var/tmp tar xpf -)
it ran for a while, then:
jemalloc: jemalloc_arena.c:182: Failed assertion: p[i] == 0
Abort (core dumped)
root@freebeast:/common/home/david # echo $?
134
root@freebeast:/common/home/david # ls -lTio *.core
ls: No match.
root@freebeast:/common/home/david #
So ... no core file, apparently.
freebeast(10.0-C)[2] find /usr/src/contrib/jemalloc -type f -name
jemalloc_arena.c
freebeast(10.0-C)[3]
No file named jemalloc_arena.c, either.
But contrib/jemalloc/src/arena.c contains a function,
arena_chunk_validate_zeroed():
175 static inline void
176 arena_chunk_validate_zeroed(arena_chunk_t *chunk, size_t run_ind)
177 {
178 size_t i;
179 UNUSED size_t *p = (size_t *)((uintptr_t)chunk + (run_ind
LG_PAGE));
180
181 for (i = 0; i PAGE / sizeof(size_t); i++)
182 assert(p[i] == 0);
183 }
Thoughts?
I received a similar report yesterday in the context of filezilla, but
didn't get as far as reproducing it. I think the problem is in
chunk_alloc_dss(), which dangerously claims that newly allocated memory is
zeroed. It looks like I formalized this bad assumption in early 2010,
though the bug existed before that. It's a bigger deal now because sbrk()
is preferred over mmap(), so the bug has languished for a couple of years.
I'll get a fix committed today (and revert the order of preference
between sbrk() and mmap()).
By the way, I wonder why not everyone hits this (I don't).
I just now hit the same issue while using ports tinderbox. It was calling
tar during the makeJail tinderbox subcommand and gave the same error as
in the subject. Funny thing is I had run the same command (on a different
jail) right before this and didn't get the error. What's the status of
this? Should I set MALLOC_PRODUCTION=yes in /etc/make.conf, rebuild world
and forget about it?
How recent is your system? This problem should have been fixed by r234569, so
if you're still seeing problems after that revision, there's another problem we
need to figure out. (By the way, it's possible for an application to trigger
this assertion, but unlikely.)
Thanks,
Jason___
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: RFC: jemalloc: qdbus sigsegv in malloc_init
On Apr 30, 2012, at 7:13 AM, Gustau Pérez i Querol wrote: the kde team is seeing some strange problems with the new version (4.8.1) of devel/dbus-qt4 with current. It does work with stable. I also suspect that the problem described below is affecting the experimental cinnamon port (an alternative to gnome3, possible replacement of gnome2). The problem happens with both i386 and amd64 with empty /etc/malloc.conf and simple /etc/make.conf. Everything compiled with base gcc (no clang). The kernel was compiled with no debug support, but it can enable if needed. There are reports from avi...@freebsd.org of the same behavior with clang compiled world and kernel and with MALLOC_PRODUCTION=yes. When qdbus starts, it segfauts. The backtrace of the problem with r234769 can be found here: http://pastebin.com/ryBXtqGF. When starting the qdbus daemon by hand in a X+twm session, we see it calls calloc many times and after a fixed number of times segfaults. We see it segfaults at rb_gen (a quite large macro defined at $SRC_BASE/contrib/jemalloc/include/jemalloc/internal/rb.h). If the daemon is started by hand, I'm able to skip all the calls qdbus makes to calloc till the one causing the segfault. At that point, at rb_gen, we don't exactly know what is going on or how to debug the macro. Ktrace are available, but we were unable to find anything new from them. With old versions of current before the jemalloc imports (as of March 30th) the daemon segfaulted at malloc.c:2426. With revisions during April 20 to 24th (can be more precise, it was during the jemalloc imports) the daemon segfaulted at malloc_init. Bts are available if needed, and if necessary I can go back to those revision and recompile world+kernel to see its behavior. Any help from freebsd-current@ (perhaps Jason Evans can help us) will be appreciated. Any additional info, like source revisions, can be provided. I would like to stress that the experimental devel/dbus-qt4 works fine with recent stable. The crash is happening in page run management, so there is some pretty bad memory corruption going on by the time of the crash. If I understand you correctly, you have reproduced the crash on a system that does *not* have MALLOC_PRODUCTION defined, which means that none of the assertions in jemalloc caught the problem. Adrian Chadd made the excellent suggestion of trying valgrind; it's likely to point out the problem almost immediately. If that doesn't work, the utrace functionality in malloc may help you figure out what activity has occurred by the time of the crash, and give you a better understanding of what happened to memory around the address that is involved in the crash. Jason___ 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: jemalloc: jemalloc_arena.c:182: Failed assertion: p[i] == 0
On Apr 28, 2012, at 5:09 AM, Aleksandr Rybalko wrote:
On Apr 21, 2012, at 11:54 AM, David Wolfskill wrote:
But contrib/jemalloc/src/arena.c contains a function,
arena_chunk_validate_zeroed():
175 static inline void
176 arena_chunk_validate_zeroed(arena_chunk_t *chunk, size_t
run_ind) 177 {
178 size_t i;
179 UNUSED size_t *p = (size_t *)((uintptr_t)chunk +
(run_ind LG_PAGE)); 180
181 for (i = 0; i PAGE / sizeof(size_t); i++)
182 assert(p[i] == 0);
183 }
maybe it somehow related to low count of free memory, because I see
that very frequently on my box. (Atheros AR7242 mips32be with 32M of
RAM)
After #ifdef of that function body, box behave good (seems) :)
Yes, arena_chunk_validate_zeroed() (which is debug-only code) has the side
effect of faulting in untouched pages, so it potentially increases physical
memory usage. In practice, this sanity checking has saved jemalloc from
regressions that would otherwise manifest as mysterious application memory
corruption (and would have prevented even more regressions, had it existed
earlier). You can disable it and many other performance-sacrificing debug
features by defining MALLOC_PRODUCTION in /etc/make.conf.
Jason___
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: HEADSUP: /etc/malloc.conf format change
On Apr 25, 2012, at 9:39 AM, Ruslan Ermilov wrote: So you removed _malloc_options that was part of the documented programming API, while some software made use of it. While removing part of the documented API was definitely a bad idea, you didn't provide any mean to detect this change programmatically, neither through a macro test, nor by bumping __FreeBSD_version. The only way now is to try and see if it compiles, which is far from perfect. The way how _malloc_options is handled for binary compatibility, by simply ignoring its value, is (ahem) questionable. Why do I care? The developers of the nginx web server have been notified today that it could not be built on FreeBSD 10.0-CURRENT anymore, due to this change, when compiled with nginx malloc debugging. It's activated by the DEBUG option of the www/nginx-devel port, if you care to try it out. Please explore the possibility to add backwards compatiblity for the documented API, or at the very least provide a mean to detect this otherwise disruptive and hard to detect change for a programmer. A __FreeBSD_version bump seems like a good idea to me, but adding backward compatibility for _malloc_options is questionable at best. Of the 17 options that _malloc_options supported, only 6 have directly corresponding options in malloc_conf, plus another 3 that would present strange quirks (fragile and difficult to precisely document) if an attempt were made to provide compatibility. In past iterations I was always careful to provide as much option compatibility as possible over the lifetime of each release (e.g., 'H' in RELENG_7), but individual options came and went with major releases. _malloc_options could only be pushed so far, and when it hit its breaking point I replaced it. Creaky compatibility is IMO a liability rather than an asset. In the case of nginx, it looks like a __FreeBSD_version bump is exactly what it needs. I'll try to get that done today. On a related note, is there any way to find all ports that refer to _malloc_options without extracting source for all of them? I considered being proactive about finding software that depends on _malloc_options, but no tractable approaches came to mind. Thanks, Jason___ 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: jemalloc: jemalloc_arena.c:182: Failed assertion: p[i] == 0
On Apr 21, 2012, at 11:54 AM, David Wolfskill wrote:
After applying Dimitry Andric's patches to contrib/jemalloc and replacing
/usr/bin/as with one built last Sunday, I was finally(!) able to rebuild
head as of 234536:
FreeBSD freebeast.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #797
234536M: Sat Apr 21 10:23:33 PDT 2012
r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386
However, as I was copying a /usr/obj hierarchy via tar -- e.g.:
root@freebeast:/common/home/david # (cd /var/tmp rm -fr obj mkdir obj)
(cd /usr tar cpf - obj) | (cd /var/tmp tar xpf -)
it ran for a while, then:
jemalloc: jemalloc_arena.c:182: Failed assertion: p[i] == 0
Abort (core dumped)
root@freebeast:/common/home/david # echo $?
134
root@freebeast:/common/home/david # ls -lTio *.core
ls: No match.
root@freebeast:/common/home/david #
So ... no core file, apparently.
freebeast(10.0-C)[2] find /usr/src/contrib/jemalloc -type f -name
jemalloc_arena.c
freebeast(10.0-C)[3]
No file named jemalloc_arena.c, either.
But contrib/jemalloc/src/arena.c contains a function,
arena_chunk_validate_zeroed():
175 static inline void
176 arena_chunk_validate_zeroed(arena_chunk_t *chunk, size_t run_ind)
177 {
178 size_t i;
179 UNUSED size_t *p = (size_t *)((uintptr_t)chunk + (run_ind
LG_PAGE));
180
181 for (i = 0; i PAGE / sizeof(size_t); i++)
182 assert(p[i] == 0);
183 }
Thoughts?
I received a similar report yesterday in the context of filezilla, but didn't
get as far as reproducing it. I think the problem is in chunk_alloc_dss(),
which dangerously claims that newly allocated memory is zeroed. It looks like
I formalized this bad assumption in early 2010, though the bug existed before
that. It's a bigger deal now because sbrk() is preferred over mmap(), so the
bug has languished for a couple of years. I'll get a fix committed today (and
revert the order of preference between sbrk() and mmap()).
By the way, I wonder why not everyone hits this (I don't).
Thanks,
Jason___
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: /usr/bin/as: out of memory allocating 4194304 bytes after a total of 524288000 bytes
On Apr 20, 2012, at 12:49 PM, Dimitry Andric wrote: On 2012-04-20 15:55, Michael Pounov wrote: On Fri, 20 Apr 2012 05:57:18 -0700 David Wolfskillda...@catwhisker.org wrote: ... The update after 234416 was to 234454; the attempted buildworld failed: ... /usr/bin/as: out of memory allocating 4194304 bytes after a total of 524288000 bytes yep, I sent PR for this issue;) http://www.freebsd.org/cgi/query-pr.cgi?pr=167064 The root cause of this is the new jemalloc import in r234370. In contrib/jemalloc/src/chunk.c, this defines a global variable called 'chunksize'. At run-time, this turns out to have a value of 4194304, at least on my i386 system. However, GNU as *also* has a global variable called 'chunksize', with a very different intent: it is the default chunk size for its so-called obstacks, an internal implementation detail. It is set to zero in contrib/binutils/gas/as.c, but normally ends up as 4096 during further initialization. Now, because the variable from jemalloc ends up in libc.a, and /usr/bin/as is statically linked, the jemalloc variable overrides the one from GNU as. This causes as to allocate 4 MiB chunks instead of 4 KiB chunks for all its internal processing, and you can guess what happens with a reasonably large input file. :) I think the best solution would be for jemalloc to avoid using obvious names like chunksize for its globals, because it is basically a library that could be linked to any sort of program out there. For example, it could prefix all its internal-use only globals with jemalloc_ or some other mangling scheme. Jason, any thoughts? jemalloc has optional namespace mangling support built in for just this reason. I'll turn it on, hopefully today. Thanks, Jason___ 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: /usr/bin/as: out of memory allocating 4194304 bytes after a total of 524288000 bytes
On Apr 20, 2012, at 1:10 PM, Dimitry Andric wrote: On 2012-04-20 21:54, Jason Evans wrote: On Apr 20, 2012, at 12:49 PM, Dimitry Andric wrote: ... I think the best solution would be for jemalloc to avoid using obvious names like chunksize for its globals, because it is basically a library that could be linked to any sort of program out there. For example, it could prefix all its internal-use only globals with jemalloc_ or some other mangling scheme. Jason, any thoughts? jemalloc has optional namespace mangling support built in for just this reason. I'll turn it on, hopefully today. Indeed, I had just found jemalloc/internal/private_namespace.h. :) It does seem to list only functions, not variables, is that right? Ah right, functions only. Well then, I don't have any bright ideas for solving this problem in the short run. Jason___ 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: /usr/bin/as: out of memory allocating 4194304 bytes after a total of 524288000 bytes
On Apr 20, 2012, at 1:14 PM, Jason Evans wrote: On Apr 20, 2012, at 1:10 PM, Dimitry Andric wrote: On 2012-04-20 21:54, Jason Evans wrote: On Apr 20, 2012, at 12:49 PM, Dimitry Andric wrote: I think the best solution would be for jemalloc to avoid using obvious names like chunksize for its globals, because it is basically a library that could be linked to any sort of program out there. For example, it could prefix all its internal-use only globals with jemalloc_ or some other mangling scheme. Jason, any thoughts? jemalloc has optional namespace mangling support built in for just this reason. I'll turn it on, hopefully today. Indeed, I had just found jemalloc/internal/private_namespace.h. :) It does seem to list only functions, not variables, is that right? Ah right, functions only. Well then, I don't have any bright ideas for solving this problem in the short run. I take it back. There's spotty mangling coverage for variables. I'll try to add full coverage. Jason___ 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: [head tinderbox] failure on powerpc/powerpc
On Apr 17, 2012, at 4:26 AM, FreeBSD Tinderbox wrote: /obj/powerpc.powerpc/src/tmp/usr/lib/libc.so: undefined reference to `__sync_sub_and_fetch_8' /obj/powerpc.powerpc/src/tmp/usr/lib/libc.so: undefined reference to `__sync_add_and_fetch_8' This (and the similar error for powerpc64, arm, pc98, and i386) is due to jemalloc incorrectly trying to use compiler intrinsics on all platforms. Fortunately we have atomic(9), so I should be able to get an alternate implementation in place today. Jason___ 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
HEADSUP: /etc/malloc.conf format change
As a result of the recent jemalloc update, the format for /etc/malloc.conf has changed. If your system has an old-style /etc/malloc.conf, you will want to delete it prior to installworld, and optionally re-create it using the new format after rebooting. See malloc.conf(5) for details (specifically the TUNING section and the opt.* entries in the MALLCTL NAMESPACE section). The MALLOC_OPTIONS environment variable and the _malloc_options global do not pose the same headache, because their new counterparts are named MALLOC_CONF and malloc_conf, respectively. Jason___ 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: jemalloc: Conf string ends with key
On Apr 17, 2012, at 12:10 PM, John Nielsen wrote: On Apr 17, 2012, at 8:58 AM, O. Hartmann wrote: On 04/17/12 14:51, Ivan Klymenko wrote: В Tue, 17 Apr 2012 10:42:13 +0200 O. Hartmann ohart...@mail.zedat.fu-berlin.de пишет: remove /etc/malloc.conf simple and efficient ;-) I encountered this today as well. I set /etc/malloc.conf a long time ago and haven't thought about it much since. The new options format is documented in jemalloc(3), but I for one would have appreciated a heads-up of some sort. Should this be an entry in UPDATING? I just sent a HEADSUP email, and will add an entry to UPDATING. Thanks for the suggestion. Jason___ 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: jemalloc: Conf string ends with key
On Apr 17, 2012, at 2:06 PM, AN wrote: # uname -a jemalloc: Conf string ends with key FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #10 r234389: Tue Apr 17 16:05:11 EDT 2012 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 […] and from UPDATING i did: ln -s aj /etc/malloc.conf I read the latest entry in UPDATING. Could someone please explain how to get back to what I had, it was working well. The new jemalloc slows the system down considerably. Thanks in advance From the latest UPDATING update (wasn't part of the jemalloc commit, unfortunately): (To completely disable malloc debugging, define MALLOC_PRODUCTION in /etc/make.conf, or to merely disable the most expensive debugging functionality run ln -s 'abort:false,junk:false' /etc/malloc.conf.) Jason___ 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: contrib/jemalloc
On Apr 13, 2012, at 3:43 PM, David O'Brien wrote: On Thu, Apr 12, 2012 at 01:19:56PM -0700, Jason Evans wrote: On Apr 12, 2012, at 11:41 AM, David O'Brien wrote: It looks like you could run './FREEBSD-upgrade extract' from a check out of ssh://svn.freebsd.org/base/vendor/jemalloc. I'm unclear what the './FREEBSD-upgrade rediff' step is for. I'm having trouble following what then regenerate diffs to update line offsets is for. The 'rediff' step regenerates the diff so that it precisely matches the differences as they apply to the code about to be imported. If this step were omitted, patch fuzz would accumulate in FREEBSD-diffs. How do you handle the difference between FreeBSD having include/malloc_np.h and your GIT repo having jemalloc/include/jemalloc/jemalloc.h[.in]? Does './FREEBSD-upgrade extract' or './FREEBSD-upgrade rediff' patch 'include/malloc_np.h' and 'include/stdlib.h'? Especially with the '#define JEMALLOC_P(s) s' wrapping. Is that part of the './FREEBSD-upgrade rediff' step? stdlib.h+malloc_np.h and jemalloc.h are different enough that they require separate maintenance. Alas, not all programming can be automated; if interfaces change, manual intervention is required. contrib/jemalloc/FREEBSD-upgrade doesn't describe the commit into FreeBSD subversion repo step, that I can see. So I am not sure what gets committed vs. what's in git://canonware.com/jemalloc.git. Every difference that remains in the tree afterwards is to be committed. That might require some 'svn add' and/or 'svn rm' commands prior to 'svn commit'. The only upside to vendor branch merges I can think of is that if any jemalloc sources were manually modified between imports, merging would fail rather than silently overwriting the changes. I feel that is an important check-and-balance. Not following our established procedure also means that the average developer(committer) and commercial consumer will have their expectations fails. One expects to be able to find the stock vendor sources in ssh://svn.freebsd.org/base/vendor/ and to be able to find FreeBSD local changes to the sources thru 'svn diff' against ssh://obr...@svn.freebsd.org/base. Regarding established procedure, I read through several of the contrib/*/FREEBSD-upgrade files when trying to understand established procedure, and the conclusion I came to is that many of the vendor imports would be painful for a new person to take over. In contrast, contrib/jemalloc/FREEBSD-upgrade provides nearly complete automation, and documentation on how to deal with the manual parts of the process, should the need arise. However, this presumes that changes aren't making it upstream. That is not an unreasonable presumption. Unless contrib/jemalloc/ is locked so that you are aware of every commit FreeBSD and git://canonware.com/jemalloc.git can diverge at times. Today I updated the FREEBSD-upgrade script to take care of this possibility. http://people.freebsd.org/~jasone/patches/jemalloc_20120413a.patch One problem that doesn't fit neatly into the standard vendor import procedure is that jemalloc.3 is a generated file. It isn't feasible to keep FreeBSD-specific changes out of the vendor branch unless jemalloc's build system is imported, or manual changes are made directly to the generated file (yuck). In contrast, the FREEBSD-upgrade script leaves all non-essential files out of the imports, resulting in a cleaner import. Imagine we're looking at the svn history three years from now, and I've croaked, leaving the FreeBSD copy of jemalloc to drift where it will. svn might contain something like the following sequence of relevant commits: - (jasone) Import jemalloc 7ca0fdfb85b2a9fc7a112e158892c098e004385b. - (jasone) Import jemalloc [some other git rev]. - (jasone) Import jemalloc [some other git rev]. - (jasone) Import jemalloc 3.0.0. - (jasone) Import jemalloc 3.0.1. - (obrien) Fix aligned_alloc() to stop snatching helpless children. - (jasone) Import jemalloc 3.2.0. - (obrien) Stop protecting children; they're not as helpless as they appear. - (obrien) Import jemalloc 3.2.1. May jasone RIP. - (obrien) This allocator sucks. Gut it. What gets lost? As near as I can tell, the svn history tells the whole story, and 'svn blame' even reflects FreeBSD-specific changes that weren't made as part of an import commit (and FREEBSD-diffs provides a full audit trail for those). It's worth mentioning that the less work imports are, the more often I will be able to do them. I've put several days of effort into streamlining this process so that FreeBSD's jemalloc won't languish. I've been working more or less full time on jemalloc for the past six weeks (thanks Facebook!), but I really have to wrap this up and get back to other projects. Jason___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe
Re: contrib/jemalloc
On Apr 12, 2012, at 11:41 AM, David O'Brien wrote: On Wed, Apr 04, 2012 at 09:56:45PM -0700, Jason Evans wrote: I have the current version of jemalloc integrated into libc as contrib/jemalloc: http://people.freebsd.org/~jasone/patches/jemalloc_20120404b.patch Looking at the latest patch http://people.freebsd.org/~jasone/patches/jemalloc_20120405a.patch I cannot tell for sure if you did an 'svn move' of the files from lib/libc/stdlib/ to contrib/jemalloc/. It looks to me like they have not. If not, can you regen the diff after using 'svn move' so we maintain log history? Done now for malloc.3 -- reallocf.3 in my tree. http://people.freebsd.org/~jasone/patches/jemalloc_20120412a.patch For the rest of the code, its structure/origin is different enough that 'svn move' doesn't really apply. * Is it acceptable to check this in directly to trunk without using a vendor branch? For the import workflow I have planned, a vendor branch would just be extra work with no benefit that I can see. I do not think it is acceptable. Our workflow is to do vendor imports. They are invaluable in tracking down history and changes years after the fact. They are also very valuable to commercial third-parties that consume FreeBSD into their products (I speak for Juniper Networks in this). Why do you feel they are [measurably] extra work with no benefit? The workflow I'm using is documented in the patch (contrib/jemalloc/FREEBSD-upgrade). Can you tell me how to achieve a similarly streamlined import flow with a vendor branch in the mix? Also, what history would a vendor branch preserve that this workflow does not? The only upside to vendor branch merges I can think of is that if any jemalloc sources were manually modified between imports, merging would fail rather than silently overwriting the changes. However, this presumes that changes aren't making it upstream. Jason___ 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: contrib/jemalloc
On Apr 5, 2012, at 10:52 AM, Konstantin Belousov wrote: On Wed, Apr 04, 2012 at 09:56:45PM -0700, Jason Evans wrote: I have the current version of jemalloc integrated into libc as contrib/jemalloc: http://people.freebsd.org/~jasone/patches/jemalloc_20120404b.patch * Are the symbol versioning specifications right, and are the compatibility symbols for _malloc_options and _malloc_message workable? Why do you manually added __sys_compat() for the symbols ? My reading of the patch shows that you do not change the ABI, and symbols are still at FBSD_1.0 and even in Symbol.map. The 1.3 symbols have different names, without prepended '_' ? Please correct me if I am wrong, but it seems that the __sym_compat() magic is not needed. The malloc_conf and malloc_message symbols are new to this version of jemalloc, though they are similar in spirit to _malloc_options/_malloc_message. _malloc_options/_malloc_message aren't actually supported by this version of jemalloc, but the symbols still need to exist so that old applications that were linked with previous releases can run. My intention with the __sys_compat() macros was to make _malloc_options/_malloc_message available to those applications, but to keep from exporting the symbols for use when linking new applications. Is this the wrong thing to do, and/or do I misunderstand how compat symbols work? * Is the light editing of the jemalloc manual page sufficient? Keeping the changes minimal will make regular imports less work, but the result is less tailored to FreeBSD. Might be, keep existing but somewhat trimmed malloc(3) page as is, but add the unedited man from contrib as jemalloc(3), xreferencing it from malloc(3) ? Hmm, that's an interesting idea. My main concerns with it are the amount of redundancy (everything in malloc(3) would be redundant), and the decreased visibility of additional functionality in the documentation. The TUNING, IMPLEMENTATION NOTES, DEBUGGING MALLOC PROBLEMS, and DIAGNOSTIC MESSAGES sections would all be absent from malloc(3), thus requiring users to notice the jemalloc(3) cross reference to find full documentation. Thanks, Jason___ 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: contrib/jemalloc
On Apr 5, 2012, at 6:33 AM, John Baldwin wrote: On Thursday, April 05, 2012 12:56:45 am Jason Evans wrote: * Will the utrace feature be missed? I removed it some time ago, mainly because traces are impossibly large for most real-world use cases. I will only speak to this one. I do still find this useful (I used it most recently a week or so ago). It would be nice to keep if it is not a major pain to maintain. Okay, I re-added utrace support. It isn't very invasive, so maintainability shouldn't be a problem. http://people.freebsd.org/~jasone/patches/jemalloc_20120405a.patch Thanks, Jason___ 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
contrib/jemalloc
I have the current version of jemalloc integrated into libc as contrib/jemalloc: http://people.freebsd.org/~jasone/patches/jemalloc_20120404b.patch This is the first update to FreeBSD's jemalloc in over two years, and the differences are huge (faster, better introspection, hopefully fewer bugs). This has been stable for me across numerous buildworld/installworld iterations, as well as when running several benchmarks. There's a bugfix to openpam in the patch that des says will be obsoleted by the next vendor import, so I'm planning to let that settle before committing. In the meanwhile, I'm hoping for some review sanity checks on the following aspects of the patch: * Are the symbol versioning specifications right, and are the compatibility symbols for _malloc_options and _malloc_message workable? * Is it acceptable to check this in directly to trunk without using a vendor branch? For the import workflow I have planned, a vendor branch would just be extra work with no benefit that I can see. * Is the light editing of the jemalloc manual page sufficient? Keeping the changes minimal will make regular imports less work, but the result is less tailored to FreeBSD. * Will the utrace feature be missed? I removed it some time ago, mainly because traces are impossibly large for most real-world use cases. Thanks, Jason___ 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: TLS bug?
On 06/17/2011 02:35 PM, Marius Strobl wrote: On Fri, Jun 17, 2011 at 03:31:29PM -0400, Nathaniel W Filardo wrote: On Fri, Jun 17, 2011 at 08:07:13PM +0200, Marius Strobl wrote: Using bonnie++ I can't reproduce this (didn't try mysql) but I have I seem to have good luck reproducing it with -r 5 -s 10 -x 10 by about the third iteration. Ok, with these parameters I can reproduce it. some TLS fixes for libthr I forgot about but could be relevant here (most actually date back to 2008 when the base binutils didn't support GNUTLS for sparc64 so I couldn't test them easily). Could you please give a libthr build with the following patch a try? http://people.freebsd.org/~marius/libthr_sparc64.diff Concurrent runs both with and without those diffs still asserted. Interestingly, libc's .tbss section, even after the assertion, is still full of zeros, so it looks like something stranger than a wild-write back to .tbss. I'll go diving through the tls allocation code again when I get a minute. In combination with the below patch bonnie++ survived 100 iterations here. I'm not sure what this means though as I don't have much knowledge about TLS, I merely implemented the necessary relocations. Could be that malloc() actually requires the initial exec model for variant II. Unfortunately, it's not documented why it was added for x86. Jason, can you shed some light on this? Marius Index: malloc.c === --- malloc.c(revision 219535) +++ malloc.c(working copy) @@ -234,7 +234,7 @@ #ifdef __sparc64__ # define LG_QUANTUM 4 # define LG_SIZEOF_PTR 3 -# define TLS_MODEL/* default */ +# define TLS_MODEL__attribute__((tls_model(initial-exec))) #endif #ifdef __amd64__ # define LG_QUANTUM 4 I added the initial-exec TLS_MODEL because it is faster than the default; jemalloc in no way depends on this for correctness though, so your patch is safe. Thanks, Jason ___ 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: malloc problems in -current malloc_usable_size()
Mark Atkinson wrote: I updated my kernel/world yesterday and thunderbird 3.0.2 started core dumping after I completed the upgrade. It continued to do so on previously good operations after a full re-compile. I noticed that some jemalloc changes went in and was wondering if anyone else was noticing SEGV problems in other apps with malloc_usable_size() or ARENA problems in threaded apps? (gdb) bt #0 0x28eacb14 in malloc_usable_size () from /lib/libc.so.7 #1 0x28eadbaa in free () from /lib/libc.so.7 #2 0x2ed9ac22 in gss_release_buffer () from /usr/lib/libgssapi.so.10 This failure (segfault due to accessing an unmapped region of memory) is more subtle than I would typically expect of a malloc bug. My approach to debugging this would be to turn on tracing (see MALLOC_OPTIONS=U docs) and see if the pointer passed to free() was valid (i.e. returned by malloc/calloc/realloc, but not yet freed). Jason ___ 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: AMD AGP Bug
On Wed, Jan 30, 2002 at 11:14:48PM +0100, Gérard Roudier wrote: Linux can be fixed, but the useless writes of the existing Athlons from the very fast cache to the relatively very slow memory cannot. And all Athlon users may well pay this penalty under any OS... unless we want to disable caching. :) Have you done benchmarks to show that the speculative writes are useless often enough to cause enough memory bus contention that overall performance is degraded, despite the speedups when the speculative writes are valid? I suspect that AMD in fact performed such tests; otherwise they wouldn't have gone to the trouble of implementing speculative writes. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -CURRENT as of 14 Jan seems slow
On Wed, Jan 16, 2002 at 05:04:31PM +1100, Bruce Evans wrote: On Tue, 15 Jan 2002, David Wolfskill wrote: Date: Tue, 15 Jan 2002 16:46:17 -0800 (PST) From: John Baldwin [EMAIL PROTECTED] Two questions: 1) Do you have WITNESS on in your kernel config? Yes, in both the build machine the laptop -- since before I made a local hierarchy within my CVS repository (September 9, 2001). 2) If yes, have you tried building with a kernel without witness? No, not since I put it in to re-sync with GENERIC. I could try that, I suppose -- but as noted, I've had WITNESS in there for a while; something seems to have changed during that one 24-hr. period that affected things rather radically. And I thought it notable. :-} I gather no one else has noticed this? File locking seems to cause only the usual few percent of slowdown for each round of major locking changes. I haven't completed benchmarking the file locking pessimizations. I don't use WITNESS or INVARIANTS for benchmarking of course. Maybe the file locking changes cause much larger pessimizations when WITNESS is turned on than most locking changes. I can see how they might: WITNESS seemed to slow down creation and destruction of mutexes more than most mutex operations last time I checked, and there is a descriptor for each file and each file descriptor. Note that additional locking with witness turned on can drastically affect performance. Chances are that Alfred's changes in combination with witness are what caused the slowdown. During certain stages of the lockmgr conversion to mutexes, I saw similar performance degradations (a factor of ~5-10, IIRC). Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
On Sat, Aug 11, 2001 at 01:04:07PM -0700, John Polstra wrote: I have no argument about the keyboard probes. I just want to add that in the case of the Belkin OmniView, it should be noted that Belkin shipped a bunch of them with a couple of EPROM chips swapped accidentally. There's a page on the Belkin web site that tells how to check for it and how to fix it. Once I put the chips into the right sockets, my OmniView started working a _whole_ lot better. :-) The weird thing is, it appeared to kind of sort of work most of the time even before. So all along I assumed it was just a poorly designed device, when actually it was just assembled wrong. (I still think it's a poorly designed device, but it's a lot better than it was before I swapped the chips.) I had the same problems, and took my KVM switch apart, expecting to find the chips reversed. They were in fact installed correctly, so at least in my case, the problem exists regardless. If I'm careful to have the KVM switch on the same channel as a booting machine, and leave it on that channel until the probing is done, everything seems to work fine. Otherwise, the keyboard is not detected. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
On Sun, Aug 12, 2001 at 02:35:22PM -0700, John Polstra wrote: Maybe they swapped the labels on the chips too. :-) Well, it apparently doesn't fry anything to have the chips reversed, so maybe I should try swapping them just to make sure. =) Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: picking a DB (Re: nvi maintainer?)
On Tue, Jul 10, 2001 at 11:16:32PM +0200, Tomasz Paszkowski wrote: On Mon, Jul 09, 2001 at 05:55:56PM -0400, [EMAIL PROTECTED] wrote: Well, it started out discussing the next release of nvi and promptly concluded, that it would require upgrading dbm. So, now the issue is -- which db to pick: the currently used (buggy), the DB3 (too restrictive a license, IMO), gdbm, or something else (Net or OpenBSD's?). Does anyone have tried dxstore (http://www.dss.bc.ca/dxstore) ? I'am using it in few very big projects and it works fine. And of course it has BSD-like license. The dxstore license has the same problem as the Sleepycat DB license. In addition, it has the pesky advertising clause of the original BSD license. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pthread and write()
On Thu, Jun 07, 2001 at 09:33:22PM +1000, Idea Receiver wrote: I dont know if this is cause by -current, I have not yet try on the -stable. However, I just write here, maybe someone can help me.. :P recently, I wrote a multithread network server for my work. what it does is to accept TCP connection from remote, and then put it into a new thread. I have wrote a simulation client to test this application i wrote. The simulation client will keep opening multi connection to the server, and keep sent a 8byte structure to server using loop and sleep(1) in between each write(). Also each of the thread created by server will simply reply a 8byte structure to its client (using write() again). When the client bring up enough (between 300-1000) connection to the server, then the server will core dump around 30mis to 1hr time. After I trace the problem, I found it is cause by write() with signal 11. then i use gdb to trace out the problem. follow is what i get from gdb: Program received signal SIGSEGV, Segmentation fault. 0x28121637 in _fd_lock_backout () from /usr/lib/libc_r.so.4 can anyone plz help with this problem? is there anything important I missed? This probably isn't enough information to be able to diagnose the problem (which may very well be in your application). Please provide an example program that exhibits the behavior. Thanks, Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: background fsck
I had exactly the same thing happen to /var on an SMP test box using -current as of 16 May. It happened once out of about a half dozen panics. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: program hangs in thread scheduler
On Thu, Feb 01, 2001 at 02:08:54PM -0500, Mike Heffner wrote: Is this a problem with the thread scheduler or is this somehow related to the application? (gdb) bt #0 0x284d74cc in poll () from /usr/lib/libc.so.5 #1 0x2848ce74 in thread_kern_poll (wait_reqd=1) at /usr/src/lib/libc_r/uthread/uthread_kern.c:833 #2 0x2848c7c9 in _thread_kern_scheduler () at /usr/src/lib/libc_r/uthread/uthread_kern.c:481 #3 0xd0d0d0d0 in ?? () #4 0x282a66cc in g_main_run (loop=0x8167b40) at gmain.c:935 #5 0x281c6047 in gtk_main () from /usr/X11R6/lib/libgtk12.so.2 #6 0x80590f1 in main (argc=1, argv=0xbfbffb9c) at aim.c:610 #7 0x80576f9 in _start (arguments=0xbfbffc80 "gaim") at /usr/src/lib/csu/i386-elf/crt1.c:96 This stack trace looks more or less okay to me. The problem is probably in the application rather than in libc_r. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Voodoo3 + XFree4 + DRM - simple_lock ? :-)
On Wed, Jan 31, 2001 at 04:54:30AM +1000, Andrew Kenneth Milton wrote: However, recently simple_lock and friends seem to have disappeared, and the kernel modules make some use of them (although there is still reference to it in machine/smptests.h) It looked like I could replace them with calls to mtx_* stuff Removing the calls to simple_lock etc sure made it run a lot faster though, but, I think I'd rather have the safety. What are the 'new' corresponding structures and calls for simple_lock ? Mutexes should be used in places where simplelocks were used. With few exceptions, sleep mutexes should be used (even though simplelocks were spin locks). See mutex(9) for details. Be forewarned that there is work in progress to clean up the mutex API that will probably be checked in within a week. Transitioning from the current mutex API to the upcoming one will be trivial, but it will have to be done if you convert to mutexes in the next few days. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lock order reversal message
On Tue, Jan 30, 2001 at 01:56:26PM +0200, John Hay wrote: Booting with a kernel built from today's source (with devfs also in), I see this lock order reversal message: ### Routing daemons:. Doing IPv6 network setup:add net :::0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 net.inet6.ip6.forwarding: 0 - 0 net.inet6.ip6.accept_rtadv: 0 - 0 net.inet6.ip6.accept_rtadv: 0 - 1 lock order reversal 1st vnode interlock last acquired @ ../../kern/vfs_vnops.c:644 2nd 0xc02d5280 mntvnode @ ../../ufs/ffs/ffs_vfsops.c:940 3rd 0xc85d314c vnode interlock @ ../../ufs/ffs/ffs_vfsops.c:949 add net fe80::: gateway ::1 add net ff02::: gateway fe80::2a0:c9ff:fe8d:7c5f%fxp0 ND default interface = fxp0 IPv4 mapped IPv6 address support=YES. Additional daemons: syslogd. ### The machine is a SMP box, if that makes a difference. It does not seem to cause harm because it continue booting and I can log in. This shouldn't be a problem. The lock order reversal has been there for a long time and hasn't caused any problems, but since simplelocks were used before, we didn't have any diagnostics to tell us it was there. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Voodoo3 + XFree4 + DRM - simple_lock ? :-)
On Tue, Jan 30, 2001 at 01:18:05PM -0800, Julian Elischer wrote: Jason Evans wrote: Mutexes should be used in places where simplelocks were used. With few exceptions, sleep mutexes should be used (even though simplelocks were spin locks). See mutex(9) for details. Be forewarned that there is work in progress to clean up the mutex API that will probably be checked in within a week. Transitioning from the current mutex API to the upcoming one will be trivial, but it will have to be done if you convert to mutexes in the next few days. where can we see the new spec (or at least a sample)? This is the most recent patch. I expect that the final result will be pretty similar, though Bosko may still change a couple of details: http://people.freebsd.org/~bmilekic/code/mutex_cleanup-5.patch Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel threading: the first steps [patch]
On Sat, Jan 27, 2001 at 12:33:23AM -0800, Root Dude wrote: Here's a first step. This is very disappointing, Julian. You've duplicated work that I've already done, and if you've been paying attention at all, you know that it was already done. Even if you haven't been paying attention, I find it particularly telling that you never even sent me email about this. This is the single most flagrant lack of cooperation I have experienced while working with the FreeBSD Project. I'm truly dumbfounded. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XXX driver didn't initialize queue mtx
On Sat, Jan 27, 2001 at 12:36:41PM -0800, Matthew Jacob wrote: Oh, I suppose, I did find that... well, mainly I wanted the person who made the change to actually broadcast to NIC maintainers what the expectations were... The code that prints these warnings out has existed for a while. However, whoever added it made a bad assumption about the internals of the mutex implementation, so the code never got executed. I "fixed" it last week, so the warnings get printed now. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XXX driver didn't initialize queue mtx
On Sat, Jan 27, 2001 at 12:48:36PM -0800, Matthew Jacob wrote: Somewhere in between, Jason Evans wrote: On Sat, Jan 27, 2001 at 12:36:41PM -0800, Matthew Jacob wrote: Oh, I suppose, I did find that... well, mainly I wanted the person who made the change to actually broadcast to NIC maintainers what the expectations were... The code that prints these warnings out has existed for a while. However, whoever added it made a bad assumption about the internals of the mutex implementation, so the code never got executed. I "fixed" it last week, so the warnings get printed now. Shouldn't ether_ifattach initialize the mutex? Or do expect all drivers to initialize these prior to calling ether_ifattach? Look- I just want to know what the people who put the check in *want*. cvs annotate is your friend. The code was added in revision 1.95 of src/sys/net/if.c by Jonathan Lemon. Please talk to him about what should be done to fix the drivers. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XXX driver didn't initialize queue mtx
On Sat, Jan 27, 2001 at 03:19:04PM -0600, Jonathan Lemon wrote: Actually, the new check appears to be incorrect, as seen by the code fragments below: Whoops. I obviously looked at the wrong #define when making the change. Thanks for pointing out the mistake. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps
On Wed, Jan 24, 2001 at 03:37:24PM +0200, Maxim Sobolev wrote: "Daniel M. Eischen" wrote: For porters, the __FreeBSD_version has been bumped to 500016 to reflect the above change. Could you please bump version number of libc/libc_r shared libraries, so the programs linked with older version will still work correctly? AFAIK, we don't bump library version numbers for -current. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cy.c doesn't compile in LINT
On Wed, Jan 24, 2001 at 09:21:06PM +0100, Poul-Henning Kamp wrote: cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../dev -I../../../include -I../../contrib/dev/acpica/Subsystem/Include -DGPROF -DGPROF4 -DGUPROF -D_KERNEL -include opt_global.h -elf -malign-functions=4 -fno-builtin -mpreferred-stack-boundary=2 -pg -mprofiler-epilogue ../../i386/isa/cy.c ../../i386/isa/cy.c: In function `cy_units': ../../i386/isa/cy.c:447: warning: `firmware_version' might be used uninitialized in this function ../../i386/isa/cy.c: In function `cyopen': ../../i386/isa/cy.c:783: warning: implicit declaration of function `mtx_enter' ../../i386/isa/cy.c:783: `MTX_SPIN' undeclared (first use in this function) ../../i386/isa/cy.c:783: (Each undeclared identifier is reported only once ../../i386/isa/cy.c:783: for each function it appears in.) ../../i386/isa/cy.c:789: warning: implicit declaration of function `mtx_exit' ../../i386/isa/cy.c: In function `cyhardclose': ../../i386/isa/cy.c:889: `MTX_SPIN' undeclared (first use in this function) ../../i386/isa/cy.c: In function `cyinput': ../../i386/isa/cy.c:1035: `MTX_SPIN' undeclared (first use in this function) ../../i386/isa/cy.c: In function `cyintr': ../../i386/isa/cy.c:1117: `MTX_SPIN' undeclared (first use in this function) ../../i386/isa/cy.c: In function `cypoll': ../../i386/isa/cy.c:1783: `MTX_SPIN' undeclared (first use in this function) ../../i386/isa/cy.c: In function `cyparam': ../../i386/isa/cy.c:2029: `MTX_SPIN' undeclared (first use in this function) ../../i386/isa/cy.c: In function `cysetwater': ../../i386/isa/cy.c:2284: `MTX_SPIN' undeclared (first use in this function) ../../i386/isa/cy.c: In function `cystart': ../../i386/isa/cy.c:2332: `MTX_SPIN' undeclared (first use in this function) ../../i386/isa/cy.c: In function `cystop': ../../i386/isa/cy.c:2477: `MTX_SPIN' undeclared (first use in this function) ../../i386/isa/cy.c: In function `cymctl': ../../i386/isa/cy.c:2557: `MTX_SPIN' undeclared (first use in this function) ../../i386/isa/cy.c: In function `cywakeup': ../../i386/isa/cy.c:2669: `MTX_SPIN' undeclared (first use in this function) ../../i386/isa/cy.c: In function `cd_etc': ../../i386/isa/cy.c:2840: `MTX_SPIN' undeclared (first use in this function) ../../i386/isa/cy.c: In function `cd_getreg': ../../i386/isa/cy.c:2884: `MTX_SPIN' undeclared (first use in this function) ../../i386/isa/cy.c: In function `cd_setreg': ../../i386/isa/cy.c:2913: `MTX_SPIN' undeclared (first use in this function) *** Error code 1 Stop in /syv/src/sys/compile/LINT. syv# This looks to be due to the simplelock changes. I'm a bit confused as to why LINT compiled fine for me... I'll take a look at it as soon as I get a chance. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current panics in mount(2)
On Mon, Jan 22, 2001 at 12:16:38PM -0800, Mike Smith wrote: In the meantime, perhaps we could ask that one of the SMPng rules of engagement mandate that no mutex structures or structure members should ever be exported as part of a userspace interface? This sounds fine in principle, but the real problem is that kernel structures are exported. In order for us to fix some of the places where structures are exported and an embedded mutex becomes necessary, we would have to go out of our way to fix an existing design flaw. Under normal circumstances, I would agree with you that broken code should be fixed as it is modified. However, the amount of work that the SMPng project is already taking on is overwhelming. Placing this additional burden on the SMPng developers would in my opinion be detrimental to the medium-term success of the project. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
WITNESS may cause failed boot, patch available
Peter Wemm noticed that WITNESS currently causes a kernel trap the alpha. The bug also exists on x86, but does not necessarily cause any problems. If you run into problems (probably during boot), there is a patch available that should fix the WITNESS problem: http://people.freebsd.org/~jasone/diffs/mutex_f_3.diff Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: WITNESS may cause failed boot, patch available
On Sun, Jan 21, 2001 at 01:06:15PM -0500, Bosko Milekic wrote: http://people.freebsd.org/~jasone/diffs/mutex_f_3.diff This looks like a variation of Peter's mutex.diff which moves a bunch of macros to kern/kern_mutex.c from sys/mutex.h - so is it final now that we will move them there? It was one of the things I expected to happen as part of the mutex API and inlining cleanup, but it was necessary to either move a bunch of mutex implementation details out of mutex.h, or to expose even more implementation details in order to fix the WITNESS breakage, so I did the former. By the way, Peter helped me clean this patch up, so there isn't a conflict of interest between the two patches. I just wish this could have waited until your mutex cleanups were ready. =) Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Debugging SMP instability (was Re: HEADS-UP: await/asleep removal imminent)
On Wed, Jan 17, 2001 at 07:42:26PM +0100, Soren Schmidt wrote: Basically if you're expecting me or the SMP team to figure out what's going on without more info, you're pretty much out of luck. See above, not really possible, we have been trying to find some (affordable) HW that could be used to preserve a log over a boot, but so far I havn't been able to find anything that works, and is fast enough to not effect the system too much... I did some research on this and am convinced that at least some video cards would work as memory buffers for KTR logs. Specifically, someone mentioned to me yesterday that their Matrox Millennium II flashes the X desktop during startup from a previous invocation across warm boots. (I pursued some alternatives and found the PCI RAM cards to be prohibitively expensive (more than $700), and sound cards to not have enough RAM except on old SoundBlaster AWE cards.) For someone with device driver experience, I expect it would be a few hours of effort to make it possible to use a second video card (or even the primary one for that matter) as a DMA region in which KTR logs can be saved, so that there is a way to debug even these spontaneous reboots you're having. Maybe I'll eventually get to implementing this myself, but to be honest, I don't have a driving need for it right now, whereas you do. =) You're experiencing a stability problem that none of us (SMPng people) can reproduce. We'd love to fix the problem, but without more information, your reports are only slightly more useful than the typical newbie "it's broken" reports, though certainly more frustrating. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
termios.h patch for review
A while back I was porting an sshd implementation that was developed on NetBSD to FreeBSD, and discovered that some definitions are missing in our termios.h. I looked at the SUSv2 standard, and it appears to me that this is a bug in FreeBSD. Can someone who is more knowledgeable in this area please take a look at the following patch and tell me if it is correct? Thanks, Jason Index: sys/sys/termios.h === RCS file: /home/ncvs/src/sys/sys/termios.h,v retrieving revision 1.14 diff -u -r1.14 termios.h --- sys/sys/termios.h 2000/11/28 20:03:23 1.14 +++ sys/sys/termios.h 2000/12/05 02:28:16 @@ -112,6 +112,9 @@ #define ONLCR 0x0002 /* map NL to CR-NL (ala CRMOD) */ #define OXTABS 0x0004 /* expand tabs to spaces */ #define ONOEOT 0x0008 /* discard EOT's (^D) on output) */ +#define OCRNL 0x0010 /* map CR to NL on output */ +#define ONOCR 0x0020 /* no CR output at column 0 */ +#define ONLRET 0x0040 /* NL performs CR function */ #endif /*_POSIX_SOURCE */ /* To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: termios.h patch for review
On Thu, Dec 28, 2000 at 06:12:32PM -0800, Alfred Perlstein wrote: * Jason Evans [EMAIL PROTECTED] [001228 11:48] wrote: A while back I was porting an sshd implementation that was developed on NetBSD to FreeBSD, and discovered that some definitions are missing in our termios.h. I looked at the SUSv2 standard, and it appears to me that this is a bug in FreeBSD. Can someone who is more knowledgeable in this area please take a look at the following patch and tell me if it is correct? My concern is that just adding these defines doesn't actually implement anything in the drivers/libraries. :) Yes, Garrett told me the same thing. I thought there was a reason I didn't just commit the patch back when I noticed the problem... =) Have you taken a look at linux/glibc to see what these flags are actually supposed to do? No, but I read SUSv2 to see what the flags are supposed to do. The comments in the patch reflect what I read there: +#define OCRNL 0x0010 /* map CR to NL on output */ +#define ONOCR 0x0020 /* no CR output at column 0 */ +#define ONLRET 0x0040 /* NL performs CR function */ Anway, it seems that the answer is that the patch isn't acceptable by itself, so I'll try to look at it in more detail, unless someone beats me to it. Thanks, Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: debug build of libc_r
On Mon, Dec 18, 2000 at 12:01:19PM -0600, Peter Schultz wrote: Hi, I'm seeing a crash related to libc_r. Could someone please instruct me as to how to build a debug version. cd /usr/src/lib/libc_r make clean DEBUG_FLAGS=-g3 make make install Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ssh and scp fail connecting to a root account
On Fri, Sep 15, 2000 at 03:40:12PM +0100, Konstantin Chuguev wrote: Udo Schweigert wrote: after a fresh build of -current openssh does not work if connecting to the root-user. For example (tested from a -stable machine, but the same from 4.1-RELEASE): Yes, I've been seeing the same thing since the checkout of the SMPng stuff... No idea why it's happening. I've seen similar things intermittently over the past 10 days, and specifically the same problem for the past three days or so. I'm pretty sure that the problems have been associated with the random device rather than the SMP work specifically. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP mega-commit complete
On Thu, Sep 07, 2000 at 03:31:06PM -0400, Wesley Morgan wrote: On Wed, 6 Sep 2000, Jason Evans wrote: A static tag, named PRE_SMPNG, was created at 18:00 PDT. The SMP patches have now been committed. Is it safe to follow src-sys from PRE_SMPNG and everything else as -current? top and ps won't work quite right if you do that. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
SMP mega-commit complete
A static tag, named PRE_SMPNG, was created at 18:00 PDT. The SMP patches have now been committed. There are a number of known issues, and we are actively tracking them on the SMP web page at: http://people.freebsd.org/~jasone/smp/ If you run into issues that appear related to the SMP changes, and they aren't listed as known issues, please bring them up on the -smp or -current mailing list. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP: SMP code commit iminent
In compliance with the SMP project announcement (archived at http://people.freebsd.org/~jasone/smp/smp_project_announcement.txt), this email is a minimum 24 hour notice that SMP code will be committed to -current. A large patch including major changes to how the kernel works will be checked in sometime after 6 September, 18:00 PST. Also in compliance with the SMP project announcement, a static tag will be created between the above-mentioned time and when the actual commit is done. If you have questions or issues, make sure to first read the original project announcement (URL above) before sending email to the lists. For more extensive information about the SMP project, see the project web page at: http://people.freebsd.org/~jasone/smp/ Let the fun begin! Jason Evans SMP Project Manager To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: SMP code commit iminent
On Tue, Sep 05, 2000 at 06:37:38PM -0700, David O'Brien wrote: What is the status of the Alpha bits? Will we have a working kernel after the commit, or should we site tight for a week while the Alpha bits are tweaked into working status? It should work (compile and run), though interrupt threads will not be enabled. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: SMP code commit iminent
[-smp dropped from cc list.] On Tue, Sep 05, 2000 at 09:57:05PM -0700, Matthew Jacob wrote: Jason- I think we'd all appreciate a UTC timestamp suitable for -D that we can all use to checkout stuff prior to the big change. I initially wrote: Also in compliance with the SMP project announcement, a static tag will be created between the above-mentioned time and when the actual commit is done. Good enough? Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Destabilization due to SMP development
On Sun, Aug 20, 2000 at 12:14:05PM +, Nik Clayton wrote: On Mon, Jun 19, 2000 at 11:53:30AM -0700, Jason Evans wrote: Summary: -current will be destabilized for an extended period (on the order of months). A tag (not a branch) will be laid down before the initial checkin, and non-developers should either stick closely to that tag until the kernel stabilizes, or expect large doses of pain. This tag will be laid down as soon as June 26, 00:00 PST, with a minimum 24 hour warning beforehand. Is there any news on this work? Unless I've missed the significance of recent commits, I haven't seen anything approaching this sort of destabilisation in -current. No, there has not been a commit yet, but we're quite close at this point to making one. Chances are good that this will happen within the next two weeks. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP locking primities (was Re: HEADS UP: Destabilization due to SMP development)
On Tue, Jun 20, 2000 at 09:41:57AM +0200, Poul-Henning Kamp wrote: Am I the only person who miss a brief document which tells what the outcome of the meeting was ? I'm at USENIX right now, so I'm a bit strapped for time to work on this. Still, I plan to email a brief summary of the meeting within the next couple of days. It won't include all of the gory details, simply because I don't remember all of them(my notes were mainly for my own benefit, and are of limited usefulness). Can we get to see the slides ? I have the slides, but need to get them on a web page. This will also happen in the next couple of days. Audio ? Video ? Greg Lehey has a PAL recording of much of the meeting. If you want to get ahold of a copy, talk to him privately to see what arrangements you can make. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP: Destabilization due to SMP development
Summary: -current will be destabilized for an extended period (on the order of months). A tag (not a branch) will be laid down before the initial checkin, and non-developers should either stick closely to that tag until the kernel stabilizes, or expect large doses of pain. This tag will be laid down as soon as June 26, 00:00 PST, with a minimum 24 hour warning beforehand. --- Last week, approximately 20 BSD developers got together and discussed how to move FreeBSD's SMP support to the next level. Our effort will be largely based on the work that has been done in BSD/OS, which should make things go much more smoothly than they otherwise might, but we still expect -current to be destabilized for an extended period of time. Matthew Dillon is currently working on the locking primitives, as well as some changes to the way our top-level kernel locking works. His initial code will not remove spl()s. This code will probably be committed as the first step, as soon as June 26, 00:00 PST, and Peter Wemm will lay a tag down just beforehand. We will give at least 24 hours notice before the tag is laid down. Be forewarned: if you are doing anything with -current besides FreeBSD development, you will probably want to stop tracking -current at that point for a while. Greg Lehey will be working on the initial cutover to interrupt threads (as well as the lazy interrupt thread context switching code later on). spl()s will go away as soon as interrupt threads start working. Once interrupt threads are working, most of the remaining work of threading the kernel will be able to go on in parallel. Device driver maintainers will be able to convert device drivers over a period of several months. We expect to have a compatibility shim in place initially, but there will be a hard cutoff date sometime before the release of FreeBSD 5.0 where the compatibility shim is removed. Before getting too excited about this part of the conversion to a threaded kernel, please keep in mind that 1) there will be plenty of time to do this conversion, 2) the conversion is pretty trivial for most drivers, and 3) as we get to the stage where the conversion becomes possible, there will be much more detail about how to do the conversion, as well as the working examples of the first drivers to be converted. The addition of kernel support for scheduler activations is generally a separate project, but there are some interdependencies between the SMP and scheduler activations changes, especially in the scheduler and the proc structure. There are many other SMP-related changes that will be made to the kernel that are not specifically mentioned in this email, since they are not of significant interest from a grand overview perspective. However, there are many details, and if you want to follow the technical discussions, you will want to be subscribed to at least the -current and -smp mailing lists. Finally, here are some notes about the organization of this effort. I was cajoled into acting as the manager of this effort. That doesn't mean I'm going to do all (or even a major part) of the work; it merely means I'm the focal point of communications and decisions made with regard to the project. Right now, there are at least a dozen highly capable FreeBSD developers that have taken an interest in working on this project. We, as a group, have made a number of decisions about how to attack this project. If you want to contribute to technical aspects of the project, please jump in. However, consider that the general direction we're taking with the SMP effort is the result of a number of very knowledgeable people hashing this out over a period of two days; don't expect that direction to change in the short-term. So, if you have grievances about the way this project is being run, complain to me, but please let the other developers work on this in relative peace. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
SMP locking primities (was Re: HEADS UP: Destabilization due to SMP development)
On Mon, Jun 19, 2000 at 05:34:47PM -0700, Matthew Dillon wrote: Ok, I have put up a web page that will track my efforts. http://apollo.backplane.com/FreeBSDSmp/ On this page, you say: The algorithms described on this page are essentially the BSDI algorithms plus accomodations we disussed at the Yahoo SMP meeting. However, I did not do a direct port. I did a from-scratch rewrite because, simply put, it was easier for me. The variables are named differently but I attempt to follow the same API. All the work is subject to change... the point is to make it work first, then clean it up later. Does this include the locking primitives? In the case of the locking primitives, there is functionality that we definitely need, such as the witness code, and it probably would save effort to use the BSD/OS code. I'm guessing that you are actually using the BSD/OS code in this case; I'm just looking for clarification. Thanks, Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mysql FreeBSD 4.0 problem
On Wed, Mar 15, 2000 at 11:51:52AM +0300, Zherdev Anatoly wrote: Hello. I have some problem with MySQL 4.0 If MySQL compile -static on last snapshots (I tried snapshots 2214 2313), mysqld don't work correctly. After starting mysqld listen port and don't print errors, but telnet localhost 3306 don't write mysql version (mysqld nothing print :( ) and mysql client can't connect too. Telnet don't break connection while i don't kill mysqld. Mysql dynamicaly compiled work correct (mysqld print version number if connect on it port). On old snapshots (i tried on 2112) and FreeBSD 3.x (i tried 3.4 stable 2125) all work OK. I test it on different computers SMP/non SMP. I added additional support for pthread_cancel() on 27 January that doesn't interact with the static linker well. This is almost surely the reason you're having problems. I'm very close (an hour, maybe) to checking a fix into the RELENG_4 branch, as well as the head. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Weak symbols in libc_r broken?
On Mon, Mar 13, 2000 at 06:12:22PM +1100, John Birrell wrote: I deleted the weak definitions in the _THREAD_SAFE PRSYSCALL in lib/libc/i386/SYS.h and the problem goes away. I don't understand why Jason needed to add them in the first place. I didn't need to add them. At some point during all the changes I made, I mistakenly got it in my mind that the weak aliases had been there before I started mucking with things, and therefore I, uh, left them there. =) Unfortunately, I didn't notice this problem until a week ago, and it was only this weekend that I understood the root of the problem. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pthread_{suspend,resume}_np broken?
On Wed, Mar 01, 2000 at 09:30:43AM -0500, Daniel M. Eischen wrote: I haven't run any other regression tests. I'll do that when I get some more time. Jason, can you also take a look at these changes and run some tests on them? I just moved a couple of days ago and all my test boxes are still in boxes. It will be at least a couple of days before I can test this properly. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: tentitive complete patch for MAP_GUARDED available
On Fri, Feb 18, 2000 at 11:05:31AM -0800, Matthew Dillon wrote: I also think that a single guard page at the base of the stack may be insufficient for some applications. I'm considering adding yet another field to vm_map_entry 'vm_pindex_t guard_pages' which allows the number of guard pages to be specified (we can use mmap()'s offset argument to pass the parameter). In general, a given number of guard pages is insufficient for some (perhaps non-existent) applications. The basic idea is to catch typical stack overflow. Trying to always catch stack overflow is not practical. Since this is a heuristic error detection technique, I'm not sure how much work/complexity it's worth to paramaterize the number of guard pages for each mapping. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pthread.h and unistd.h
On Thu, Feb 17, 2000 at 11:29:57AM -0500, Daniel Eischen wrote: How about we remove the #if defined()s for: _POSIX_THREAD_PROCESS_SHARED _POSIX_THREAD_PRIO_PROTECT _POSIX_THREAD_PRIO_INHERIT _POSIX_THREAD_PRIORITY_SCHEDULING from our pthread.h? Yes, it looks like use of the last three should be removed from pthread.h. I'll submit a patch to Jordan. Thanks, Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Heads up, vm.max_proc_mmap sysctl added
On Wed, Feb 16, 2000 at 01:18:13PM -0800, Matthew Dillon wrote: This deals with a mmap+fork bomb that can cause the kernel to eat all of KVM in vm_map_entry structures. The default limit should be set generously enough for people using the current FreeBSD threads incarnation (and isn't an issue w/ linux threads due to rfork resulting in scaling of the limit for the shared address space). Heads up in case a heavy threads programmer sees something I missed. Note that thread stack allocation in libc_r also uses mmap() (one region per thread), so this applies there as well. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Heads up, vm.max_proc_mmap sysctl added
On Wed, Feb 16, 2000 at 02:13:39PM -0800, Jason Evans wrote: On Wed, Feb 16, 2000 at 01:18:13PM -0800, Matthew Dillon wrote: This deals with a mmap+fork bomb that can cause the kernel to eat all of KVM in vm_map_entry structures. The default limit should be set generously enough for people using the current FreeBSD threads incarnation (and isn't an issue w/ linux threads due to rfork resulting in scaling of the limit for the shared address space). Heads up in case a heavy threads programmer sees something I missed. Note that thread stack allocation in libc_r also uses mmap() (one region per thread), so this applies there as well. Never mind. Matt stated this correctly, and I misread it. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Heads up, vm.max_proc_mmap sysctl added
On Wed, Feb 16, 2000 at 03:33:58PM -0800, Matthew Dillon wrote: Is anyone interested in me doing this for the 4.0 release? It would help both our current threads model and the linux threads model a lot. I can do it in a day and it should be trivial to test, the modifications are actually quite minor. I would really like to see this change happen, and will happily make the necessary libc_r and linuxthreads changes to use the functionality, but we're well into the code freeze right now, which IMO makes this more appropriate for 4.1. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: This is getting ridiculous..
On Fri, Jan 28, 2000 at 12:05:21AM -0800, Kris Kennaway wrote: /home/kris/tmp/world/obj/.amd_mnt/freefall/host/c/users/kris/tmp/world/src/alpha/.amd_mnt/freefall/host/c/users/kris/tmp/world/src/gnu/usr.bin/cc/cpp/../cc_int/libcc_int.a(choose-temp.o): In function `choose_temp_base': choose-temp.c(.text+0x218): warning: mktemp() possibly used unsafely; consider using mkstemp() /home/kris/tmp/world/obj/.amd_mnt/freefall/host/c/users/kris/tmp/world/src/alpha/.amd_mnt/freefall/host/c/users/kris/tmp/world/src/gnu/usr.bin/cc/cpp/../cc_fbsd/libcc_fbsd.a(mktemp.o): In function `_gettemp': mktemp.c(.text+0x3f0): undefined reference to `_open' mktemp.c(.text+0x3f4): undefined reference to `_open' *** Error code 1 1 error This is from a freshly checked-out tree on beast, with no local mods outside of secure/. I've verified twice it's up-to-date with CVS.. I'm still trying to test this patch before committing. Jason Index: SYS.h === RCS file: /home/ncvs/src/lib/libc/alpha/SYS.h,v retrieving revision 1.9 diff -u -r1.9 SYS.h --- SYS.h 2000/01/27 23:06:02 1.9 +++ SYS.h 2000/01/28 08:15:20 @@ -104,7 +104,7 @@ #definePSYSCALL(name) \ PLEAF(name,0); /* XXX # of args? */\ - WEAK_ALIAS(__CONCAT(_thread_sys_,name), name); \ + WEAK_ALIAS(__CONCAT(_,name), name); \ CALLSYS_ERROR(name) #definePRSYSCALL(name) \ @@ -115,7 +115,7 @@ #definePPSEUDO(label,name) \ PLEAF(label,0);/* XXX # of args? */\ - WEAK_ALIAS(__CONCAT(_thread_sys_,name), name); \ + WEAK_ALIAS(__CONCAT(_,name), name); \ CALLSYS_ERROR(name);\ RET;\ PEND(label) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RFC: buildworld breakage due to cross-tools/libc/mktemp.
On Wed, Jan 19, 2000 at 01:36:43AM -0800, David O'Brien wrote: On Thu, Jan 13, 2000 at 06:53:25AM -0500, Daniel Eischen wrote: On Wed, 12 Jan 2000, David O'Brien wrote: I don't see why a plain function like mkstemp() should be written so specially. Couldn't all the hiding/changing done for threads be done w/in open() itself? Neither HP-UX 10.30 (which has kernel threads), nor Solaris 7 needs such open() hackery in mkstemp(). Given where we want to go with pthreads, and the proposed architecture, I'm not sure why we need to have open - _libc_open - __open (or whatever it is). Why isn't using _open internally in libc sufficient? open is a weak symbol for _open, and libpthread can override the open (weak symbol). Is this email being ignored? No, I was just busy doing other things. There is potentially one good reason to leave these changes in place for now: they allow proper thread cancellation in libc_r as it stands right now. This seems to me like a good enough reason to leave the changes as is until our grand new threads library is realized. However, I agree that in the end we will want to simplify the libc symbol naming. I'm planning on checking in libc_r cancellation changes today that use the current libc symbol naming setup. As soon as we're not using libc_r anymore I'll be glad to simplify the symbol naming. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RFC: buildworld breakage due to cross-tools/libc/mktemp.
On Wed, Jan 19, 2000 at 12:21:50PM -0500, Daniel Eischen wrote:
No, I was just busy doing other things.
There is potentially one good reason to leave these changes in place for
now: they allow proper thread cancellation in libc_r as it stands right
now. This seems to me like a good enough reason to leave the changes as is
until our grand new threads library is realized. However, I agree that in
the end we will want to simplify the libc symbol naming.
I'm planning on checking in libc_r cancellation changes today that use the
current libc symbol naming setup. As soon as we're not using libc_r
anymore I'll be glad to simplify the symbol naming.
I guess I'm confused as to why you can't do what you need with
_XXX (internally used, non-cancellable function) and XXX (weak
reference to _XXX) within libc. libc_r would provide XXX that
did something along the lines of:
int
XXX(void)
{
enter_cancellation_point();
_XXX();
leave_cancellation_point();
return(0);
}
Doen't that method still have the problem of propagating cancellation
points within the libc code? In another email I argued for the need for
three names, and your response was that three names aren't needed in the
context of the next-generation threads library, but it seems to me that in
the case of libc_r, three names really are needed in order to do
cancellation correctly. Following is a revised version of my previous
email (changed to reflect libc_r rather than libpthread):
It isn't adequate to only have two names with libc_r. There have to be:
1) _open() -- A name to access the actual system call.
2) _libc_open() -- A name that libc uses internally which by default is the
same as _open(), but can be overridden.
3) open() -- The name that an application uses (and cancellation point).
If we were to remove _libc_open() and use open() instead inside of libc, we
would incorrectly propagate cancellation points (as is the case right now,
since _libc_open() and open() are the same in libc_r).
If we were to remove _libc_open() and use _open() instead inside of libc,
then we would have the problem of some libc functions using system calls
directly, where libc_r needs to do call conversion and/or extra bookkeeping
work.
Jason
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Make world breakage...
On Thu, Jan 13, 2000 at 08:35:16PM +0100, Wilko Bulte wrote: I resurrected things by grabbing an 'old' .4 library from another Alpha. Now things work again. In case you missed it, I checked in a probable fix for the bug that got you last time around. You might try again now. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Buildworld Breakage
On Wed, Jan 12, 2000 at 02:57:41PM +0100, Pascal Hofstee wrote: With my CURRENT-tre updated within an hour ago ... Buildworld is broken. cc -O -pipe -DFREEBSD_NATIVE -DIN_GCC -DHAVE_CONFIG_H -DDEFAULT_TARGET_VERSION=\ "2.95.2\" -DDEFAULT_TARGET_MACHINE=\"i386-unknown-freebsd\" -DPREFIX=\"/usr/obj/usr/src/i386/usr\" -I/usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cpp/../cc_tools -I/usr/src/gnu/usr.bin/cc/cpp/../cc_tools -I/usr/src/gnu/usr.bin/cc/cpp/../../ ../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cpp/../../../../contrib/gcc/config -I/usr/obj/usr/src/i386/usr/include -o cpp gcc.o cppspec.o /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cpp/../cc_drv/libcc_drv.a /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cpp/../cc_fbsd/libcc_fbsd.a /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cpp/../cc_drv/libcc_drv.a(choose-te mp.o): In function `choose_temp_base': choose-temp.o(.text+0x13e): warning: mktemp() possibly used unsafely; consider using mkstemp() /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cpp/../cc_fbsd/libcc_fbsd.a(mktemp. o): In function `mktemp': mktemp.o(.text+0x1e1): undefined reference to `_libc_open' *** Error code 1 Stop in /usr/src/gnu/usr.bin/cc/cpp. *** Error code 1 Stop in /usr/src/gnu/usr.bin/cc. *** Error code 1 This looks like possible breakage related to the changes to libc that I committed early this morning. The thing is, I successfully built the world with those changes in place. It may be that you got a partial update of the ~150 files that the changes touched in libc and libc_r. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Make world breakage...
On Wed, Jan 12, 2000 at 09:56:22PM +0200, Mark Murray wrote: Hi Anyone else seeing this? cc -O -pipe -DFREEBSD_NATIVE -DIN_GCC -DHAVE_CONFIG_H -DDEFAULT_TARGET_VERSION=\"2.95.2\" -DDEFAULT_TARGET_MACHINE=\"i386-unknown-freebsd\" -DPREFIX=\"/usr/obj/usr/src/i386/usr\" -I/usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cpp/../cc_tools -I/usr/src/gnu/usr.bin/cc/cpp/../cc_tools -I/usr/src/gnu/usr.bin/cc/cpp/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cpp/../../../../contrib/gcc/config-I/usr/obj/usr/src/i386/usr/include -o cpp gcc.o cppspec.o /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cpp/../cc_drv/libcc_drv.a /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cpp/../cc_fbsd/libcc_fbsd.a /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cpp/../cc_drv/libcc_drv.a(choose-temp.o): In function `choose_temp_base': choose-temp.o(.text+0x13e): warning: mktemp() possibly used unsafely; consider using mkstemp() /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cpp/../cc_fbsd/libcc_fbsd.a(mktemp. o): In function `mktemp': mktemp.o(.text+0x1e1): undefined reference to `_libc_open' *** Error code 1 Stop in /usr/src/gnu/usr.bin/cc/cpp. *** Error code 1 Yes, three others have reported it as well. On the surface, it looks like my fault, but I'm still in the process of trying to reproduce it (my most recent buildworld went off without a hitch). Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Buildworld Breakage
On Wed, Jan 12, 2000 at 11:16:38AM -0800, Jason Evans wrote: On Wed, Jan 12, 2000 at 02:57:41PM +0100, Pascal Hofstee wrote: With my CURRENT-tre updated within an hour ago ... Buildworld is broken. cc -O -pipe -DFREEBSD_NATIVE -DIN_GCC -DHAVE_CONFIG_H -DDEFAULT_TARGET_VERSION=\ "2.95.2\" -DDEFAULT_TARGET_MACHINE=\"i386-unknown-freebsd\" -DPREFIX=\"/usr/obj/usr/src/i386/usr\" -I/usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cpp/../cc_tools -I/usr/src/gnu/usr.bin/cc/cpp/../cc_tools -I/usr/src/gnu/usr.bin/cc/cpp/../../ ../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cpp/../../../../contrib/gcc/config -I/usr/obj/usr/src/i386/usr/include -o cpp gcc.o cppspec.o /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cpp/../cc_drv/libcc_drv.a /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cpp/../cc_fbsd/libcc_fbsd.a /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cpp/../cc_drv/libcc_drv.a(choose-te mp.o): In function `choose_temp_base': choose-temp.o(.text+0x13e): warning: mktemp() possibly used unsafely; consider using mkstemp() /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cpp/../cc_fbsd/libcc_fbsd.a(mktemp. o): In function `mktemp': mktemp.o(.text+0x1e1): undefined reference to `_libc_open' *** Error code 1 Stop in /usr/src/gnu/usr.bin/cc/cpp. *** Error code 1 Stop in /usr/src/gnu/usr.bin/cc. *** Error code 1 This looks like possible breakage related to the changes to libc that I committed early this morning. The thing is, I successfully built the world with those changes in place. It may be that you got a partial update of the ~150 files that the changes touched in libc and libc_r. Okay, this is a bootstrapping issue. I didn't run into it because I manually installed libc during testing, before doing a buildworld. Doing the following before a buildworld should allow the buildworld to complete: cd /usr/src/lib/libc make make install Then buildworld. I'm not very well versed in the buildworld bootstrapping, so any help in fixing this the right way would be appreciated. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Make world breakage...
On Wed, Jan 12, 2000 at 10:07:25PM +0100, Wilko Bulte wrote: On Wed, Jan 12, 2000 at 09:56:22PM +0200, Mark Murray wrote: Hi Anyone else seeing this? cc -O -pipe -DFREEBSD_NATIVE -DIN_GCC -DHAVE_CONFIG_H -DDEFAULT_TARGET_VERSION=\"2.95.2\" -DDEFAULT_TARGET_MACHINE=\"i386-unknown-freebsd\" -DPREFIX=\"/usr/obj/usr/src/i386/usr\" -I/usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cpp/../cc_tools -I/usr/src/gnu/usr.bin/cc/cpp/../cc_tools -I/usr/src/gnu/usr.bin/cc/cpp/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cpp/../../../../contrib/gcc/config-I/usr/obj/usr/src/i386/usr/include -o cpp gcc.o cppspec.o /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cpp/../cc_drv/libcc_drv.a /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cpp/../cc_fbsd/libcc_fbsd.a /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cpp/../cc_drv/libcc_drv.a(choose-temp.o): In function `choose_temp_base': choose-temp.o(.text+0x13e): warning: mktemp() possibly used unsafely; consider using mkstemp() /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cpp/../cc_fbsd/libcc_fbsd.a(mktemp. o): In function `mktemp': mktemp.o(.text+0x1e1): undefined reference to `_libc_open' *** Error code 1 Stop in /usr/src/gnu/usr.bin/cc/cpp. *** Error code 1 Yep. Also on Alpha: /usr/obj/usr/src/alpha/usr/src/gnu/usr.bin/cc/cpp/../cc_drv/libcc_drv.a(choose-temp.o): In function `choose_temp_base': choose-temp.c(.text+0x218): warning: mktemp() possibly used unsafely; consider using mkstemp() /usr/obj/usr/src/alpha/usr/src/gnu/usr.bin/cc/cpp/../cc_fbsd/libcc_fbsd.a(mktemp.o): In function `_gettemp': mktemp.c(.text+0x3f0): undefined reference to `_libc_open' mktemp.c(.text+0x3f4): undefined reference to `_libc_open' *** Error code 1 Stop in /usr/src/gnu/usr.bin/cc/cpp. *** Error code 1 libc successfully builds on Alpha with the changes I committed, though the bootstrapping problem issue is the same. As noted in another email I just sent, do: cd /usr/src/lib/libc make make install before doing a buildworld. This probably isn't the correct way of resolving such bootstrapping issues, but it works. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Make world breakage...
On Thu, Jan 13, 2000 at 12:16:31AM +0100, Wilko Bulte wrote: On Wed, Jan 12, 2000 at 01:22:25PM -0800, Jason Evans wrote: On Wed, Jan 12, 2000 at 10:07:25PM +0100, Wilko Bulte wrote: On Wed, Jan 12, 2000 at 09:56:22PM +0200, Mark Murray wrote: Hi Anyone else seeing this? ... /usr/obj/usr/src/alpha/usr/src/gnu/usr.bin/cc/cpp/../cc_fbsd/libcc_fbsd.a(mktemp.o) In function `_gettemp': mktemp.c(.text+0x3f0): undefined reference to `_libc_open' mktemp.c(.text+0x3f4): undefined reference to `_libc_open' *** Error code 1 Stop in /usr/src/gnu/usr.bin/cc/cpp. *** Error code 1 libc successfully builds on Alpha with the changes I committed, though the bootstrapping problem issue is the same. As noted in another email I just sent, do: I had to add: cd /usr/src make includes What errors did you run into? make install did not work, maybe I should not do this multiuser? miata#make install install -c -o root -g wheel -m 444 libc.a /usr/lib install -c -o root -g wheel -m 444 libc_p.a /usr/lib install -c -s -o root -g wheel -m 444 libc.so.4 /usr/lib /usr/libexec/ld-elf.so.1: /usr/lib/libc.so.4: Undefined symbol "_libc_open" *** Error code 70 I copied libc.so.4 manually to /usr/lib but that is not sufficient. It looks like ld-elf sticks to libc.so.4 even if I move the symlink libc.so back from libc.so.4 to libc.so.3 before doing a buildworld. This probably isn't the correct way of resolving such bootstrapping issues, but it works. I'm no bootstrapping expert either, but I get the distinct feeling there should be an easier way :-( Help! For now I don't date reboot my Alpha Oh, that looks bad. =( I got myself into a similar fix yesterday and had to install FreeBSD on another partition to put a working libc.so.4 back in place. Keeping a spare copy of one that is known to work is a good idea. This advice comes a wee bit late... =( Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Make world breakage...
On Thu, Jan 13, 2000 at 12:16:31AM +0100, Wilko Bulte wrote: On Wed, Jan 12, 2000 at 01:22:25PM -0800, Jason Evans wrote: On Wed, Jan 12, 2000 at 10:07:25PM +0100, Wilko Bulte wrote: On Wed, Jan 12, 2000 at 09:56:22PM +0200, Mark Murray wrote: Hi Anyone else seeing this? ... /usr/obj/usr/src/alpha/usr/src/gnu/usr.bin/cc/cpp/../cc_fbsd/libcc_fbsd.a(mktemp.o) In function `_gettemp': mktemp.c(.text+0x3f0): undefined reference to `_libc_open' mktemp.c(.text+0x3f4): undefined reference to `_libc_open' *** Error code 1 Stop in /usr/src/gnu/usr.bin/cc/cpp. *** Error code 1 libc successfully builds on Alpha with the changes I committed, though the bootstrapping problem issue is the same. On further inspection, though libc builds on the Alpha, I'm guessing that terrible breakage results if it is installed. The Alpha I was testing on isn't mine, and I was afraid to mess things up, so I tested the build of libc, but did all installation and program testing with libc_r. The problem is that SYS.h for the Alpha doesn't define the _libc_*() aliases for system calls, which libc now uses. I'll try to get this fixed today if possible. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RFC: buildworld breakage due to cross-tools/libc/mktemp.
The buildworld problem that I introduced is due to cc_fbsd directly compiling and linking in src/lib/libc/stdio/mktemp.c. This is in my opinion a questionable practice, since it adds dependencies to the internals of the libc code, which has just been proven to bite. =) Aesthetics aside, I'm not sure what the best fix for the problem is. Options include: 1) Ignore the problem, since it only happens once, and has a work-around. This is probably not a good idea, since it makes the upgrade path bumpy. 2) Make a separate copy of mktemp.c to remove the internal dependency. I'm not familiar with the detailed semantics of mktemp() but this may be a problem if mktemp() is required to behave the same across all programs, and the two versions of mktemp.c diverge. 3) Add conditional compilation, such that the macro _libc_open=open is defined during the cross-tools stage. I tried this, but wasn't able to find an obvious way of inserting it into the build system. Besides, it's a bit of a hack, and doesn't address the core issue (dependency on libc internals). 4) Build a libc for the cross-tools stage that all the targets for that stage can be linked against. This looks cleanest to me, but adds substantially to build time and may be difficult to implement. Suggestions are welcome. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: __sigisempty() undefined if cc -g used.
On Fri, Jan 07, 2000 at 07:36:11PM -0500, Luoqi Chen wrote:
In an effort to chase down a libc_r bug, I compiled libc_r with CFLAGS=-g
(and later CFLAGS=-g3), but ran into linker problems as a result.
blitz:~ gcc poll.c -pthread
/usr/lib/libc_r.so: undefined reference to `__sigisempty'
Even the simplest of C programs will get this linker error if using the
-pthread option.
So, __sigisempty is an inline function, defined in
/usr/include/sys/signalvar.h:
extern __inline int
__sigisempty(sigset_t *set)
{
int i;
for (i = 0; i _SIG_WORDS; i++) {
if (set-__bits[i])
return (0);
}
return (1);
}
It doesn't make much sense to have an "extern" inline function, gcc probably
was confused by this, change "extern" to "static" and try again.
Yep, that fixed it. Thanks!
I just committed the change.
Jason
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Proposed end-all fix for (Re: Make world broken in libc_r)
On Sat, Nov 27, 1999 at 11:40:08AM -0800, Alfred Perlstein wrote:
On Sat, 27 Nov 1999, Mark Murray wrote:
Hi
"make world" is broken in libc_r. Simple fix is to replace all
"socklen_t" with "int".
libc_r likes to pull data from /usr/include instead of the
source tree, "make includes" fixes this. I'm not sure if
that's the correct way to fix it though.
I've got a change in the pipeline that will cause world breakage again,
unless we do something about this. Is there anything wrong with simply
adding:
CFLAGS+=-I${.CURDIR}/../../include
to lib/libc_r/Makefile? It fixes such build problems.
Jason
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Threads and my new job.
Walnut Creek has hired me as a full time employee to work primarily on improving and expanding FreeBSD's threads support. This is very exciting to me, and I hope my work will be of benefit the FreeBSD community. There is a lot of work to be done in order to make FreeBSD's threads support truly excellent, and it will take more than just me working on it. Fortunately, there are a number of other people also interested in improving threads support, and as work progresses, I expect this will very much be a group effort. Some very fruitful long-range architecture discussions have been taking place on the -arch mailing list, and discussion will likely continue there for some time as design decisions are hashed out. If you are interested in participating in the design discussion, please subscribe to -arch (if you haven't already), read the -arch archives for the past couple of weeks to bring yourself up to speed on what has been discussed so far, read some of the more pertinent references listed throughout the discussion, then jump in. The signal-to-noise ratio on -arch is exceptionally high; please do your part in keeping it that way. What am I going to do? My first mandate is to round out the edges of our current libc_r and to bring it closer to standards compliance before 4.0. Specifically, I know that the following work is necessary: *) Address and close approximately 20 PRs. The list of PRs I know about is: i386/7426, bin/7587, misc/8202, bin/8281, kern/8729, misc/9778, misc/9903, misc/10599, bin/10992, kern/11982, kern/11984, bin/13008, misc/13117, kern/13644, misc/14264, i386/14383, kern/14685, and docs/14858. If there are other PRs that I didn't list that are directly related to threads, please let me know about them in private email so that I can keep track of them. *) Signal delivery fixes. I think Daniel Eischen has already taken care of this. *) Lacking interfaces, such as pthread_cancel() (mentioned specifically in PR bin/7587) need to be implemented. *) Make a real libpthread, rather than relying on the -pthread linker magic. This is high on Daniel Eischen's wish list, so maybe he already has something in the works. =) If you know of other outstanding issues that have a prayer of being addressed before 4.0 ships, please speak up. Jason Jason Evans [EMAIL PROTECTED] http://www.canonware.com/~jasone Home phone: (650) 856-8204 "I once knew a happy medium. Her name was Zohar." - James Foster To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
