How to update to the security advisories
Hey, i look since a long time, but i did not find. Is there a howto somewhere, how i have to go through the update for the security advisories? Thanks for any links, hints, ideas, comments and hot coffees :-D Roger ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.4-STABLE changes breaks IDE boot (was Re: 5.3 -> 5.4 breaks ATA (Intel ICH2))
A new kernel based on sources of 9/28/2005 still fails to boot on a Toshiba 8100 with a UDMA33 IDE onboard controller. The parameters passed to atapci0 are different from those passed by the earlier kernel, and the system locks up this point. I'm not including the dmesg, etc., since that's the same as I posted earlier. Mike Squires ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] option to re-enable aggressive ATA probing
Tim Howe wrote: Tim Howe <[EMAIL PROTECTED]> writes: ata0-master: stat=0xd0 err=0xd0 lsb=0xd0 msb=0xd0 This turned out to be the key. Version 1.51 of ata-lowlevel.c added a check for stat0/1, err, lsb, and msb being identical. If they are, it aborts the probe. The attached patch creates an option ATA_AGGRESSIVE_PROBE which disables this for the old aggressive behavior (which may wait up to the full 31 seconds). I also took the liberty of reworking the still-busy check from 3 equality tests to 2 bitmask tests. It seems simpler to my eye with identical results, but if I missed something or the other style was preferred please let me know. The patch is against 5-STABLE because that's what I have. Looks good except for one issue I talk about below. By the way, I don't think this will ever appear back into the RELENG_5 tree unless it gets a PR or at least someone who can check it in. Is there anyone willing to ask the right people? You might look at the initials for whoever changed the code recently and see if you can figure out who that was. Meanwhile, I will try and test it within the week. See below for my question about the patch. Billy --- sys/conf/options.stock Tue Sep 27 00:28:50 2005 +++ sys/conf/optionsTue Sep 27 00:55:53 2005 @@ -301,6 +301,7 @@ # Options used in the 'ata' ATA/ATAPI driver ATA_STATIC_ID opt_ata.h ATA_NOPCI opt_ata.h +ATA_AGGRESSIVE_PROBE opt_ata.h DEV_ATADISKopt_ata.h DEV_ATAPICDopt_ata.h DEV_ATAPISTopt_ata.h --- sys/conf/NOTES.stockTue Sep 27 00:30:28 2005 +++ sys/conf/NOTES Tue Sep 27 00:56:39 2005 @@ -1501,8 +1501,11 @@ # # ATA_STATIC_ID: controller numbering is static ie depends on location # else the device numbers are dynamically allocated. +# ATA_AGGRESSIVE_PROBE:Does not give up on probing when all err, lsb, and + msb are identical. Shouldn't there be a comment for the above line? Like this: +# msb are identical. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pthread_key_create memory leakage in pthreads?
Lefteris Tsintjelis wrote: > >Can you provide a (minimal) example where this happens? Also, what is > >the exact command line? > > valgrind --trace-children=yes --leak-check=yes --show-reachable=yes ./sql-m Two other things you can try to determine whether it's you code or a internal error in valgrind: - make sure you compile and link your code with debugging information (-g), and at an reasonable optimization level (say -O). - Use valgrinds -v option to get more information. If you are sure, that's it's valgrind's fault, you can generate a suppression rule: valgrind -v --gen-suppressions=yes You can put them into a file, say ~/.valgrind-suppressions, and tell valgrind to them with the --suppressions= switch. If you want to use them by default, create a ~/.valgrindrc file and put the appropriate options there. If all that doesn't help you, you're welcome to send me a copy of your code (in a private mail), and I'll have a look. -- Best regards / Viele Grüße, [EMAIL PROTECTED] Simon Barner[EMAIL PROTECTED] pgpUSnV3SMqxU.pgp Description: PGP signature
Re: pthread_key_create memory leakage in pthreads?
In the last episode (Sep 29), Lefteris Tsintjelis said: > Simon Barner wrote: > > > >Can you provide a (minimal) example where this happens? Also, what is > >the exact command line? > > valgrind --trace-children=yes --leak-check=yes --show-reachable=yes ./sql-m > > ==12024== 200 bytes in 1 blocks are definitely lost in loss record 3 of 5 > ==12024==at 0x3C03619F: malloc (in > /usr/local/lib/valgrind/vgpreload_memcheck.so) > ==12024==by 0x3C0978EC: (within /usr/local/lib/valgrind/libpthread.so.1) > ==12024==by 0x3C09A2FD: (within /usr/local/lib/valgrind/libpthread.so.1) > ==12024==by 0x3C09A489: pthread_key_create (in > /usr/local/lib/valgrind/libpthread.so.1) It's probably leakage internal to valgrind, since the stack trace stops inside a valgrind library. I wouldn't worry about it. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pthread_key_create memory leakage in pthreads?
Simon Barner wrote: Can you provide a (minimal) example where this happens? Also, what is the exact command line? valgrind --trace-children=yes --leak-check=yes --show-reachable=yes ./sql-m ==12024== Memcheck, a memory error detector for x86-linux. ==12024== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward. ==12024== Using valgrind-2.1.0, a program supervision framework for x86-linux. ==12024== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward. ==12024== Estimated CPU clock rate is 3089 MHz ==12024== For more details, rerun with: -v ==12024== ==12024== warning: Valgrind's pthread_cond_destroy is incomplete ==12024== (it doesn't check if the cond is waited on) ==12024== your program may misbehave as a result ==12024== warning: Valgrind's pthread_cond_destroy is incomplete ==12024== (it doesn't check if the cond is waited on) ==12024== your program may misbehave as a result ==12024== ==12024== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ==12024== malloc/free: in use at exit: 33100 bytes in 22 blocks. ==12024== malloc/free: 6051 allocs, 6029 frees, 24774738 bytes allocated. ==12024== For counts of detected errors, rerun with: -v ==12024== searching for pointers to 22 not-freed blocks. ==12024== checked 2119764 bytes. ==12024== ==12024== 52 bytes in 1 blocks are still reachable in loss record 1 of 5 ==12024==at 0x3C036967: calloc (in /usr/local/lib/valgrind/vgpreload_memcheck.so) ==12024==by 0x3C050F6C: my_thread_init (in /usr/local/lib/mysql/libmysqlclient_r.so.14) ==12024==by 0x3C050E4A: my_thread_global_init (in /usr/local/lib/mysql/libmysqlclient_r.so.14) ==12024==by 0x3C04C158: my_init (in /usr/local/lib/mysql/libmysqlclient_r.so.14) ==12024== ==12024== ==12024== 136 bytes in 12 blocks are still reachable in loss record 2 of 5 ==12024==at 0x3C03619F: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck.so) ==12024==by 0x3C0978EC: (within /usr/local/lib/valgrind/libpthread.so.1) ==12024==by 0x3C098F65: pthread_mutex_init (in /usr/local/lib/valgrind/libpthread.so.1) ==12024==by 0x3C050D95: my_thread_global_init (in /usr/local/lib/mysql/libmysqlclient_r.so.14) ==12024== ==12024== ==12024== 200 bytes in 1 blocks are definitely lost in loss record 3 of 5 ==12024==at 0x3C03619F: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck.so) ==12024==by 0x3C0978EC: (within /usr/local/lib/valgrind/libpthread.so.1) ==12024==by 0x3C09A2FD: (within /usr/local/lib/valgrind/libpthread.so.1) ==12024==by 0x3C09A489: pthread_key_create (in /usr/local/lib/valgrind/libpthread.so.1) ==12024== ==12024== ==12024== 4096 bytes in 1 blocks are still reachable in loss record 4 of 5 ==12024==at 0x3C03619F: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck.so) ==12024==by 0x3C17B4B9: __smakebuf (in /lib/libc.so.5) ==12024==by 0x3C17B416: __swsetup (in /lib/libc.so.5) ==12024==by 0x3C16FC39: __vfprintf (in /lib/libc.so.5) ==12024== ==12024== ==12024== 28616 bytes in 7 blocks are still reachable in loss record 5 of 5 ==12024==at 0x3C03619F: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck.so) ==12024==by 0x3C05308A: my_once_alloc (in /usr/local/lib/mysql/libmysqlclient_r.so.14) ==12024==by 0x3C0534B7: init_state_maps (in /usr/local/lib/mysql/libmysqlclient_r.so.14) ==12024==by 0x3C053E94: init_available_charsets (in /usr/local/lib/mysql/libmysqlclient_r.so.14) ==12024== ==12024== LEAK SUMMARY: ==12024==definitely lost: 200 bytes in 1 blocks. ==12024==possibly lost: 0 bytes in 0 blocks. ==12024==still reachable: 32900 bytes in 21 blocks. ==12024== suppressed: 0 bytes in 0 blocks. valgrind is not a native BSD program. I use it to detect program memory leaks. However, I am not sure if in this case, is detecting its own leaks and problems or not. It is refering to its own /usr/local/lib/valgrind/\ libpthread.so.1. sql-m is my own program that I test but I have double checked everything and this shouldn't happen. If you need further info about the sql-m please let me know and I will send you a copy but its a very simple threaded one. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pthread_key_create memory leakage in pthreads?
Lefteris Tsintjelis wrote: > Hi, > > dmesg: FreeBSD 5.4-STABLE #0: Sun Sep 25 20:08:39 EEST 2005 > > I am using valgrind to check my program but it always seems to come with > this > message: > > ==8210== 600 bytes in 3 blocks are definitely lost in loss record 3 of 6 > ==8210==at 0x3C03619F: malloc (in > /usr/local/lib/valgrind/vgpreload_memcheck.so) > ==8210==by 0x3C0978EC: (within /usr/local/lib/valgrind/libpthread.so.1) > ==8210==by 0x3C09A2FD: (within /usr/local/lib/valgrind/libpthread.so.1) > ==8210==by 0x3C09A489: pthread_key_create (in > /usr/local/lib/valgrind/libpthread.so.1) > > I am not sure if its accurate or not. I use a proper pthread_exit in my > thread. > Is there anything more that I should do besides that? Can you provide a (minimal) example where this happens? Also, what is the exact command line? -- Best regards / Viele Grüße, [EMAIL PROTECTED] Simon Barner[EMAIL PROTECTED] pgpdmvRS9SOhh.pgp Description: PGP signature
Re: Problem About how to use shared posix semaphore
On Thu, 2005-09-29 at 20:47 +0800, Gary Li-126 wrote:
> Hi,
> I always get the error message:"Operation not permitted" When I use
> sem_init set pshared argument equal 1. Compiling as : "gcc -o sem_test
> sem_test.c -lc_r". My freebsd ver is release 5.4 p6.
>From sem_init(3):
A non-zero value for pshared specifies a
shared semaphore that can be used by multiple processes, which this
implementation is not capable of.
I suspect you're asking the impossible. You could try using a different
threading library, but libc_r won't work:
/usr/src/lib/libc_r/uthread/uthread_sem.c:
_sem_init(sem_t *sem, int pshared, unsigned int value)
{
[...]
if (pshared != 0) {
/*
* The user wants a semaphore that can be shared among
* processes, which this implementation can't do. Sounds like a
* permissions problem to me (yeah right).
*/
errno = EPERM;
retval = -1;
goto RETURN;
}
This return code is documenbted in the sem_init man page:
[EPERM]Unable to initialize a shared semaphore.
Gavin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Problem About how to use shared posix semaphore
Hi,
I always get the error message:"Operation not permitted" When I use
sem_init set pshared argument equal 1. Compiling as : "gcc -o sem_test
sem_test.c -lc_r". My freebsd ver is release 5.4 p6.
Test code appear below:
1 #include
2 #include
3 #include
4 #include
5 #include
6 #include
7 #include
8 #include
9 #include
10
11 int main(int argc, char ** argv)
12 {
13 sem_t mutex;
14 if (-1 == sem_init (&mutex, 1, 1)) {
15 printf("sem init error:%s\n", strerror(errno));
16 exit(0);
17 }
18 sem_wait (&mutex);
19 printf("sem wait ok:\n");
20 sem_post (&mutex);
21 sem_destroy (&mutex);
22 return 0;
23 }
Best regards,
Gary Li___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Advice sought on upgrading from 4.11-R to 5.4...
Doug Barton <[EMAIL PROTECTED]> wrote: > I disagree that ignoring comments in the files is a good idea. There is no > way for mergemaster to know for sure if the comment is material or not, > that's the admin's job. Furthermore, it is non-trivial to automatically detect that a change is inside a comment. Many files use "#", but some files use ";" or "//" for comments (e.g. BIND files), send- mail mc files use "dnl" to introduce comments, and I'm sure there are others. Ignoring everything that starts with "#" would be a particularly bad idea, because there are files where that character does _not_ introduce a comment. I agree with Doug that changes in comments are sometimes important enough to be read by the admin, e.g. if a default setting changes or an important new option is introduced. Of course, there are also sometimes changes that just fix typos, and dealing with those might be a waste of time, but that's no a valid reason to ignore _all_ changes inside comments. Here's my recommendation for /etc/mergemaster.rc: DIFF_FLAG='-Bub'# Hide changes in whitespace DIFF_OPTIONS='-I$FreeBSD:.*[$]' # Ignores CVS Id tags IGNORE_MOTD=yes # Ignores changes in motd Of course, as always: YMMV. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "C++ is the only current language making COBOL look good." -- Bertrand Meyer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
pthread_key_create memory leakage in pthreads?
Hi, dmesg: FreeBSD 5.4-STABLE #0: Sun Sep 25 20:08:39 EEST 2005 I am using valgrind to check my program but it always seems to come with this message: ==8210== 600 bytes in 3 blocks are definitely lost in loss record 3 of 6 ==8210==at 0x3C03619F: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck.so) ==8210==by 0x3C0978EC: (within /usr/local/lib/valgrind/libpthread.so.1) ==8210==by 0x3C09A2FD: (within /usr/local/lib/valgrind/libpthread.so.1) ==8210==by 0x3C09A489: pthread_key_create (in /usr/local/lib/valgrind/libpthread.so.1) I am not sure if its accurate or not. I use a proper pthread_exit in my thread. Is there anything more that I should do besides that? Please CC Thnx, Lefteris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
