pgk_add segmentation fault
Hi ! pkg_add is crashing with a segmentation fault: pkg_add -v mysql-client-5.1.22.tbz Requested space: 3809856 bytes, free space: 128323438592 bytes in /var/tmp/instmp.ND8UBU extract: Package name is mysql-client-5.1.22 extract: CWD to /usr/local extract: /usr/local/man/man1/mysql_config.1.gz extract: /usr/local/man/man1/mysql.1.gz extract: /usr/local/man/man1/mysqladmin.1.gz extract: /usr/local/man/man1/mysqlbinlog.1.gz extract: /usr/local/man/man1/mysqlcheck.1.gz extract: /usr/local/man/man1/mysqldump.1.gz extract: /usr/local/man/man1/mysqlimport.1.gz extract: /usr/local/man/man1/mysqlshow.1.gz extract: /usr/local/man/man8/mysqlmanager.8.gz . . . extract: /usr/local/lib/mysql/libmysqlclient_r.la extract: /usr/local/lib/mysql/libmysqlclient_r.so extract: /usr/local/lib/mysql/libmysqlclient_r.so.16 extract: /usr/local/share/aclocal/mysql.m4 extract: /usr/local/share/mysql/mysql_fix_privilege_tables.sql extract: execute '/sbin/ldconfig -m /usr/local/lib/mysql' extract: CWD to (null) Segmentation fault (core dumped) # uname -a FreeBSD CMXHost 5.30.0170 FreeBSD 5.30.0170 #0: Thu Apr 13 14:05:14 UTC 2006 i386 7.05.0014 Any ideas ? TIA -- The day is short, and the work is great,| Aharon Schkolnik and the laborers are lazy, and the reward | is great, and the Master of the house is| [EMAIL PROTECTED] impatient. - Ethics Of The Fathers Ch. 2| 054 8422076 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A TrustedBSD voluntary sandbox policy.
On Wed, Nov 07, 2007 at 10:20:28PM -0500, [EMAIL PROTECTED] wrote: I'm considering developing a policy/module for TrustedBSD loosely based on the systrace concept - A process loads a policy and then executes another program in a sandbox with fine grained control over what that program can do. ... Please note that the 'policy' given on the command line is purely for the sake of example, no syntax or semantics have been decided upon. Can't comment on the implementation or wider issues, but if you pursue this, please have a look at how MacOS Leopard does it (Seatbelt). Would be nice to converge on both syntax (a Schema dialect) and tools names / command line args--or if converging is not possible, at least know where and why and make a conscious decision. Bye, Andrea -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pgk_add segmentation fault
Hi, It seems that pkg_add tries to executes ldconfig which itself cause the segmentation fault. On Nov 8, 2007 7:44 AM, Aharon Schkolnik [EMAIL PROTECTED] wrote: Hi ! pkg_add is crashing with a segmentation fault: pkg_add -v mysql-client-5.1.22.tbz Requested space: 3809856 bytes, free space: 128323438592 bytes in /var/tmp/instmp.ND8UBU extract: Package name is mysql-client-5.1.22 extract: CWD to /usr/local extract: /usr/local/man/man1/mysql_config.1.gz extract: /usr/local/man/man1/mysql.1.gz extract: /usr/local/man/man1/mysqladmin.1.gz extract: /usr/local/man/man1/mysqlbinlog.1.gz extract: /usr/local/man/man1/mysqlcheck.1.gz extract: /usr/local/man/man1/mysqldump.1.gz extract: /usr/local/man/man1/mysqlimport.1.gz extract: /usr/local/man/man1/mysqlshow.1.gz extract: /usr/local/man/man8/mysqlmanager.8.gz . . . extract: /usr/local/lib/mysql/libmysqlclient_r.la extract: /usr/local/lib/mysql/libmysqlclient_r.so extract: /usr/local/lib/mysql/libmysqlclient_r.so.16 extract: /usr/local/share/aclocal/mysql.m4 extract: /usr/local/share/mysql/mysql_fix_privilege_tables.sql extract: execute '/sbin/ldconfig -m /usr/local/lib/mysql' extract: CWD to (null) Segmentation fault (core dumped) # uname -a FreeBSD CMXHost 5.30.0170 FreeBSD 5.30.0170 #0: Thu Apr 13 14:05:14 UTC 2006 i386 7.05.0014 Any ideas ? TIA -- The day is short, and the work is great,| Aharon Schkolnik and the laborers are lazy, and the reward | is great, and the Master of the house is| [EMAIL PROTECTED] impatient. - Ethics Of The Fathers Ch. 2| 054 8422076 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- System Programmer -- I'm Searching For Perfection, So Even If U Need Portability U've To Use Assembly ;-) -- http://libosdk.berlios.de ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any progress on FreeBSD/xen port?
Kip Macy wrote: I've committed to importing i386/PAE (UP) domU support for Xen by the end of the year. -Kip Excellent, thanks for the update. -Scott Oertel ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A TrustedBSD voluntary sandbox policy.
On Wed, Nov 07, 2007 at 10:20:28PM -0500, [EMAIL PROTECTED] wrote: I'm considering developing a policy/module for TrustedBSD loosely based on the systrace concept - A process loads a policy and then executes another program in a sandbox with fine grained control over what that program can do. I'm aiming for a much simpler implementation, however. No interaction. No privilege elevation (only restriction). No system call rewriting, only access control. The interface will look something like this: (cat EOF deny all allow file_open /etc/passwd allow file_open /dev/tty allow sock_connect 127.0.0.1 80 allow sock_connect 208.77.188.166 80 rlimit core 0 rlimit cpu 20 rlimit nofile 10 EOF ) | sandbox /bin/ls -alF /bin Please note that the 'policy' given on the command line is purely for the sake of example, no syntax or semantics have been decided upon. The implementation appears to be simple, as far as I'm aware. I'm sure there will be thorns and problems - that's what I'm here to find out. The 'sandbox' process compiles the policy text into a binary structure in userland, loads the binary structure into the kernel module via a system call implemented with mac_syscall(), sets various rlimits and then runs /bin/ls with execve(). When the process exits, the memory for the binary structure is freed. I would like, at this stage, to know if the above model is seriously incompatible with the way the MAC framework works, it's not entirely clear either way having read other policies such as mac_biba, mac_stub etc. For example - how to know when a process has exited? Policy for an executed process would be kept in a small hash table, indexed by process id. The policy will be enabled when the process sucessfully calls execve() for the first time and will be destroyed when the process exits. If we're not notified when a process has exited, we can't remove policy from the table. Also, what should be done when a process decides to fork() or execve()? It'd be rather unfortunate if the process could break out of the sandbox just by executing another process but blocking all attempts to fork() or execve() would make classes of programs unusable. First problem is that it is hard to operate on file paths. MAC passes a locked vnode to you and you cannot go from there to a file name easly. You could do it by comparsion: call VOP_GETATTR(9) on the given vnode, do the same for /etc/passwd and others and compare their inodes and file system ids. Performance hit may be significant for complex policies. You can register yourself for process_exit, process_fork and process_exec in-kernel events and do your cleanups from your event handler. Take a look at EVENTHANDLER(9). -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpnSAKoJorcw.pgp Description: PGP signature
Some FreeBSD performance Issues
Hi All, I recently ported my HLA (High Level Assembler) compiler to FreeBSD and, along with it, the HLA Standard Library. I have a performance-related question concerning file I/O. It appears that character-at-a-time file I/O is *exceptionally* slow. Yes, I realize that when processing large files I really ought to be doing block/buffered I/O to get the best performance, but for certain library routines I've written it's been far more convenient to do character-at-a-time I/O rather than deal with all the buffering issues. In the past, while slower, this character-at-a-time paradigm has provided reasonable, though not stellar, performance under Windows and Linux. However, with the port to FreeBSD I'm seeing a three-orders-of-magnitude performance loss. Here's my little test program: program t; #include( stdlib.hhf ) //#include( bsd.hhf ) static f :dword; buffer :char[64*1024]; begin t; fileio.open( socket.h, fileio.r ); mov( eax, f ); #if( false ) // Windows: 0.25 seconds // BSD: 5.2 seconds while( !fileio.eof( f )) do fileio.getc( f ); //stdout.put( (type char al )); endwhile; #elseif( false ) // Windows: 0.0 seconds (below 1ms threshold) // BSD: 5.2 seconds forever fileio.read( f, buffer, 1 ); breakif( eax 1 ); //stdout.putc( buffer[0] ); endfor; #elseif( false ) // BSD: 5.1 seconds forever bsd.read( f, buffer, 1 ); breakif( @c ); breakif( eax 1 ); //stdout.putc( buffer[0] ); endfor; #else // BSD: 0.016 seconds bsd.read( f, buffer, 64*1024 ); //stdout.write( buffer, eax ); #endif fileio.close( f ); end t; (I selectively set one of the conditionals to true to run a different test; yeah, this is HLA assembly code, but I suspect that most people who can read C can *mostly* figure out what's going on here). The fileio.open call is basically a bsd.open( socket.h, bsd.O_RDONLY ); API call. The socket.h file is about 19K long (it's from the FreeBSD include file set). In particular, I would draw your attention to the first two tests that do character-at-a-time I/O. The difference in performance between Windows and FreeBSD is dramatic (note: Linux numbers are comparable to Windows). Just to make sure that the library code wasn't doing something incredibly stupid, the third test makes a direct FreeBSD API call to read the data a byte at a time -- the results are comparable to the first two tests. Finally, I read the whole file at once, just to make sure the problem was character-at-a-time I/O (which obviously is the problem). Naturally, at one point I'd uncommented all the output statements to verify that I was reading the entire file -- no problem there. Is this really the performance I can expect from FreeBSD when doing character I/O this way? Is is there some tuning parameter I can set to change internal buffering or something? From this numbers, if I had to guess, I'd suspect that FreeBSD was re-reading the entire 4K (or whatever) block from the file cache everytime I read a single character. Can anyone explain what's going on here? I'm loathe to change my fileio module to add buffering as that will create some subtle semantic differences that could break existing code (I do have an object-oriented file I/O class that I'm going to use to implement buffered I/O, I would prefer to leave the fileio module unbuffered, if possible). And a more general question: if this is the way FreeBSD works, should something be done about it? Thanks, Randy Hyde ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Fwd: pgk_add segmentation fault
-- Forwarded message -- From: Kris Kennaway [EMAIL PROTECTED] Date: Nov 8, 2007 1:44 PM Subject: Re: pgk_add segmentation fault To: Maslan [EMAIL PROTECTED] Maslan wrote: Hi, It seems that pkg_add tries to executes ldconfig which itself cause the segmentation fault. Can you reproduce it when running that command by hand? If so, rebuild ldconfig with -ggdb and see where it is crashing. extract: execute '/sbin/ldconfig -m /usr/local/lib/mysql' extract: CWD to (null) Segmentation fault (core dumped) Kris -- System Programmer -- I'm Searching For Perfection, So Even If U Need Portability U've To Use Assembly ;-) -- http://libosdk.berlios.de ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some FreeBSD performance Issues
In the last episode (Nov 08), Randall Hyde said: It appears that character-at-a-time file I/O is *exceptionally* slow. Yes, I realize that when processing large files I really ought to be doing block/buffered I/O to get the best performance, but for certain library routines I've written it's been far more convenient to do character-at-a-time I/O rather than deal with all the buffering issues. In the past, while slower, this character-at-a-time paradigm has provided reasonable, though not stellar, performance under Windows and Linux. However, with the port to FreeBSD I'm seeing a three-orders-of-magnitude performance loss. Here's my little test program: [...] The fileio.open call is basically a bsd.open( socket.h, bsd.O_RDONLY ); API call. The socket.h file is about 19K long (it's from the FreeBSD include file set). In particular, I would draw your attention to the first two tests that do character-at-a-time I/O. The difference in performance What timings does dd if=/usr/include/sys/socket.h of=/dev/null ibs=1 obs=64k report? It takes about .4 sec on my non-idle dual pIII-900 system. Try truss'ing your program as it runs; maybe the program is doing some extra syscalls you aren't aware of? -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: page fault degaradation performance
Running out of memory and having to continually swap things in and out of ram degrades performance, yes. Page faults are simply how the virtual memory subsystem gets things done, like pulling things out of swap. --Doug On Nov 7, 2007 7:48 PM, binto [EMAIL PROTECTED] wrote: Btw Even page fault isn't a terrible thing, but she could make trashing condition..that can degrade CPU utilization, am i correct? On 11/6/07, binto [EMAIL PROTECTED] wrote: I just wanna know, how to reduce the number of page faults to upgrade program or OS performance? is there any parameters that i must set if i reduce the number of page fault? Don't forget that some amount of page faults are normal consequences of using a machine with virtual memory. Page faults alone are not an indicator that you're out of memory or suffering in any way, they just mean that something was requested in vm that wasn't actually in ram, and needed to be loaded. Ask 'swapinfo' or 'top' to see if you might possibly benefit from more ram by reducing paging. --Doug ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: page fault degaradation performance
Btw, what is page replacement algorithm that used by FreeBSD...sorry I'm newbie..LRU or another algorithm? Running out of memory and having to continually swap things in and out of ram degrades performance, yes. Page faults are simply how the virtual memory subsystem gets things done, like pulling things out of swap. --Doug On Nov 7, 2007 7:48 PM, binto [EMAIL PROTECTED] wrote: Btw Even page fault isn't a terrible thing, but she could make trashing condition..that can degrade CPU utilization, am i correct? On 11/6/07, binto [EMAIL PROTECTED] wrote: I just wanna know, how to reduce the number of page faults to upgrade program or OS performance? is there any parameters that i must set if i reduce the number of page fault? Don't forget that some amount of page faults are normal consequences of using a machine with virtual memory. Page faults alone are not an indicator that you're out of memory or suffering in any way, they just mean that something was requested in vm that wasn't actually in ram, and needed to be loaded. Ask 'swapinfo' or 'top' to see if you might possibly benefit from more ram by reducing paging. --Doug ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make: evaluation of symbolic link with ../ fails
On Tue, 06 Nov 2007 17:20:14 +0100 Julian H. Stacey [EMAIL PROTECTED] wrote: It seems to me that all except csh (including bourne shell !) are broken !! Amazing ! None of them cope properly actually following symbolic links, they all make false premise the /some_path/.. == /some_path ! That's not a bug, that's a feature. When symlinks were introduced in 4.1c (or thereabouts), people were often surprised to do: $ cd /some_path/child $ ... $ cd .. and not wind up in /some_path, or having the ever popular sh loop: $ for dir in list of subdirs $ do $ cd $dir $ ... $ cd .. $ done start working on something totally unrelated to the current directory halfway through the loop. So sh (and etc.) added a feature so that those things worked the way users expected them to. Basically, the shells don't make a false premise that /some_path/.. == /some_path, they make the premise appear to be true as a feature. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
kgdb: cannot read IdlePTD ??
# cd /usr/src/sys/i386/compile/KERNELSOME/ # kgdb kernel.debug /var/crash/vmcore.0 kgdb: cannot read IdlePTD kgdb: cannot read IdlePTD???help pls thx BWP ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: options TI_JUMBO_HDRSPLIT and TI_PRIVATE_JUMBOS are mutually exclusive
...seem like i just need for Tx side [ smtp /outgoing mail server ] by enable kern.ipc.zero_copy.send disable kern.ipc.zero_copy.receive thx binto On Fri, Nov 02, 2007 at 11:00:26AM +0700, binto wrote: another question. in my 'dmesg' i have NIC - em0 Intel(R) PRO/1000 Network Connection Version - 6.6.6...is it support Tigon driver that need to set ZERO_COPY_SOCKETS ? em(4) supports zero copy for Tx side. zero copy for receiver side requires header splitting assistance from hardware which is not available in em(4). I guess ti(4) on Tigon II would be the only driver that supports header splitting. However it seems newer Intel NICs and Sun Cassini+ seems to have header splitting feature. Jack Vogel, maintainer of em(4), may have more information for header splitting support on em(4).(CCed) thx On Fri, Nov 02, 2007 at 09:39:19AM +0700, binto wrote: I try to compile MYKERNEL to set zero_copy tigon driver in my machine with: device ti options TI_PRIVATE_JUMBOS options TI_JUMBO_HDRSPLIT but got: #error options TI_JUMBO_HDRSPLIT and TI_PRIVATE_JUMBOS are mutually exclusive what's up? %vi +/TI_JUMBO_HDRSPLIT /usr/src/sys/conf/NOTES -- Regards, Pyun YongHyeon -- Regards, Pyun YongHyeon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some FreeBSD performance Issues
Dan Nelson wrote: In the last episode (Nov 08), Randall Hyde said: It appears that character-at-a-time file I/O is *exceptionally* slow. ... reasonable, though not stellar, performance under Windows and Linux. However, with the port to FreeBSD I'm seeing a three-orders-of-magnitude performance loss. ... What timings does dd if=/usr/include/sys/socket.h of=/dev/null ibs=1 obs=64k report? It takes about .4 sec on my non-idle dual pIII-900 system. Try truss'ing your program as it runs; maybe the program is doing some extra syscalls you aren't aware of? You should also carefully do an strace or similar on Windows and Linux as well. You may find that you're doing a system call per byte on FreeBSD but not on those other systems. Tim Kientzle ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
