SU+J hard recovery failure
Hello folks, Yesterday I had a panic on my laptop. Unfortunately the SU+J was not able to recovery the file system, the error was something like : Unknown error: Help! Could not find directory 9854215 And it went to the single user mode, I needed to fsck_ufs manually to recover the disk. What afraid me is what if happens on a headless machine? It will be hard to recover. Regards, -- Demelier David ___ 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
libstdc++ not found by clang and base ld on 9-STABLE when building cmake c++ project
Hello, I'm not sure if this is right list, but has anything recently changed which could explain why cmake c++ project (http://sourceforge.net/projects/gemrb/) started to fail upon linking stage (looking like libstdc++ is not included /usr/include/c++/4.2/)? It works normally if passed gcc48 as compiler which subsequently uses (ld) binutils from ports and relevant libstdc++. I have in src.conf- WITH_CLANG_IS_CC=true WITHOUT_GCC=true WITHOUT_CLANG_FULL=true This project was routinely building with clang for me just fine earlier (as well as with gcc47 if told so). I even checked some ancient git tags and I'm positive it's some change in system, as they failed in the same way (no libstdc++ when linking). -- View this message in context: http://freebsd.1045724.n5.nabble.com/libstdc-not-found-by-clang-and-base-ld-on-9-STABLE-when-building-cmake-c-project-tp5799353.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ 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: libstdc++ not found by clang and base ld on 9-STABLE when building cmake c++ project
Apart from it, clang looks _very_ c++ capable, as in building boost and rebuilding os (itself) normally, so it doesn't look broken from this point. Just after some rebuild of OS (1-2 weeks ago?) This on git project started to fail upon linking. -- View this message in context: http://freebsd.1045724.n5.nabble.com/libstdc-not-found-by-clang-and-base-ld-on-9-STABLE-when-building-cmake-c-project-tp5799353p5799355.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ 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: FreeBSD 9.1 excessive memory allocations
On Tue, 2013-03-26 at 11:35 -0700, Unga wrote: Hi all I have a heavily threaded C application, developed on an Intel Core i5 laptop (2 cores) running FreeBSD 8.1-RELEASE. When this application compile and run on another Intel Core i7 laptop (4 cores) running FreeBSD 9.1-RELEASE, this application immediately starts grabbing memory by over 100MB per second and soon exit with not enough RAM. Both laptops having 4GB RAM. All malloc and free are mutex locked. Very rarely this problem happens on the i5 (2 cores) laptop too, but on the i7 laptop, it happens every time. Appreciate any feedback to identify and fix this issue. Best regards Unga Too many moving parts, you need to partition the problem. Is it the change in OS (and especially libraries) that causes the problem, or the change in the number of cores (more concurrent threads) is exposing some sort of application-side race condition? Given the fact that it does occur on 2 cores + freebsd 8.1, even if more rarely, it's almost surely an application problem. Perhaps you could use a tool such as valgrind to help track down the runaway allocations? Another way to expose thread race problems is to force more thread context switches. A blunt tool for doing so is to set hz=5000 or even higher in /boot/loader.conf. I've never done that on a desktop or laptop system, only on embedded systems, but it should still work okay. If changing the application code is easier, you can get a similar effect by creating a thread whose only job is to preempt other threads, by using rtprio_thread() to set it to real time priority, then just have it sleep for short random intervals (microseconds), all it does is wakes up and goes right back to sleep. Also, FYI, there's no need to use a mutex in your application to protect allocations. The memory allocator in libc is thread-safe, and in fact is particularly designed for efficient multi-threaded allocation. -- Ian ___ 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: FreeBSD 9.1 excessive memory allocations
On Wed, Mar 27, 2013 at 08:06:10AM -0600, Ian Lepore wrote: On Tue, 2013-03-26 at 11:35 -0700, Unga wrote: Hi all I have a heavily threaded C application, developed on an Intel Core i5 laptop (2 cores) running FreeBSD 8.1-RELEASE. When this application compile and run on another Intel Core i7 laptop (4 cores) running FreeBSD 9.1-RELEASE, this application immediately starts grabbing memory by over 100MB per second and soon exit with not enough RAM. Both laptops having 4GB RAM. All malloc and free are mutex locked. Very rarely this problem happens on the i5 (2 cores) laptop too, but on the i7 laptop, it happens every time. Appreciate any feedback to identify and fix this issue. Best regards Unga Too many moving parts, you need to partition the problem. Is it the change in OS (and especially libraries) that causes the problem, or the change in the number of cores (more concurrent threads) is exposing some sort of application-side race condition? Given the fact that it does occur on 2 cores + freebsd 8.1, even if more rarely, it's almost surely an application problem. Perhaps you could use a tool such as valgrind to help track down the runaway allocations? Another way to expose thread race problems is to force more thread context switches. A blunt tool for doing so is to set hz=5000 or even higher in /boot/loader.conf. I've never done that on a desktop or laptop system, only on embedded systems, but it should still work okay. If changing the application code is easier, you can get a similar effect by creating a thread whose only job is to preempt other threads, by using rtprio_thread() to set it to real time priority, then just have it sleep for short random intervals (microseconds), all it does is wakes up and goes right back to sleep. Also, FYI, there's no need to use a mutex in your application to protect allocations. The memory allocator in libc is thread-safe, and in fact is particularly designed for efficient multi-threaded allocation. Thank you Ian -- you've covered nearly all of the points I wanted to mention in a reply, but opted to not send it (one of those after I read it I had second thoughts situations). For the OP: I *strongly* recommend ports/devel/valgrind as mentioned. It can be a little bit daunting getting started with it (okay, wow, what am I doing with this thing?), but it's very useful for situations exactly like this. There's lots of random tidbits of info on it on the web too. If the issue turns out to be something in userland (library-wise) or the kernel, there are FreeBSD.org people who can help with those (I can think of 4 off the top of my head right now). They can be CC'd if things get to that point, but exhaust other avenues first. It would also be wise, at that time, if you could make the source to the application available, that would probably help folks narrow down what's happening -- otherwise they'll be forced to rely entirely on claims like it *should* be behaving like this, which isn't necessarily the same thing as how the underlying code bits actually behave. My impression as of this writing, is that the problem is in the application. If FreeBSD 9.1 had major problems with memory leaks in userland threaded apps, I'd expect it would have been discovered by now; that said, there is always the chance there is a bug somewhere outside of your application code, it just seems slim. -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | ___ 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: FreeBSD 9.1 excessive memory allocations [SOLVED]
- Original Message - From: Ian Lepore i...@freebsd.org To: Unga unga...@yahoo.com Cc: freebsd-stable@freebsd.org freebsd-stable@FreeBSD.org Sent: Wednesday, March 27, 2013 2:06 PM Subject: Re: FreeBSD 9.1 excessive memory allocations On Tue, 2013-03-26 at 11:35 -0700, Unga wrote: Hi all I have a heavily threaded C application, developed on an Intel Core i5 laptop (2 cores) running FreeBSD 8.1-RELEASE. When this application compile and run on another Intel Core i7 laptop (4 cores) running FreeBSD 9.1-RELEASE, this application immediately starts grabbing memory by over 100MB per second and soon exit with not enough RAM. Both laptops having 4GB RAM. All malloc and free are mutex locked. Very rarely this problem happens on the i5 (2 cores) laptop too, but on the i7 laptop, it happens every time. Appreciate any feedback to identify and fix this issue. Best regards Unga Too many moving parts, you need to partition the problem. Is it the change in OS (and especially libraries) that causes the problem, or the change in the number of cores (more concurrent threads) is exposing some sort of application-side race condition? Given the fact that it does occur on 2 cores + freebsd 8.1, even if more rarely, it's almost surely an application problem. Perhaps you could use a tool such as valgrind to help track down the runaway allocations? Another way to expose thread race problems is to force more thread context switches. A blunt tool for doing so is to set hz=5000 or even higher in /boot/loader.conf. I've never done that on a desktop or laptop system, only on embedded systems, but it should still work okay. If changing the application code is easier, you can get a similar effect by creating a thread whose only job is to preempt other threads, by using rtprio_thread() to set it to real time priority, then just have it sleep for short random intervals (microseconds), all it does is wakes up and goes right back to sleep. Also, FYI, there's no need to use a mutex in your application to protect allocations. The memory allocator in libc is thread-safe, and in fact is particularly designed for efficient multi-threaded allocation. -- Ian Dear Tony, Alexander, Jan, Ian and Jeremy Thank you very much for your very valuable comments. Problem seems to be solved. But require more testing. 1. Fixed an application-level crucial bug. This is nearly a 7000 lines C app. It was really hard to see as the application is designed with 8 dedicated threads. 2. At run-time, this application shoots up to about 400 dynamic threads on the i7 machine, whereas on the i5 machine, it only shoots up 57 dynamic threads. It was bit scaring, therefore, made a hard limit on total number of threads to 64. Regarding mutex locks on allocations, as per the malloc(3), it says small and medium size allocations are done from per thread caches, therefore, thread-safe. My allocations are large in nature, about 5-7MB. Best regards Unga ___ 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: FreeBSD 9.1 excessive memory allocations [SOLVED]
On Wed, 27 Mar 2013 19:33:46 +0100, Unga unga...@yahoo.com wrote: - Original Message - From: Ian Lepore i...@freebsd.org To: Unga unga...@yahoo.com Cc: freebsd-stable@freebsd.org freebsd-stable@FreeBSD.org Sent: Wednesday, March 27, 2013 2:06 PM Subject: Re: FreeBSD 9.1 excessive memory allocations On Tue, 2013-03-26 at 11:35 -0700, Unga wrote: Hi all I have a heavily threaded C application, developed on an Intel Core i5 laptop (2 cores) running FreeBSD 8.1-RELEASE. When this application compile and run on another Intel Core i7 laptop (4 cores) running FreeBSD 9.1-RELEASE, this application immediately starts grabbing memory by over 100MB per second and soon exit with not enough RAM. Both laptops having 4GB RAM. All malloc and free are mutex locked. Very rarely this problem happens on the i5 (2 cores) laptop too, but on the i7 laptop, it happens every time. Appreciate any feedback to identify and fix this issue. Best regards Unga Too many moving parts, you need to partition the problem. Is it the change in OS (and especially libraries) that causes the problem, or the change in the number of cores (more concurrent threads) is exposing some sort of application-side race condition? Given the fact that it does occur on 2 cores + freebsd 8.1, even if more rarely, it's almost surely an application problem. Perhaps you could use a tool such as valgrind to help track down the runaway allocations? Another way to expose thread race problems is to force more thread context switches. A blunt tool for doing so is to set hz=5000 or even higher in /boot/loader.conf. I've never done that on a desktop or laptop system, only on embedded systems, but it should still work okay. If changing the application code is easier, you can get a similar effect by creating a thread whose only job is to preempt other threads, by using rtprio_thread() to set it to real time priority, then just have it sleep for short random intervals (microseconds), all it does is wakes up and goes right back to sleep. Also, FYI, there's no need to use a mutex in your application to protect allocations. The memory allocator in libc is thread-safe, and in fact is particularly designed for efficient multi-threaded allocation. -- Ian Dear Tony, Alexander, Jan, Ian and Jeremy Thank you very much for your very valuable comments. Problem seems to be solved. But require more testing. 1. Fixed an application-level crucial bug. This is nearly a 7000 lines C app. It was really hard to see as the application is designed with 8 dedicated threads. 2. At run-time, this application shoots up to about 400 dynamic threads on the i7 machine, whereas on the i5 machine, it only shoots up 57 dynamic threads. It was bit scaring, therefore, made a hard limit on total number of threads to 64. Regarding mutex locks on allocations, as per the malloc(3), it says small and medium size allocations are done from per thread caches, therefore, thread-safe. My allocations are large in nature, about 5-7MB. The per thread caches are for speed. Not for thread-safety. Ronald. ___ 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: FreeBSD 9.1 excessive memory allocations [SOLVED]
On Wed, 2013-03-27 at 11:33 -0700, Unga wrote: - Original Message - From: Ian Lepore i...@freebsd.org To: Unga unga...@yahoo.com Cc: freebsd-stable@freebsd.org freebsd-stable@FreeBSD.org Sent: Wednesday, March 27, 2013 2:06 PM Subject: Re: FreeBSD 9.1 excessive memory allocations On Tue, 2013-03-26 at 11:35 -0700, Unga wrote: Hi all I have a heavily threaded C application, developed on an Intel Core i5 laptop (2 cores) running FreeBSD 8.1-RELEASE. When this application compile and run on another Intel Core i7 laptop (4 cores) running FreeBSD 9.1-RELEASE, this application immediately starts grabbing memory by over 100MB per second and soon exit with not enough RAM. Both laptops having 4GB RAM. All malloc and free are mutex locked. Very rarely this problem happens on the i5 (2 cores) laptop too, but on the i7 laptop, it happens every time. Appreciate any feedback to identify and fix this issue. Best regards Unga Too many moving parts, you need to partition the problem. Is it the change in OS (and especially libraries) that causes the problem, or the change in the number of cores (more concurrent threads) is exposing some sort of application-side race condition? Given the fact that it does occur on 2 cores + freebsd 8.1, even if more rarely, it's almost surely an application problem. Perhaps you could use a tool such as valgrind to help track down the runaway allocations? Another way to expose thread race problems is to force more thread context switches. A blunt tool for doing so is to set hz=5000 or even higher in /boot/loader.conf. I've never done that on a desktop or laptop system, only on embedded systems, but it should still work okay. If changing the application code is easier, you can get a similar effect by creating a thread whose only job is to preempt other threads, by using rtprio_thread() to set it to real time priority, then just have it sleep for short random intervals (microseconds), all it does is wakes up and goes right back to sleep. Also, FYI, there's no need to use a mutex in your application to protect allocations. The memory allocator in libc is thread-safe, and in fact is particularly designed for efficient multi-threaded allocation. -- Ian Dear Tony, Alexander, Jan, Ian and Jeremy Thank you very much for your very valuable comments. Problem seems to be solved. But require more testing. 1. Fixed an application-level crucial bug. This is nearly a 7000 lines C app. It was really hard to see as the application is designed with 8 dedicated threads. 2. At run-time, this application shoots up to about 400 dynamic threads on the i7 machine, whereas on the i5 machine, it only shoots up 57 dynamic threads. It was bit scaring, therefore, made a hard limit on total number of threads to 64. Regarding mutex locks on allocations, as per the malloc(3), it says small and medium size allocations are done from per thread caches, therefore, thread-safe. My allocations are large in nature, about 5-7MB. Best regards Unga I think you may be reading too much into the malloc manpage. When it mentions the use of per-thread small-object caches to avoid locking it's talking about performance, not thread safety. Allocations of all sizes are thread-safe, the library just assumes that huge allocations are rare enough that it doesn't use extra per-thread resources to avoid locking for them, it just uses locking for huge blocks. -- Ian ___ 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
Any objections/comments on axing out old ATA stack?
Hi. Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA stack, using only some controller drivers of old ata(4) by having `options ATA_CAM` enabled in all kernels by default. I have a wish to drop non-ATA_CAM ata(4) code, unused since that time from the head branch to allow further ATA code cleanup. Does any one here still uses legacy ATA stack (kernel explicitly built without `options ATA_CAM`) for some reason, for example as workaround for some regression? Does anybody have good ideas why we should not drop it now? -- Alexander Motin ___ 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: Any objections/comments on axing out old ATA stack?
On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote: Hi. Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA stack, using only some controller drivers of old ata(4) by having `options ATA_CAM` enabled in all kernels by default. I have a wish to drop non-ATA_CAM ata(4) code, unused since that time from the head branch to allow further ATA code cleanup. Does any one here still uses legacy ATA stack (kernel explicitly built without `options ATA_CAM`) for some reason, for example as workaround for some regression? Yes, I use the legacy ATA stack. Does anybody have good ideas why we should not drop it now? Because it works? -- Steve ___ 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: Any objections/comments on axing out old ATA stack?
On 27.03.2013 23:32, Steve Kargl wrote: On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote: Hi. Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA stack, using only some controller drivers of old ata(4) by having `options ATA_CAM` enabled in all kernels by default. I have a wish to drop non-ATA_CAM ata(4) code, unused since that time from the head branch to allow further ATA code cleanup. Does any one here still uses legacy ATA stack (kernel explicitly built without `options ATA_CAM`) for some reason, for example as workaround for some regression? Yes, I use the legacy ATA stack. On 9.x or HEAD where new one is default? Does anybody have good ideas why we should not drop it now? Because it works? Any problems with new one? -- Alexander Motin ___ 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: Any objections/comments on axing out old ATA stack?
On Wed, Mar 27, 2013 at 2:32 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote: Hi. Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA stack, using only some controller drivers of old ata(4) by having `options ATA_CAM` enabled in all kernels by default. I have a wish to drop non-ATA_CAM ata(4) code, unused since that time from the head branch to allow further ATA code cleanup. Does any one here still uses legacy ATA stack (kernel explicitly built without `options ATA_CAM`) for some reason, for example as workaround for some regression? Yes, I use the legacy ATA stack. You're missing the reason for why you're running the old ATA stack. Do you have hardware that doesn't work with ATA_CAM? Have you not tried ATA_CAM on that box? Some other reason? -- Freddie Cash fjwc...@gmail.com ___ 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: Any objections/comments on axing out old ATA stack?
On Wed, Mar 27, 2013 at 11:35:35PM +0200, Alexander Motin wrote: On 27.03.2013 23:32, Steve Kargl wrote: On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote: Hi. Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA stack, using only some controller drivers of old ata(4) by having `options ATA_CAM` enabled in all kernels by default. I have a wish to drop non-ATA_CAM ata(4) code, unused since that time from the head branch to allow further ATA code cleanup. Does any one here still uses legacy ATA stack (kernel explicitly built without `options ATA_CAM`) for some reason, for example as workaround for some regression? Yes, I use the legacy ATA stack. On 9.x or HEAD where new one is default? Head. Does anybody have good ideas why we should not drop it now? Because it works? Any problems with new one? Last time I tested the new one, and this was several months ago, the system (a Dell Latitude D530 laptop) would not boot. -- Steve ___ 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: Any objections/comments on axing out old ATA stack?
On 28.03.2013 00:05, Steve Kargl wrote: On Wed, Mar 27, 2013 at 11:35:35PM +0200, Alexander Motin wrote: On 27.03.2013 23:32, Steve Kargl wrote: On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote: Hi. Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA stack, using only some controller drivers of old ata(4) by having `options ATA_CAM` enabled in all kernels by default. I have a wish to drop non-ATA_CAM ata(4) code, unused since that time from the head branch to allow further ATA code cleanup. Does any one here still uses legacy ATA stack (kernel explicitly built without `options ATA_CAM`) for some reason, for example as workaround for some regression? Yes, I use the legacy ATA stack. On 9.x or HEAD where new one is default? Head. Does anybody have good ideas why we should not drop it now? Because it works? Any problems with new one? Last time I tested the new one, and this was several months ago, the system (a Dell Latitude D530 laptop) would not boot. Probably we should just fix that. Any more info? -- Alexander Motin ___ 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: Any objections/comments on axing out old ATA stack?
On Thu, Mar 28, 2013 at 12:22:11AM +0200, Alexander Motin wrote: On 28.03.2013 00:05, Steve Kargl wrote: Last time I tested the new one, and this was several months ago, the system (a Dell Latitude D530 laptop) would not boot. Probably we should just fix that. Any more info? I can't remember all the details. I intended to try again as work was being done on the new code at the time. I never got around to it as my laptop worked fine with the old code and unfortunately I got busy with work and family. Reading the freebsd-current mailing lists suggests that now is not the time to be a hero. -- Steve ___ 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: SU+J hard recovery failure
On 27/03/2013, at 18:43, David Demelier demelier.da...@gmail.com wrote: Yesterday I had a panic on my laptop. Unfortunately the SU+J was not able to recovery the file system, the error was something like : Unknown error: Help! Could not find directory 9854215 And it went to the single user mode, I needed to fsck_ufs manually to recover the disk. What afraid me is what if happens on a headless machine? It will be hard to recover. For headless remote systems I use fsck_y_enable=YES. In my experience 'fsck -y' almost invariably recovers the disk to a point where it can boot and then I can login remotely. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C smime.p7s Description: S/MIME cryptographic signature
Re: Any objections/comments on axing out old ATA stack?
My main concern with the new stuff is that it requires CAM and that's reasonably big compared to the standalone ATA code. It'd be nice if we could slim down the CAM stack a bit first; it makes embedding it on the smaller devices really freaking painful. Thanks, adrian ___ 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
Request for heimdal update to stable/releng
While looking into an issue with security/heimdal I found that v1.5.2 of heimdal has been in HEAD for 11 months and has had 2 small fixes in that time. Now that I look at it these two fixes should probably be duplicated to the port as well. This update has yet to be copied down to stable or releng branches, leaving releng with v1.1 which is over 5 years old. The issue I found in the ports version (pr/177397) appears to still exist in HEAD - while the hcrypto lib included is not used the man pages are still installed. Some of these man pages have the same names as openssl man pages. As openssl is used the hcrypto man pages don't need to be installed. ___ 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: FreeBSD 9.1 excessive memory allocations [SOLVED]
I think you may be reading too much into the malloc manpage. When it mentions the use of per-thread small-object caches to avoid locking it's talking about performance, not thread safety. Allocations of all sizes are thread-safe, the library just assumes that huge allocations are rare enough that it doesn't use extra per-thread resources to avoid locking for them, it just uses locking for huge blocks. -- Ian Good to note all allocations are thread safe in FreeBSD. Is it by some standard that malloc should be thread safe regardless the OS (BSDs, Linux, Windows, Android, etc)? Unga ___ 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
