> > int *i;
> > /* warn("errno: %d", errno); -- no error, nothing to check */
> > i = malloc(sizeof(int));
> > if(!i)warn("errno: %d", errno); /* only warn on failure */
> > free(i); /* -- free ign
On Sat, Apr 9, 2011 at 16:43, John Levine wrote:
> Your code is wrong. There's only a useful value in errno after
> something fails. This would be more reasonable:
>
> int main(void)
> {
> int *i;
> /* warn("errno: %d", errno); -- no error, not
>-- snip
>#include
>#include
>#include
>
>int main(void)
>{
>int *i;
>warn("errno: %d", errno);
>i = malloc(sizeof(int));
>warn("errno: %d", errno);
>free(i);
>return (errno);
>}
>-
pinpointed to following code sample.
-- snip
#include
#include
#include
int main(void)
{
int *i;
warn("errno: %d", errno);
i = malloc(sizeof(int));
warn("errno: %d", errno);
free(i);
return (errno);
}
-- snip
which will g
On 08/30/10 11:59, Yuri wrote:
google-perftools malloc library has such feature.
But does FreeBSD system allocator have it?
Maybe getrusage(2) can help you, though it also counts non-malloc()
allocations.
___
freebsd-questions@freebsd.org mailing
google-perftools malloc library has such feature.
But does FreeBSD system allocator have it?
Yuri
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "fr
e(inst);
>free(inst);
>
> return 0;
> ---
>
> Still no seg fault.
>
> The reason im am doing this is that from top I can see the memory grow as
> I connect to this app. When I disconnect, the memory used ( as displayed
> from top ) does not decr
> -Original Message-
> From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd-
> questi...@freebsd.org] On Behalf Of Dan Nelson
> Sent: 11 June 2010 09:56 PM
> To: Vikash Badal
> Cc: freebsd-questions@freebsd.org
> Subject: Re: threads and malloc/free on freeb
but it didn't:
>
> if I try this from a non threaded, non socket code:
> --
>char *z;
>
>z = (char*)malloc(1000);
>printf("malloc is %ld\n", malloc_usable_size(z));
>free(z);
>printf("after malloc is %ld\n", malloc_u
, malloc_usable_size(inst));
free(inst);
return 0;
---
output> allocated 2304
output> after free allocated 2304
from playing around, this should have segfaulted but it didn't:
if I try this from a non threaded, non socket code:
------
char
On Sat, May 22, 2010 at 1:56 AM, Dan Nelson wrote:
> In the last episode (May 22), Anoop Kumar Narayanan said:
>> I think glibc uses asynchronous free, as in it doesn't free the memory
>> immediately. So even though the memory is free'd its still part of the
>> process's address space but present
In the last episode (May 22), Anoop Kumar Narayanan said:
> I think glibc uses asynchronous free, as in it doesn't free the memory
> immediately. So even though the memory is free'd its still part of the
> process's address space but present in the free pool and so it doesn't
> crash.
FreeBSD doe
I think glibc uses asynchronous free, as in it doesn't free the memory
immediately. So even though the memory is free'd its still part of the
process's address space but present in the free pool and so it doesn't
crash.
-Anoop
On Sat, May 22, 2010 at 12:48 AM, Dan Nelson wrote:
> In the last epi
In the last episode (May 21), Vikash Badal said:
> Excuse me if this is a stupid questions.
>
> I have a thread socket application that seems to be behaving strangely
>
> In a worker thread, I have the following.
>
> ---
>LogMessage(DEBUG_0, "allocated %ld", malloc_usable_size(inst))
-----
char *z;
z = (char*)malloc(1000);
printf("malloc is %ld\n", malloc_usable_size(z));
free(z);
printf("after malloc is %ld\n", malloc_usable_size(z));
--
Output> malloc is 1024
Output> Segmentation fault (core dumped)
Can a
On Mon, 01 Dec 2008 14:57:23 -0800, Yuri <[EMAIL PROTECTED]> wrote:
> Giorgos Keramidas wrote:
>> The FreeBSD malloc(3) implementation can use either mmap() or sbrk() to
>> obtain memory from the system. It does not 'waste a high percentage of
>> memory' b
id *last = NULL;
void *ptr;
while ((ptr = malloc(chunksize)) != NULL) {
if (first == NULL)
first = ptr;
last = ptr;
malloced += chunksize;
}
printf("Malloced %zu bytes. First: %p, Last: %p\n", malloced, first, last);
exit(0);
}
--
Dan Nelson
In the last episode (Dec 01), Yuri said:
> Giorgos Keramidas wrote:
> > The FreeBSD malloc(3) implementation can use either mmap() or
> > sbrk() to obtain memory from the system. It does not 'waste a high
> > percentage of memory' but it simply maps only high addres
Giorgos Keramidas wrote:
The FreeBSD malloc(3) implementation can use either mmap() or sbrk() to
obtain memory from the system. It does not 'waste a high percentage of
memory' but it simply maps only high addresses (with an unmapped 'hole'
in lower addresses).
But the
On Mon, 01 Dec 2008 13:28:48 -0800, Yuri <[EMAIL PROTECTED]> wrote:
> I am compiling the following program:
>
> #include
> main() { printf("0x%x\n", malloc(1)); }
You should probably use printf("%p", ptr) to print pointers :)
> in 32-bit 7.1-PRERELEASE
I am compiling the following program:
#include
main() { printf("0x%x\n", malloc(1)); }
in 32-bit 7.1-PRERELEASE and get 0x28201100 which is ~673MB of 4GB
address space or 16%.
When I run the same program with the google malloc (from
devel/google-perftools)
I get much lower value
At 01:16 AM 8/5/2008, Shyamal Shukla wrote:
Hi All,
I am trying to validate my understanding of how malloc works by means
of the below C program which tries to corrupt essential information
maintained by malloc for free() operation.
The program allocates 4, 12 byte blocks (internally 16
me with a reference to the working of
>> malloc() and free()?
>
> That's because the original assumption is false. [...]
I forgot to attach the link to the jemalloc paper, apologies.
Here it is:
http://people.freebsd.org/~jasone/jemalloc/bsdcan2006/jemalloc.pdf
This describes how je
On Tue, 5 Aug 2008 11:46:06 +0530, "Shyamal Shukla" <[EMAIL PROTECTED]> wrote:
> Hi All,
>
> I am trying to validate my understanding of how malloc works by means
> of the below C program which tries to corrupt essential information
> maintained by malloc for fr
Hi All,
I am trying to validate my understanding of how malloc works by means
of the below C program which tries to corrupt essential information
maintained by malloc for free() operation.
The program allocates 4, 12 byte blocks (internally 16 bytes are allocated
for each 12 byte block
lem only occurs on FreeBSD 7.0, not any other Unix systems. In
> D> the meantime I am losing money because of it.
>
>>> On Sun, 27 Jul 2008 05:03:58 +0300,
>>> Giorgos Keramidas <[EMAIL PROTECTED]> said:
>
> G> While that's understandable, the cur
>> On Sun, 27 Jul 2008 05:03:58 +0300,
>> Giorgos Keramidas <[EMAIL PROTECTED]> said:
G> While that's understandable, the current malloc() has undergone quite
G> extensive testing by Jason Evans and a lot of people who use it in FreeBSD
G> 7.X or later. Its ability to exp
/etc/malloc.conf. The default for that file is to not exist. The man page
does not indicate which settings are used in that situation. After reading
through it I get the feeling that the default settings for D and M are 'dM'.
Hence, to return to the older malloc aproach to
Doug Hardie wrote:
On Jul 26, 2008, at 19:03, Giorgos Keramidas wrote:
While that's understandable, the current malloc() has undergone quite
extensive testing by Jason Evans and a lot of people who use it in
FreeBSD 7.X or later. Its ability to expose bugs in this way was deemed
impo
Doug Hardie wrote:
On Jul 26, 2008, at 19:03, Giorgos Keramidas wrote:
While that's understandable, the current malloc() has undergone quite
extensive testing by Jason Evans and a lot of people who use it in
FreeBSD 7.X or later. Its ability to expose bugs in this way was deemed
impo
On Jul 26, 2008, at 19:03, Giorgos Keramidas wrote:
While that's understandable, the current malloc() has undergone quite
extensive testing by Jason Evans and a lot of people who use it in
FreeBSD 7.X or later. Its ability to expose bugs in this way was
deemed
important enough that
were making use of memory after it had
been freed, but before the allocator returned it to some other
malloc() call.
That is certainly possible. However, the program has worked under
considerable load for many years with versions 3.7 to 6.2.
Problems only occur with 7.0. The program is
On Sat, 26 Jul 2008 17:36:35 -0700, Doug Hardie <[EMAIL PROTECTED]> wrote:
> On Jul 26, 2008, at 17:10, Kris Kennaway wrote:
>> Firstly, if you did not recompile the program under 7.0 then it is not
>> using the new malloc at all.
>
> It was recompiled. All there is
,
but before the allocator returned it to some other malloc() call.
That is certainly possible. However, the program has worked under
considerable load for many years with versions 3.7 to 6.2. Problems
only occur with 7.0. The program is quite complex and big. It uses
The memory allocator
allocated by malloc. Malloc was
significantly changed with 7.0 and reading through the malloc man
page there are a number of flags that can be set with /etc/
malloc.conf. The default for that file is to not exist. The man
page does not indicate which settings are used in that situation.
After
Doug Hardie wrote:
I have a program that has run correctly since FreeBSD 3.7. However,
when upgrading the server to 7.0 I am encountering issues where values
just seem to arbirtrarily change. These values are all located in
memory allocated by malloc. Malloc was significantly changed with
I have a program that has run correctly since FreeBSD 3.7. However,
when upgrading the server to 7.0 I am encountering issues where values
just seem to arbirtrarily change. These values are all located in
memory allocated by malloc. Malloc was significantly changed with 7.0
and reading
On Friday 29 June 2007, Shawn O'Connor wrote:
> On Jun 28, 2007, at 4:41 PM, Pieter de Goeje wrote:
> > On Thursday 28 June 2007, Shawn O'Connor wrote:
> >> Guys,
> >>
> >> I'm trying to do the following:
> >>
> >> mdconfig -
2GB and does
> >> use disk instead of RAM when I test using it.
> >
> > That's because you used -o reserve. Leave it out and it'll be fine.
>
> When using with -o reserve and swap it returns immediately, just like
> with -t malloc without the -o reserve (excep
On Jun 28, 2007, at 4:41 PM, Pieter de Goeje wrote:
On Thursday 28 June 2007, Shawn O'Connor wrote:
Guys,
I'm trying to do the following:
mdconfig -a -t malloc -o reserve -s 2g
You really don't want to do this. mdconfig will try to allocate 2G
of wired
memory, which will
On Thursday 28 June 2007, Shawn O'Connor wrote:
> Guys,
>
> I'm trying to do the following:
>
> mdconfig -a -t malloc -o reserve -s 2g
You really don't want to do this. mdconfig will try to allocate 2G of wired
memory, which will obviously fail, because you reall
Guys,
I'm trying to do the following:
mdconfig -a -t malloc -o reserve -s 2g
Which fails saying it can't:
mdconfig: ioctl(/dev/mdctl): Cannot allocate memory
I saw some old post advocated using -t swap instead, saying that swap
probably wouldn't be used until real memory wa
now is the hard drive, so
> >> I have been booting a minimal system off a flash drive. The box has
> >> two gigs of ram. if I try to create a malloc backed md device bigger
> >> then 300mb(this is not the exact limit but it is between 300mb and
> >> 400mb) it
e box has
> two gigs of ram. if I try to create a malloc backed md device bigger
> then 300mb(this is not the exact limit but it is between 300mb and
> 400mb) it fails. If I use -o reserve the mdconfig command fails and if
> I don't then when I try and use that space FreeBSD cra
On Sun, May 13, 2007 at 09:34:46PM -0700, Kevin Downey wrote:
> I am building a shiny new desktop, the only thing I don't have right
> now is the hard drive, so
> I have been booting a minimal system off a flash drive. The box has
> two gigs of ram. if I try to create a malloc
I am building a shiny new desktop, the only thing I don't have right
now is the hard drive, so
I have been booting a minimal system off a flash drive. The box has
two gigs of ram. if I try to create a malloc backed md device bigger
then 300mb(this is not the exact limit but it is between
Olaf Greve wrote:
Hi all,
A colleague of mine has run into a weird issue, for which we hope
someone knows a solution (or otherwise: if someone knows there's no
(easy) solution, that's also good to know.
The issue: when running a script that will consume a large amount of
memory (under Free
Hi guys,
Well, my colleague has done some more RTFM-ing and Googling, and he
found the following solution:
Put kern.maxdsiz="1073741824" in /boot/loader.conf (see the example in
/boot/defaults/loader.conf), and then reboot.
That way a new kernel compilation was not required.
Tnx for thinking
is pretty much idle.
The returned error in httpd-error.log is:
httpd in malloc(): error: allocation failed
We tried fiddling around with the php.ini and httpd.conf files, after
Googling and trying stuff like RlimitMem (which apparently only seems to
have effect for the CGI version of PHP and n
Jonathon McKitrick wrote:
If I want to write an assembly language program without using libc, is it ok
to use mmap and a file descriptor of -1 to allocate memory?
How about sbrk()?
jm
--
What's good for the goose is good for the gander.
What the hell is a gander, anyway?
A male goose... :-)
If I want to write an assembly language program without using libc, is it ok
to use mmap and a file descriptor of -1 to allocate memory?
jm
--
What's good for the goose is good for the gander.
What the hell is a gander, anyway?
___
freebsd-questions@fre
On 2005-08-19 15:00, Dmitry Mityugov <[EMAIL PROTECTED]> wrote:
>On 8/19/05, Giorgos Keramidas <[EMAIL PROTECTED]> wrote:
>>On 2005-08-18 22:17, Dmitry Mityugov <[EMAIL PROTECTED]> wrote:
>>>On 8/18/05, Giorgos Keramidas <[EMAIL PROTECTED]> wrote:
It may be surprising, but casting back and for
On 8/19/05, Giorgos Keramidas <[EMAIL PROTECTED]> wrote:
> On 2005-08-18 22:17, Dmitry Mityugov <[EMAIL PROTECTED]> wrote:
> >On 8/18/05, Giorgos Keramidas <[EMAIL PROTECTED]> wrote:
...
> >> It may be surprising, but casting back and forth *MAY* change the value
> >> of the pointer.
> >...
> >
> >
On 2005-08-18 22:17, Dmitry Mityugov <[EMAIL PROTECTED]> wrote:
>On 8/18/05, Giorgos Keramidas <[EMAIL PROTECTED]> wrote:
>>On 2005-08-18 12:08, Sergey Matveychuk <[EMAIL PROTECTED]> wrote:
>>>Chuck Swiger wrote:
>>>>>What is pointer
On 8/18/05, Giorgos Keramidas <[EMAIL PROTECTED]> wrote:
> On 2005-08-18 12:08, Sergey Matveychuk <[EMAIL PROTECTED]> wrote:
> >Chuck Swiger wrote:
> >>>What is pointer coercion? I have no pointer before malloc() returns.
> >>
> >> Right. Well,
On 2005-08-18 12:08, Sergey Matveychuk <[EMAIL PROTECTED]> wrote:
>Chuck Swiger wrote:
>>>What is pointer coercion? I have no pointer before malloc() returns.
>>
>> Right. Well, malloc returns a (void *), but most people want to use the
>> memory malloc retur
hitectures. It's quite clear for me now.
What is pointer coercion? I have no pointer before malloc() returns.
Right. Well, malloc returns a (void *), but most people want to use the
memory malloc returns to hold their own arrays, structs, whatever, which
means that you need to be abl
-
> From: [EMAIL PROTECTED] [mailto:owner-freebsd-
> [EMAIL PROTECTED] On Behalf Of Erik Trulsson
> Sent: Wednesday, August 17, 2005 4:33 PM
> To: Sergey Matveychuk
> Cc: [EMAIL PROTECTED]
> Subject: Re: man malloc
>
> On Thu, Aug 18, 2005 at 01:03:46AM +0400, Sergey Matvey
Sergey Matveychuk wrote:
I know it may be stupid, but I can't understand this sentence from
malloc(3) man page:
"
The allocated space is suitably aligned (after possible pointer
coercion) for storage of any type of object.
"
What does "suitable aligned for storage of
On Thu, Aug 18, 2005 at 01:03:46AM +0400, Sergey Matveychuk wrote:
> I know it may be stupid, but I can't understand this sentence from
> malloc(3) man page:
>
> "
> The allocated space is suitably aligned (after possible pointer
> coercion) for storage of any type o
I know it may be stupid, but I can't understand this sentence from
malloc(3) man page:
"
The allocated space is suitably aligned (after possible pointer
coercion) for storage of any type of object.
"
What does "suitable aligned for storage of *any* type of object&quo
UPDATING does mention libmap.conf... adding the suggested values was
required once I got gaim rebuilt.
So *shrug* nevermind I guess :)
-Charlie
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe
So... lots of things are crashing since updating to 5.3, and a google
search revealed something about malloc() debugging options.
UPDATING mentions no such thing. :(
The 5.3 release notes mention it, however.
Crashing apps:
fluxbox: recompiled boxtools and fluxbox. Worked.
gaim: tried to
On Sat, Oct 16, 2004 at 08:06:35AM +0200, Niclas Zeising wrote:
> Hi list!
>
> I know you can turn malloc debugging on and of by symlinking
> /etc/malloc.conf, i.e. ln -s AJ /etc/malloc.conf. But how do i check if
> the debugging is on or not? I can't find a /etc/malloc.
Hi list!
I know you can turn malloc debugging on and of by symlinking
/etc/malloc.conf, i.e. ln -s AJ /etc/malloc.conf. But how do i check if
the debugging is on or not? I can't find a /etc/malloc.conf in my
system, niether can i find a AJ symlink.
I'm running 5.3-BETA7 now, but are p
raid5 get tar'd and gzip'd to another
directory on the
raid5. The panic occured during one of these sessions. The system was
locked
up tight in "syncing disks", I'm assuming because vinum needs malloc to
finish
the sync.
Although it occurred while vinum was very busy, is
On 2004-06-07 12:23, Odhiambo Washington <[EMAIL PROTECTED]> wrote:
> Hi gurus,
>
> What's the maximum memory can be allocated to a single process by default ?
If memory limits aren't at work, all available memory. But the default
is to have user limits, so you should probably check /etc/login.c
Hi gurus,
What's the maximum memory can be allocated to a single process by default ?
-Wash
http://www.netmeister.org/news/learn2quote.html
--
+==+
|\ _,,,---,,_ | Odhiambo Washington<[EMAIL PROTECTED]>
Zzz /,
ide the memory in larger regions and to
> >tell malloc which chunk to use for the next few calls, respectively when a
> >whole chunk could be freed. But I don't know how to do this.
>
> Consider using (or searching for information about) a zone-based malloc.
> NEXTSTEP us
gt;free != info->total)
return;
/* Find & remove this page in the queue */
while (*mp != info) {
mp = &((*mp)->next);
==
====
FreeBSD 5.2-CURRENT Sun May 2 08:40:29 JST 2004
CPU: Intel(R) Xeon(TM) CPU
Till Plewe wrote:
My problem is essentially that freeing large numbers of small chunks
of memory can be very slow. I have run into this problem twice so far.
[ ... ]
One solution would be to divide the memory in larger regions and to
tell malloc which chunk to use for the next few calls
xywz6.s:95: Warning: rest of line ignored; first ignored character is `,'
In any case since I have the pointers in a hash table (Judy array)
rather than an array I need extra time for look-up/deleting the entry
in the hash table as well. If I could get malloc to use a fixed memory
region for the p
M 1048576
#define SIZE 128
void *mypointers[NUM];
struct timeval elap;
struct rusage r_s, r_e;
int main(void)
{
int i;
printf("malloc:");
fflush(stdout);
for (i = 0; i < NUM; i++)
{
mypointers[i] = malloc(SIZE);
}
in order to keep memory consumption as low as possible
without sacrificing speed I am using Judy arrays (see the Judy project
at source forge). But that means I have no direct control over how
malloc is called.
One solution would be to divide the memory in larger regions and to
tell malloc which
d buy a G5 machine, but
their implementation of BSD seems still only able to malloc() up to a
4Gb process limit which is hardly what their advertising says!
Find the right list at apple to ask this for your G5 machine. There
are separate libraries for the 64bit malloc etc so to be extra sure go
find
ity to handle seriously huge datasets. We did buy a G5 machine, but
> their implementation of BSD seems still only able to malloc() up to a
> 4Gb process limit which is hardly what their advertising says!
>
> Therefore, does the AMD64 FreeBSD port allow you to malloc() or mmap()
> past
still only able to malloc() up to a
4Gb process limit which is hardly what their advertising says!
Therefore, does the AMD64 FreeBSD port allow you to malloc() or mmap()
past this 4Gb per process limit. We're typically wanting to address up
to 256Gb in a single process.
Thanks in advance for an
: recursive call
suidperl in free(): warning: recursive call
suidperl in free(): warning: recursive call
suidperl in free(): warning: recursive call
suidperl in free(): warning: recursive call
suidperl in malloc(): warning: recursive call
Out of memory!
I saw a man page called malloc, and it says
buffer.c), in which one of two malloc calls
fail, unwinding all the way to the top where xmms prints it's lovely
message.
The actual call to malloc looks sane enough to my eyes (131072 bytes, it
does this successfully beforehand so I'm guessing no probs there).
I'm suspecting that
>>>> It does not matter what freebsd does, C does
>>>> not require that malloc initialize space
>>>> according to Kernighan and Ritchie.
>> ... What's really bad, is that freebsd could
>> potentally change there behavor down the lin
man calloc:
The calloc() function allocates space for number objects, each size
bytes
in length. The result is identical to calling malloc() with an
argument
of ``number * size'', with the exception that the allocated memory
is
explicitly initialized to zero bytes.
21:42:23, Robert Huff wrote:
> >James Jacobsen writes:
> >> It does not matter what freebsd does, C does not require that
> >> malloc initialize space according to Kernighan and Ritchie.
> >
> >I knew that, and agree depending on a particular behavior is bad
> &
In the last episode (Oct 05), James Jacobsen said:
> On 10/05/03 21:42:23, Robert Huff wrote:
> >James Jacobsen writes:
> >> It does not matter what freebsd does, C does not require that
> >> malloc initialize space according to Kernighan and Ritchie.
> >
> &g
o its go to lead to some weird behavior. :-)
--James
On 10/05/03 21:42:23, Robert Huff wrote:
James Jacobsen writes:
> It does not matter what freebsd does, C does not require that
> malloc initialize space according to Kernighan and Ritchie.
I knew that, and agree depending on a
Huff wrote:
James Jacobsen writes:
> It does not matter what freebsd does, C does not require that
> malloc initialize space according to Kernighan and Ritchie.
I knew that, and agree depending on a particular behavior is
bad programming practice. That said, there's a lot of "
It does not matter what freebsd does, C does not require that malloc
initialize space according to Kernighan and Ritchie. Its a good book, I
would say its worth the forty dollars.
--Will
On 10/05/03 20:32:00, Dan Nelson wrote:
In the last episode (Oct 05), Robert Huff said:
> Dan Nel
In the last episode (Oct 05), Robert Huff said:
> Dan Nelson writes:
> > Could be one of two problems. The program either malloced memory
> > and tried to use it without zeroing it, or it freed some memory
> > and tried to keep using it. In -current, the malloc has the
Dan Nelson writes:
> Could be one of two problems. The program either malloced memory
> and tried to use it without zeroing it, or it freed some memory
> and tried to keep using it. In -current, the malloc has the J
> debugging flag set, which fills malloced and freed memory
>
> The following reply was made to PR kern/53257; it has been noted by GNATS.
>
> From: =?iso-8859-1?Q?Anders_Lind=E9n?= <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Cc:
> Subject: Re: kern/53257: malloc() never returns 0
> Date: Fri, 13 Jun 2003 10:31:
Yes, fix the bug in the application that is making incorrect use of
free(). In this instance the application is trying to free a pointer
that was never malloced in the beginning, so cannot sensibly be freed.
See the malloc(3) manpage for more details.
> from happening on a rare program that
on a rare program that works well on other operating
> systems, just not BSD (yes it is using malloc)?
That means the program is trying to free a pointer higher in memory
than the highest pointer malloc() has ever allocated. It's a good sign
that the program is doing something it shouldn
This is almost depressing...
What would cause:
in free(): warning: junk pointer, too high to make sense
(more so, is there a way to "fix" this, not what would cause this)
from happening on a rare program that works well on other operating
systems, just not BSD (yes it is us
92 matches
Mail list logo
