jb gmail.com> writes:
> ...
> So far, the options could be as follows:
> - realloc_flags(p, s, option)
> where option is one or a combination (where appropriate) of:
> REALLOCF_ANY- default (move or no-move; regular
> real
e
specific and thus less forgiving).
Think of it as being presented with a chance to become part of history,
as a co-creator of a new-and-improved memory management function,
admittedly being many OS' and libraries' Achilles' heel :-)
jb
_
no-move; regular realloc())
REALLOCF_NO_MOVE- no-move
REALLOCF_ELASTIC- combined with REALLOCF_NO_MOVE
REALLOCF_FORCE - combined with REALLOCF_NO_MOVE
REALLOCF_FALLBACK_ANY - combined with REALLOCF_NO_MOVE or its
derivatives like R
pointers to already-allocated memory.
Yeap. It is like asking teenagers to be abstinent ...
http://www.youtube.com/watch?v=SWlbN2b1PGg
Good luck !
jb
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-curr
emory available to extend
the size of the object
Reference to realloc():
http://www.cplusplus.com/reference/cstdlib/realloc/
jb
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
nduce reallocation function to do "the right thing" thru one API
call with clear and smart options.
If it does 90% of what we would ideally want, then the job is done.
jb
___
freebsd-current@freebsd.org mailing list
http://lists.free
That means one call with options, with a specific (wanted by user) result.
Of course, thinking thru the options (default, mutual exclusion, etc) is
an important process and subject to RFC.
A user-empowering API. No magic, no hacks.
So, how about Request-for-Enhancement to GNU C lib, and the ugl
Mac OS X), are a violations of a clean,
safe, and maintainable API.
Note that malloc_usable_size() is a GNU C Library extension, not part of
Single UNIX Specification.
jb
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/l
ants to track the *requested size* programmatically, it is its
business to do it and it can be done very easily.
Some of these guys got it perfectly right:
http://stackoverflow.com/questions/5813078/is-it-possible-to-find-the-memory-allocated-to-the-pointer-without
.
This is hair-raising:
http://lwn.net/Articles/319686/
Result ? The same code works here, but may not elsewhere.
It follows, you should remove malloc_usable_size() from user space instead.
jb
___
freebsd-current@freebsd.org mailing list
http://lis
connected to eth0,
http://www.freebsd.org/doc/handbook/network-bridging.html
jb
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Hi,
these represent machine lockups, if not false positives.
http://www.freebsd.org/cgi/query-pr.cgi?pr=182139&cat=
jb
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any
Glen Barber FreeBSD.org> writes:
> ...
> Can you try the 20130907 -CURRENT snapshot here?
>
> http://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/i386/10.0/
>
> Glen
OK. That worked out.
jb
___
freebsd-current@freebsd.
Thomas Mueller bellsouth.net> writes:
>
> > FreeBSD-10.0-ALPHA1-i386-disc1.iso
> > Verified checksum.
> > I can not boot from CD-RW at all - it does not seem to be recognized.
> > Anybody else has similar experience ?
> > jb
>
> Is your CD-RW n
Hi,
FreeBSD-10.0-ALPHA1-i386-disc1.iso
Verified checksum.
I can not boot from CD-RW at all - it does not seem to be recognized.
Anybody else has similar experience ?
jb
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman
Eitan Adler eitanadler.com> writes:
>
> On 18 November 2012 18:44, Mateusz Guzik gmail.com> wrote:
> > Just take user name from id -nu.
>
> While that does provide the $user value I want, id is in /usr/bin/
> which may not
jb gmail.com> writes:
> ...
> There are memory management subsystem considerations against utilizing
> tmpfs (memory + swap) for /tmp:
> ...
> - Out-of-Memory (OOM) killer
> Due to it, on heavy loaded systems processes dying on memory pressure.
- Pterodactyl
The next
jb gmail.com> writes:
> ...
Chuck Burns brea...@gmail.com
1:01 AM (16 hours ago)
My experiences with using tmpfs as /tmp
--
It works fine. until it doesn't.
I've had mountpoints run out of space, checked df and the mountpoint had been
reduced to some
nd how to customize their systems for a task.
To offer it as a default setup is not called for, regardless of memory plus
swap sizes.
jb
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
upported by tmpfs.
I do not know about you, but I feel differently about /tmp even as part of "/"
fs beeing bombed by mega-size files, and /tmp as /tmpfs (main memory plus swap)
getting full or even reaching some preset value and having some priority job or
its data or caches being swapped.
jb
p://fedoraproject.org/wiki/Talk:Features/var-run-tmpfs
jb
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
s).
/etc/rc.conf:
powerd_flags="-n hadp"
performance_cx_lowest="C2"
economy_cx_lowest="C2"
performance_cpu_freq="HIGH"
Test:
-
- measure dev.cpu.0.freq
- measure dev.cpu.0.freq during compilation
- measure dev.
first.c -o libfirst.so
> gcc -O0 -g toto.c -lfirst -L. -o test
> export LD_LIBRARY_PATH=$PWD
> gdb ./test
> ...
What is your toto.c (source code) ?
What about your main.c in compilation ?
jb
___
freebsd-current@freebsd.org mailing list
htt
is there any debugging method I as a user can utilize to collect specific
info that could aid devs ?
jb
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to &quo
lly ?
Any comments before I file a PR# ?
jb
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
quirement).
This mode is particularly useful if you need to repair your system by
copying a file from a CD-ROM to your hard drive, or if you need to
reconfigure a service that is preventing your computer from starting
properly.
This functionality
cter change -- it's
> not clear to me a patch would be easier for a commiter to handle than
> just finding and changing the only occurrance of "0661" in lpr.c.)
>
Yes, that's what we suggested, in PR filed as well.
Let's change lpr.c so that the .seq create pe
ningless ?
Example:
# cat /var/spool/output/lpd/.seq
#! /usr/local/bin/bash
touch /tmp/jb-test-`echo $$`
# ls -al /var/spool/output/lpd/.seq
-rw-rx 1 root daemon 54 Feb 29 17:05 /var/spool/output/lpd/.seq
# /var/spool/output/lpd/.seq
#
# ls /tmp/jb*
/tmp/jb-test-61789
# chmod 0640 /var/
jb gmail.com> writes:
> ...
> I would suggest (if you can) that you change the .seq permissions to 0664 and
> watch what happens to it - the purpose is to narrow down who/what changed its
> mode.
> Some history. logs. and some ad hoc "watch script" would do it.
Tak
gt; In any case, it seems either lpr.c needs to be changed,
> or if 0661 is necessary, then the periodic sripts need to
> be changed to ignore this file.
>
The periodic script is OK.
Here is the author's view:
http://lists.freebsd.org/pipermail/freebsd-hackers/2010-October/033
Jason Hellenthal dataix.net> writes:
>
>
> On Wed, Feb 29, 2012 at 08:54:20AM +, jb wrote:
> >
> > 0641 ? Are you sure ?
>
> Not at all ;)
>
> > > > > > > Checking negative group permissions:
> > > > > > > 7
nnot
> find any at the moment. E_LACKINGSLEEP
Check the PR filing again - I appended a relevant comment.
Also, Linux distros (if you can swallow it ...) also disallowed it due to sec
reason, but in a clumsy way by making sure the "exec" permission is turned off
in a package in
perm
checks for risque condition like
! -perm +010 -and -perm +001
The file should not be executable, according to its purpose.
So the lpr.c should be changed from
if ((fd = open(buf, O_RDWR|O_CREAT, 0661)) < 0) {
to
if ((fd = open(buf, O_RDWR|O_CREAT, 0660)) < 0) {
33 matches
Mail list logo
