Re: Free memory after upgrade to 7.1
Ivan Voras wrote: I think this is the major change in malloc between 7.0 and 7.1: http://svn.freebsd.org/viewvc/base?view=revisionrevision=184602 You can test if it's the cause of your problem by toggling between 'D' and 'M' options to malloc.conf (see malloc(3), don't forget to restart apache). Revision 184602 reverted the behavior so that malloc behaves the *same* for the 7.0 and 7.1 releases, with respect to DSS versus heap allocation. Jason ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Calling malloc from a signal handler
Stephen Montgomery-Smith wrote: I notice that if you use malloc from within a signal handler on FreeBSD-6.x, that you can potentially trigger a recursive call error. But this seems to have changed in FreeBSD-7.x. The malloc implementation is completely new in FreeBSD 7, so not all of the internal error checking code is the same. Is it now permissible to call malloc from within a signal handler in FreeBSD-7.x? Calling malloc from within a signal handler can cause application deadlock, so although you won't see an error message printed, you are unlikely to be happy with the results. Jason ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7 buildworld error
Joshua Coombs wrote: Derek Taylor wrote: On Fri, Feb 29, 2008 09:50 PM Sean [EMAIL PROTECTED] wrote: Check /etc/make.conf for CFLAGS, and if present remove it. This fixed the problem. Thank you. -Derek. I can confirm a failure in the same spot. What concerns me is in both my failure, and Derek's, the malloc is failing well below what limit says should be allowed. bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/include -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libcpp/include -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libdecnumber -I/usr/obj/usr/src/tmp/legacy/usr/include -c ../cc_tools/insn-attrtab.c cc1: out of memory allocating 136475392 bytes *** Error code 1 Stop in /usr/src/gnu/usr.bin/cc/cc_int. *** Error code 1 cyrix-dlc# limit cputime unlimited filesize unlimited datasize 524288 kbytes stacksize65536 kbytes coredumpsize unlimited memoryuseunlimited vmemoryuse unlimited descriptors 957 memorylocked unlimited maxproc 478 sbsize unlimited cc1 was only trying to request 130MB, my datasize is 512MB, why did it fail? It looks to me like gcc is trying to allocate a single 130MiB object, but you don't say anything about how much memory is already in use. It may well be that there are no remaining places in the memory map to place such a large object. Jason ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Changed behaviour of pthread_join (bug?)
Disregard my previous email. After looking at the test more closely, I see that it is necessary to press enter soon after starting the test to cause the failure. I'm looking into the problem now. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Changed behaviour of pthread_join (bug?)
Attached is a patch for -stable that should fix the problem your test
exposes, as well as a problem that your actual program might hit (canceled
threads should not detach). I also noticed and hopefully fixed a problem
with canceling a thread suspended while joining, but you probably don't do
that. =)
Please give the patch a try and let me know if it works for you.
Thanks,
Jason
P.S. Dan Eischen provided the bulk of this fix. Thanks Dan!
Index: uthread_cancel.c
===
RCS file: /home/ncvs/src/lib/libc_r/uthread/uthread_cancel.c,v
retrieving revision 1.3.2.3
diff -u -r1.3.2.3 uthread_cancel.c
--- uthread_cancel.c2001/06/23 00:47:05 1.3.2.3
+++ uthread_cancel.c2001/07/12 20:59:13
@@ -59,9 +59,23 @@
break;
case PS_JOIN:
+ /*
+* Disconnect the thread from the joinee and
+* detach:
+*/
+ if (pthread-data.thread != NULL) {
+ pthread-data.thread-joiner = NULL;
+ pthread_detach((pthread_t)
+ pthread-data.thread);
+ }
+ pthread-cancelflags |= PTHREAD_CANCELLING;
+ PTHREAD_NEW_STATE(pthread, PS_RUNNING);
+ break;
+
case PS_SUSPENDED:
if (pthread-suspended == SUSP_NO ||
pthread-suspended == SUSP_YES ||
+ pthread-suspended == SUSP_JOIN ||
pthread-suspended == SUSP_NOWAIT) {
/*
* This thread isn't in any scheduling
@@ -180,7 +194,6 @@
*/
_thread_run-cancelflags = ~PTHREAD_CANCELLING;
_thread_exit_cleanup();
- pthread_detach((pthread_t)_thread_run);
pthread_exit(PTHREAD_CANCELED);
PANIC(cancel);
}
@@ -211,7 +224,6 @@
if ((_thread_run-cancelflags PTHREAD_CANCEL_NEEDED) != 0) {
_thread_run-cancelflags = ~PTHREAD_CANCEL_NEEDED;
_thread_exit_cleanup();
- pthread_detach((pthread_t)_thread_run);
pthread_exit(PTHREAD_CANCELED);
}
}
Index: uthread_join.c
===
RCS file: /home/ncvs/src/lib/libc_r/uthread/uthread_join.c,v
retrieving revision 1.12.2.3
diff -u -r1.12.2.3 uthread_join.c
--- uthread_join.c 2001/07/05 16:04:09 1.12.2.3
+++ uthread_join.c 2001/07/12 20:30:29
@@ -119,6 +119,9 @@
/* Set the running thread to be the joiner: */
pthread-joiner = _thread_run;
+ /* Keep track of which thread we're joining to: */
+ _thread_run-data.thread = pthread;
+
/* Schedule the next thread: */
_thread_kern_sched_state(PS_JOIN, __FILE__, __LINE__);
