Re: threaded, forked, rethreaded processes will deadlock
Brian Fundakowski Feldman wrote: > Could you, and anyone else who would care to, check this out? It's a regression fix but it also makes the code a little bit clearer. Thanks! Index: lib/libc/stdlib/malloc.c Why does malloc need to change for this? Unless there's a really good reason, I don't want the extra branches in the locking functions. Thanks, Jason ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: A patch of HPTIOP driver for 7.1-RELEASE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Shaowei, It seems that I can not apply your patch directly, I have tried to do it manually, as attached, please let me know if it's Ok. I can commit for you against -HEAD if it looks fine and take care for MFC. Note that, however, I am more or less concerned about the driver if 32-bit utility is running on amd64 platform. There seems to have three pointer style field in hpt_iop_ioctl_param. I have checked hptrr(4) and found that it has defined a 32-bit compatibility ioctl structure. According to my understanding to hptiop(4), this could be a problem. PS. For faster handling it is probably a good idea to submit patch through our PR system: http://www.freebsd.org/send-pr.html Shaowei Wang (wsw) wrote: > Hi, guys > > hptiop driver in the 7.1 release has a little bug. > Because this issue the Raid-manage GUI program which we provided can NOT > work anymore. > > So we give the patch: > > Index: hptiop.h > === > --- hptiop.h(revision 186851) > +++ hptiop.h(working copy) > @@ -260,7 +260,7 @@ > unsigned longlpOutBuffer; /* output data buffer */ > u_int32_tnOutBufferSize;/* size of output data buffer > */ > unsigned longlpBytesReturned; /* count of HPT_U8s returned */ > -}; > +}__attribute__((packed)); > > #define HPT_IOCTL_FLAG_OPEN 1 > #define HPT_CTL_CODE_BSD_TO_IOP(x) ((x)-0xff00) > > > > -wsw > > // > > 大家好： > > hptiop的驱动在7.1发行版中有个小错误。 > 这个小错误导致了我们提供的阵列管理程序无法运行。 > > 我们给出了补丁： > > Index: hptiop.h > === > --- hptiop.h(revision 186851) > +++ hptiop.h(working copy) > @@ -260,7 +260,7 @@ > unsigned longlpOutBuffer; /* output data buffer */ > u_int32_tnOutBufferSize;/* size of output data buffer > */ > unsigned longlpBytesReturned; /* count of HPT_U8s returned */ > -}; > +}__attribute__((packed)); > > #define HPT_IOCTL_FLAG_OPEN 1 > #define HPT_CTL_CODE_BSD_TO_IOP(x) ((x)-0xff00) > > > > -wsw > > > > > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAklxDk4ACgkQi+vbBBjt66CvUQCfaAnk0XQTh3Wrn2O4Dy0pEUFW oqsAoIvlTSNGRDg71SNyGfZ5VjDh9Z93 =1xSB -END PGP SIGNATURE- Index: sys/dev/hptiop/hptiop.h === --- sys/dev/hptiop/hptiop.h ï¼çæ¬ 187338ï¼ +++ sys/dev/hptiop/hptiop.h ï¼å·¥ä½å¯æ¬ï¼ @@ -260,7 +260,7 @@ unsigned longlpOutBuffer; /* output data buffer */ u_int32_tnOutBufferSize;/* size of output data buffer */ unsigned longlpBytesReturned; /* count of HPT_U8s returned */ -}; +} __attribute__((packed)); #define HPT_IOCTL_FLAG_OPEN 1 #define HPT_CTL_CODE_BSD_TO_IOP(x) ((x)-0xff00) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: threaded, forked, rethreaded processes will deadlock
On Fri, Jan 09, 2009 at 09:39:08AM -0800, Julian Elischer wrote:
> Brian Fundakowski Feldman wrote:
>> On Thu, Jan 08, 2009 at 11:09:16PM -0800, Julian Elischer wrote:
>>> Brian Fundakowski Feldman wrote:
On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel Eischen wrote:
> On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote:
>
>> It appears that the post-fork hooks for malloc(3) are somewhat broken
>> such that
>> when a threaded program forks, and then its child attempts to go
>> threaded, it
>> deadlocks because it already appears to have locks held. I am not
>> familiar
>> enough with the current libthr/libc/rtld-elf interaction that I've been
>> able
>> to fix it myself, unfortunately.
> There's really nothing to fix - according to POSIX you are only
> allowed to call async-signal-safe functions in the child forked
> from a threaded process. If you are trying to do anything other
> than that, it may or may not work on FreeBSD, but it is not
> guaranteed and is not portable.
>
> The rationale is that what is the point of forking and creating
> more threads, when you can just as easily create more threads in
> the parent without forking? The only reason to fork from a threaded
> process is to call one of the exec() functions.
Well, it worked until the last major set of changes to malloc. For me,
the point
was that I was able to have transparent background worker threads in any
program
regardless of its architecture, using the standard pthread fork hooks.
Could you
point me to the POSIX section covering fork and threads? If it's really
not
supposed to work then that's fine, but there's an awful lot of code there
dedicated
to support going threaded again after a fork.
>>> Practically, you can't go threaded again after a fork
>>> (by which I mean creating new threads or use things
>>> like mutexes etc.) in any posix system I know of.
>>>
>>> It would require that:
>>> The forking thread stop until:
>>> Every other thread has released every resource it owns
>>> and reports itself to be in a "safe quiescent state",
>>> or at least report every resource it owns, especially
>>> locks,
>>> and
>>> After the fork:
>>> The child, post fork, to take ownership of all
>>> of them, and free them.
>>>
>>> You might be able to do that in a simple
>>> threaded program, but consider then that the libraries may have
>>> threads running in them of which you are unaware, and that
>>> some of the resources may interract with resources owned by the
>>> forking thread.
>>>
>>> Add to this that there may be a signal thrown into this mix as well
>>>
>>> (signals are the bane of thread developement)
>>
>> Well, I wouldn't mind showing all of you what I can of what I had been doing
>> with the background threads -- it works pretty well modulo this particular
>> malloc lock bug. Due to it being inappropriate to share library resources
>> between a child and parent for an open socket connection, I always considered
>> the only "safe" behavior to be going single-threaded for the duration of the
>> fork
>> processes in both the parent and child, and the pthread_atfork(3) hooks have
>> been
>> sufficient to do so.
>
>
> a
> well going single threaded for the duration of the fork, changes
> everything!
Could you, and anyone else who would care to, check this out? It's a regression
fix but it also makes the code a little bit clearer. Thanks!
Index: lib/libc/stdlib/malloc.c
===
--- lib/libc/stdlib/malloc.c(revision 187160)
+++ lib/libc/stdlib/malloc.c(working copy)
@@ -415,6 +415,7 @@
/* Set to true once the allocator has been initialized. */
static bool malloc_initialized = false;
+static bool malloc_during_fork = false;
/* Used to avoid initialization races. */
static malloc_mutex_t init_lock = {_SPINLOCK_INITIALIZER};
@@ -1205,7 +1206,7 @@
malloc_mutex_lock(malloc_mutex_t *mutex)
{
- if (__isthreaded)
+ if (__isthreaded || malloc_during_fork)
_SPINLOCK(&mutex->lock);
}
@@ -1213,7 +1214,7 @@
malloc_mutex_unlock(malloc_mutex_t *mutex)
{
- if (__isthreaded)
+ if (__isthreaded || malloc_during_fork)
_SPINUNLOCK(&mutex->lock);
}
@@ -1260,7 +1261,7 @@
{
unsigned ret = 0;
- if (__isthreaded) {
+ if (__isthreaded || malloc_during_fork) {
if (_pthread_mutex_trylock(lock) != 0) {
/* Exponentially back off if there are multiple CPUs. */
if (ncpus > 1) {
@@ -1296,7 +1297,7 @@
malloc_spin_unlock(pthread_mutex_t *lock)
{
- if (__isthreaded)
+ if (__isthreaded || malloc_during_fork)
_pthread_mutex_unlock(lock);
}
@@ -5515,9 +5516,8 @@
void
_malloc_prefork(void)
{
+ arena_t *larenas
Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's
On Fri, Jan 16, 2009 at 10:33:15AM -0800, Nate Eldredge wrote:
> Pop quiz: which of the following statements is correct?
>
> #include
> #include
>
> execl("/bin/sh", "/bin/sh", 0);
> execl("/bin/sh", "/bin/sh", NULL);
None, as NULL is allowed to expand to 0. You have to write
execl("/bin/sh", "/bin/sh", (char *)0);
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's
On Fri, 16 Jan 2009, Garrett Cooper wrote:
On Fri, Jan 16, 2009 at 2:52 AM, Thierry Herbelot
wrote:
Le Friday 16 January 2009, Garrett Cooper a écrit :
On Fri, Jan 16, 2009 at 2:21 AM, Christoph Mallon
#include
#include
#include
int
main()
{
struct stat sb;
int o_errno;
if (stat("/some/file/that/doesn't/exist", &sb) != 0) {
o_errno = errno;
printf("Errno: %d\n", errno);
printf("%s\n", strerror(o_errno));
}
return 0;
}
with this, it's better on an amd64/ RELENG_7 machine :
% diff -ub badfile.c.ori badfile.c
--- badfile.c.ori 2009-01-16 11:49:44.778991057 +0100
+++ badfile.c 2009-01-16 11:49:03.470465677 +0100
@@ -1,6 +1,7 @@
#include
#include
#include
+#include
int
main()
Cheers
TfH
That's hilarious -- why does it pass though without issue on x86 though?
-Garrett
As pointed out, when you don't have a declaration for strerror, it's
implicitly assumed to return `int'. This "feature" was widely used in the
early days of C and so continues to be accepted by compilers, and gcc by
default doesn't warn about it.
On x86, int and char * are the same size. So even though the compiler
thinks strerror is returning an int which is being passed to printf, the
code it generates is the same as for a char *. On amd64, int is 32 bits
but char * is 64. When the compiler thinks it's using int, it only keeps
track of the lower 32 bits, and the upper 32 bits get zeroed. So the
pointer that printf receives has had its upper 32 bits zeroed, and no
longer points where it should. Hence segfault.
Since running on amd64 I've seen a lot of bugs where people carelessly
assume (perhaps without noticing) that ints and pointers are practically
interchangeable, which works on x86 and the like but breaks on amd64.
Variadic functions are special offenders because the compiler can't do
much type checking.
Pop quiz: which of the following statements is correct?
#include
#include
execl("/bin/sh", "/bin/sh", 0);
execl("/bin/sh", "/bin/sh", NULL);
--
Nate Eldredge
neldre...@math.ucsd.edu___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's
On Fri, Jan 16, 2009 at 2:52 AM, Thierry Herbelot
wrote:
> Le Friday 16 January 2009, Garrett Cooper a écrit :
>> On Fri, Jan 16, 2009 at 2:21 AM, Christoph Mallon
>>
>> #include
>> #include
>> #include
>>
>> int
>> main()
>> {
>>
>> struct stat sb;
>>
>> int o_errno;
>>
>> if (stat("/some/file/that/doesn't/exist", &sb) != 0) {
>> o_errno = errno;
>> printf("Errno: %d\n", errno);
>> printf("%s\n", strerror(o_errno));
>> }
>>
>> return 0;
>>
>> }
>>
> with this, it's better on an amd64/ RELENG_7 machine :
>
> % diff -ub badfile.c.ori badfile.c
> --- badfile.c.ori 2009-01-16 11:49:44.778991057 +0100
> +++ badfile.c 2009-01-16 11:49:03.470465677 +0100
> @@ -1,6 +1,7 @@
> #include
> #include
> #include
> +#include
>
> int
> main()
>
>Cheers
>
>TfH
That's hilarious -- why does it pass though without issue on x86 though?
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
a CD you might interested in
Dear All, I think the following CD might interest you. URL: http://www.ournetos.com/itcf3.iso & http://www.compass.com.hk/itcf3.iso It is a bootable CD using grub-0.95 as of Nevada-b99, so, it is UNDI-based NICs netbootable. Also, I'd put onto it gPXE-0.96 *.lkrn for using gPXE of http://etherboot.org. Network installation media for a) FreeBSD-7.1 b) Nevada-b105 c) Debian-4.0 d) Fedora-10 e) OpenSUSE-11.1 f) Ubuntu-8.10 are on it. Also, flavors of Linuxes may be WANbooted on PCs w/ internet connectivity. Wish you enjoy it, Clarence Data Expert Limited c...@ournetos.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to access kernel memory from user space
On Thu, Jan 15, 2009 at 01:22:18PM -0600, Gerry Weaver wrote:
> _
>
> From: Alexej Sokolov [mailto:bsd.qu...@googlemail.com]
> To: Gerry Weaver [mailto:ger...@compvia.com]
> Cc: freebsd-hackers@freebsd.org
> Sent: Thu, 15 Jan 2009 12:31:00 -0600
> Subject: Re: How to access kernel memory from user space
>
>
>
>
> 2008/12/23 Gerry Weaver
> Hello All,
>
> I am working on a driver that collects various network statistics via pfil.
> I have a simple array of structures that I use to store the statistics. I
> also have a user space process that needs to collect these statistics every
> second or so. A copy operation from kernel to user space would be too
> expensive. Is there a mechanism that would allow me to gain direct access to
> my kernel array from user space? The user process would only need read
> access. It seems like maybe this could be done with mmap, but since this is
> not a character driver, there is no device file etc.. I'm a newbie, so I
> apologize if this is something that should be obvious.
>
>
> Thanks in advance,
> Gerry
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
> Hi,
> some times ago I solve this task. That's my solution in a system call
> (whithout cdev).
> Thanx in advance for founded mistakes and possible bugs (-:
>
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> #include
> #include
> #include
> #include
> #include
> #include
>
>
> /* Arguments for syscall */
> struct args {
>
> /* Pointer to allocated Buffer */
> unsigned int *p;
> };
>
> /* String to be located in maped buffer */
> const char *str = "BSD IS SEXY";
>
> /* Syscall func */
> static int
> syscf(struct thread *td, void *sa)
> {
> int error;
> struct args *uap;
> vm_offset_t addr; /* Kernel space address */
> vm_offset_t user_addr; /* User space address */
>
> struct proc *procp = (struct proc *)td->td_proc;
>
> struct vmspace *vms = procp->p_vmspace;
>
> uap = (struct args *)sa;
>
> PROC_LOCK(procp);
> user_addr = round_page((vm_offset_t)vms->vm_daddr +
> lim_max(procp, RLIMIT_DATA));
> PROC_UNLOCK(procp);
>
> MALLOC(addr, vm_offset_t, PAGE_SIZE, M_DEVBUF, M_WAITOK | M_ZERO);
>
> vm_map_entry_t myentry;
> vm_object_t myobject;
> vm_pindex_t mypindex;
> vm_prot_t myprot;
> boolean_t mywired;
> vm_ooffset_tobjoffset;
>
> vm_map_lookup(&kmem_map, addr, VM_PROT_ALL,
> &myentry, &myobject, &mypindex, &myprot, &mywired);
> /* OUT */
> vm_map_lookup_done(kmem_map, myentry);
>
> printf("---> Syscall: hint for allocating space = 0x%X\n", addr);
>
> if (myobject == kmem_object){
> printf("---> Syscall: Yes, it is kmem_obj! \n");
> }
>
> /* Offset in vm_object */
> objoffset = addr - myentry->start + myentry->offset;
>
> printf("--> Syscall: Object offset = 0x%X \n", (unsigned
> int)objoffset);
>
> /*
> * Try to map kernel buffer to user space
> */
> vm_object_reference(myobject); /* NEEDED Increment vm_obj references
> */
> error = vm_map_find(&vms->vm_map, myobject, objoffset, (vm_offset_t
> *)&user_addr,
> PAGE_SIZE, TRUE, VM_PROT_RW, VM_PROT_RW,
> MAP_ENTRY_NOFAULT);
>
> if (error == KERN_SUCCESS) {
> /* copy string using kernel address */
> size_t len;
> copystr(str, (void *)addr, 12, &len);
>
> /*
> * Tell to user process it's user space address
> */
> *uap->p = user_addr;
>
> /*
> * Try to read the string using user space address
> */
> printf("String: %s\n", (char *)*uap->p);
>
> printf("---> Syscall: user_addr for allocating space =
> 0x%X\n", user_addr);
> }
>
> return (0);
> }
>
> /* Sysent entity for syscall */
> static struct sysent sc_sysent = {
> 1, /* Number of
> arguments */
> syscf /* Syscall function*/
> };
>
> /* Offset in sysent[] */
> static int offset = NO_SYSCALL;
>
> /* Loader */
> static int
> load (struct module *m, int cmd, void *something)
> {
> int error = 0;
> switch(cmd){
> case MOD_LOAD:
> printf("Mod
Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's
Le Friday 16 January 2009, Garrett Cooper a écrit :
> On Fri, Jan 16, 2009 at 2:21 AM, Christoph Mallon
>
> #include
> #include
> #include
>
> int
> main()
> {
>
> struct stat sb;
>
> int o_errno;
>
> if (stat("/some/file/that/doesn't/exist", &sb) != 0) {
> o_errno = errno;
> printf("Errno: %d\n", errno);
> printf("%s\n", strerror(o_errno));
> }
>
> return 0;
>
> }
>
with this, it's better on an amd64/ RELENG_7 machine :
% diff -ub badfile.c.ori badfile.c
--- badfile.c.ori 2009-01-16 11:49:44.778991057 +0100
+++ badfile.c 2009-01-16 11:49:03.470465677 +0100
@@ -1,6 +1,7 @@
#include
#include
#include
+#include
int
main()
Cheers
TfH
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's
On Fri, Jan 16, 2009 at 01:33:38PM +0200, Danny Braniss wrote:
> some facts:
> #include
> int
> main()
> {
> printf("%s\n", strerror(2));
> return 0;
> }
>
> 1- it works fine on i386
> 2- it bombs on amd64
> 3- with a local strerror.c (instead of the one in libc)
> works fine
> so, there is something realy wrong going on here!
> (and it gows back to at least 7.0-stable)
The compiler thinks strerror returns an int. Include .
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's
> On Fri, Jan 16, 2009 at 01:33:38PM +0200, Danny Braniss wrote:
> > some facts:
> > #include
> > int
> > main()
> > {
> > printf("%s\n", strerror(2));
> > return 0;
> > }
> >
> > 1- it works fine on i386
> > 2- it bombs on amd64
> > 3- with a local strerror.c (instead of the one in libc)
> >works fine
> > so, there is something realy wrong going on here!
> > (and it gows back to at least 7.0-stable)
>
> The compiler thinks strerror returns an int. Include .
ahh, RTFM ALL THE WAY! I just saw the top few lines:
LIBRARY
Standard C Library (libc, -lc)
SYNOPSIS
#include
but later it shows:
#include
char *
strerror(int errnum);
on the other hand, compiling with -static workes ok, which sent me on
the wrong trail.
danny
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's
Danny Braniss schrieb:
some facts:
#include
int
main()
{
printf("%s\n", strerror(2));
return 0;
}
1- it works fine on i386
2- it bombs on amd64
3- with a local strerror.c (instead of the one in libc)
works fine
so, there is something realy wrong going on here!
(and it gows back to at least 7.0-stable)
No, everything is perfectly correct. I suggested this earlier: Compile
with -Wall and you'll see what the problem is.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's
> Garrett Cooper schrieb:
> > Ok, I just installworld'ed, recompiled the program with the
> > following modifications, and I still get segfaults. And the question
> > of the night is: why amd64 on a VERY recent CURRENT?
> > I'm going to try the same app on an amd64 freebsd VMware instance
> > with RELENG_7.
> > Remember: just because a bunch of other people aren't reporting
> > issues with CURRENT/amd64 doesn't mean that it isn't environmental,
> > related to my hardware or compile options ;).
> > Cheers,
> > -Garrett
> >
> > #include
> > #include
> > #include
> >
> > int
> > main()
> > {
> >
> > struct stat sb;
> >
> > int o_errno;
> >
> > if (stat("/some/file/that/doesn't/exist", &sb) != 0) {
> > o_errno = errno;
> > printf("Errno: %d\n", errno);
> > printf("%s\n", strerror(o_errno));
> > }
> >
> > return 0;
> >
> > }
> >
> > #include
> > #include
> > #include
> >
> > int
> > main()
> > {
> >
> > struct stat sb;
> >
> > int o_errno;
> >
> > if (stat("/some/file/that/doesn't/exist", &sb) != 0) {
> > o_errno = errno;
> > printf("Errno: %d\n", errno);
> > printf("%s\n", strerror(o_errno));
> > }
> >
> > return 0;
> >
> > }
> >
> > [gcoo...@optimus ~]$ gcc -o badfile badfile.c
> > [gcoo...@optimus ~]$ ./badfile
> > Errno: 2
> > Segmentation fault: 11 (core dumped)
> > [gcoo...@optimus ~]$
>
> Well, compile with -g, start in gdb, check what value is wrong, the
> usual stuff. Probably the return value of strerror() is interesting.
some facts:
#include
int
main()
{
printf("%s\n", strerror(2));
return 0;
}
1- it works fine on i386
2- it bombs on amd64
3- with a local strerror.c (instead of the one in libc)
works fine
so, there is something realy wrong going on here!
(and it gows back to at least 7.0-stable)
danny
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's
Garrett Cooper schrieb:
On Fri, Jan 16, 2009 at 2:21 AM, Christoph Mallon
wrote:
Christian Kandeler schrieb:
On Friday 16 January 2009 09:53, Christoph Mallon wrote:
int
main() {
int mib[4];
size_t len;
if (sysctlnametomib("kern.ipc.shmmax", mib, &len) != 0) {
printf("Errno: %d\n", errno);
errx(errno, "Error: %s", strerror(errno));
The use of errno is wrong. printf might change errno.
I don't think printf() can set errno. And even if it could, it
Of course it can. See ISO/IEC 9899:1999 (E) §7.5:3.
wouldn't matter, because C has call-by-value semantics.
This has nothing to do with call-by-value. errno is read (even twice!)
*after* the call to printf().
Ok, I just installworld'ed, recompiled the program with the
following modifications, and I still get segfaults. And the question
of the night is: why amd64 on a VERY recent CURRENT?
I'm going to try the same app on an amd64 freebsd VMware instance
with RELENG_7.
Remember: just because a bunch of other people aren't reporting
issues with CURRENT/amd64 doesn't mean that it isn't environmental,
related to my hardware or compile options ;).
Cheers,
-Garrett
#include
#include
#include
int
main()
{
struct stat sb;
int o_errno;
if (stat("/some/file/that/doesn't/exist", &sb) != 0) {
o_errno = errno;
printf("Errno: %d\n", errno);
printf("%s\n", strerror(o_errno));
}
return 0;
}
#include
#include
#include
int
main()
{
struct stat sb;
int o_errno;
if (stat("/some/file/that/doesn't/exist", &sb) != 0) {
o_errno = errno;
printf("Errno: %d\n", errno);
printf("%s\n", strerror(o_errno));
}
return 0;
}
[gcoo...@optimus ~]$ gcc -o badfile badfile.c
[gcoo...@optimus ~]$ ./badfile
Errno: 2
Segmentation fault: 11 (core dumped)
[gcoo...@optimus ~]$
Compile with -Wall (you ALWAYS should do that) and then you'll see what
the problem is.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's
Garrett Cooper schrieb:
Ok, I just installworld'ed, recompiled the program with the
following modifications, and I still get segfaults. And the question
of the night is: why amd64 on a VERY recent CURRENT?
I'm going to try the same app on an amd64 freebsd VMware instance
with RELENG_7.
Remember: just because a bunch of other people aren't reporting
issues with CURRENT/amd64 doesn't mean that it isn't environmental,
related to my hardware or compile options ;).
Cheers,
-Garrett
#include
#include
#include
int
main()
{
struct stat sb;
int o_errno;
if (stat("/some/file/that/doesn't/exist", &sb) != 0) {
o_errno = errno;
printf("Errno: %d\n", errno);
printf("%s\n", strerror(o_errno));
}
return 0;
}
#include
#include
#include
int
main()
{
struct stat sb;
int o_errno;
if (stat("/some/file/that/doesn't/exist", &sb) != 0) {
o_errno = errno;
printf("Errno: %d\n", errno);
printf("%s\n", strerror(o_errno));
}
return 0;
}
[gcoo...@optimus ~]$ gcc -o badfile badfile.c
[gcoo...@optimus ~]$ ./badfile
Errno: 2
Segmentation fault: 11 (core dumped)
[gcoo...@optimus ~]$
Well, compile with -g, start in gdb, check what value is wrong, the
usual stuff. Probably the return value of strerror() is interesting.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's
On Fri, Jan 16, 2009 at 2:35 AM, Garrett Cooper wrote:
> On Fri, Jan 16, 2009 at 2:21 AM, Christoph Mallon
> wrote:
>> Christian Kandeler schrieb:
>>>
>>> On Friday 16 January 2009 09:53, Christoph Mallon wrote:
>>>
> int
> main() {
>
>int mib[4];
>
>size_t len;
>
>if (sysctlnametomib("kern.ipc.shmmax", mib, &len) != 0) {
>printf("Errno: %d\n", errno);
>errx(errno, "Error: %s", strerror(errno));
The use of errno is wrong. printf might change errno.
>>>
>>> I don't think printf() can set errno. And even if it could, it
>>
>> Of course it can. See ISO/IEC 9899:1999 (E) §7.5:3.
>>
>>> wouldn't matter, because C has call-by-value semantics.
>>
>> This has nothing to do with call-by-value. errno is read (even twice!)
>> *after* the call to printf().
>
>Ok, I just installworld'ed, recompiled the program with the
> following modifications, and I still get segfaults. And the question
> of the night is: why amd64 on a VERY recent CURRENT?
>I'm going to try the same app on an amd64 freebsd VMware instance
> with RELENG_7.
>Remember: just because a bunch of other people aren't reporting
> issues with CURRENT/amd64 doesn't mean that it isn't environmental,
> related to my hardware or compile options ;).
> Cheers,
> -Garrett
Ugh... I pasted it twice by accident. Sorry.
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's
On Fri, Jan 16, 2009 at 2:21 AM, Christoph Mallon
wrote:
> Christian Kandeler schrieb:
>>
>> On Friday 16 January 2009 09:53, Christoph Mallon wrote:
>>
int
main() {
int mib[4];
size_t len;
if (sysctlnametomib("kern.ipc.shmmax", mib, &len) != 0) {
printf("Errno: %d\n", errno);
errx(errno, "Error: %s", strerror(errno));
>>>
>>> The use of errno is wrong. printf might change errno.
>>
>> I don't think printf() can set errno. And even if it could, it
>
> Of course it can. See ISO/IEC 9899:1999 (E) §7.5:3.
>
>> wouldn't matter, because C has call-by-value semantics.
>
> This has nothing to do with call-by-value. errno is read (even twice!)
> *after* the call to printf().
Ok, I just installworld'ed, recompiled the program with the
following modifications, and I still get segfaults. And the question
of the night is: why amd64 on a VERY recent CURRENT?
I'm going to try the same app on an amd64 freebsd VMware instance
with RELENG_7.
Remember: just because a bunch of other people aren't reporting
issues with CURRENT/amd64 doesn't mean that it isn't environmental,
related to my hardware or compile options ;).
Cheers,
-Garrett
#include
#include
#include
int
main()
{
struct stat sb;
int o_errno;
if (stat("/some/file/that/doesn't/exist", &sb) != 0) {
o_errno = errno;
printf("Errno: %d\n", errno);
printf("%s\n", strerror(o_errno));
}
return 0;
}
#include
#include
#include
int
main()
{
struct stat sb;
int o_errno;
if (stat("/some/file/that/doesn't/exist", &sb) != 0) {
o_errno = errno;
printf("Errno: %d\n", errno);
printf("%s\n", strerror(o_errno));
}
return 0;
}
[gcoo...@optimus ~]$ gcc -o badfile badfile.c
[gcoo...@optimus ~]$ ./badfile
Errno: 2
Segmentation fault: 11 (core dumped)
[gcoo...@optimus ~]$
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's
Christian Kandeler schrieb:
On Friday 16 January 2009 09:53, Christoph Mallon wrote:
int
main() {
int mib[4];
size_t len;
if (sysctlnametomib("kern.ipc.shmmax", mib, &len) != 0) {
printf("Errno: %d\n", errno);
errx(errno, "Error: %s", strerror(errno));
The use of errno is wrong. printf might change errno.
I don't think printf() can set errno. And even if it could, it
Of course it can. See ISO/IEC 9899:1999 (E) §7.5:3.
wouldn't matter, because C has call-by-value semantics.
This has nothing to do with call-by-value. errno is read (even twice!)
*after* the call to printf().
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's
On Friday 16 January 2009 09:53, Christoph Mallon wrote:
> > int
> > main() {
> >
> > int mib[4];
> >
> > size_t len;
> >
> > if (sysctlnametomib("kern.ipc.shmmax", mib, &len) != 0) {
> > printf("Errno: %d\n", errno);
> > errx(errno, "Error: %s", strerror(errno));
>
> The use of errno is wrong. printf might change errno.
I don't think printf() can set errno. And even if it could, it
wouldn't matter, because C has call-by-value semantics.
Christian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's
Garrett Cooper schrieb:
On Fri, Jan 16, 2009 at 12:58 AM, Garrett Cooper wrote:
On Fri, Jan 16, 2009 at 12:57 AM, Christoph Mallon
wrote:
Garrett Cooper schrieb:
Good point. I modified the source to do that.
Thanks,
-Garrett
You should reply to all so the discussion stays on the list.
Yeah, that was a goofup on my part. Go-go Gmail web interface!
-Garrett
Hmmm... looks like the strerror issue it could be a serious bug:
#include
#include
#include
int
main()
{
struct stat sb;
int o_errno;
if (stat("/some/file/that/doesn't/exist", &sb) != 0) {
o_errno = errno;
printf("Errno: %d\n", errno);
err(errno, "%s", strerror(o_errno));
You are still using the wrong errno.
Also err() itself prints the error string using strerror(). There might
be some interference when the result of one call to strerror() (your
call) is used after another call to strerror() (err() internally).
I doubt there is a bug in the library, otherwise we would see many
bugreports of segfaults on AMD64.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's
On Fri, Jan 16, 2009 at 12:58 AM, Garrett Cooper wrote:
> On Fri, Jan 16, 2009 at 12:57 AM, Christoph Mallon
> wrote:
>> Garrett Cooper schrieb:
>>>
>>> Good point. I modified the source to do that.
>>> Thanks,
>>> -Garrett
>>
>> You should reply to all so the discussion stays on the list.
>
> Yeah, that was a goofup on my part. Go-go Gmail web interface!
> -Garrett
Hmmm... looks like the strerror issue it could be a serious bug:
#include
#include
#include
int
main()
{
struct stat sb;
int o_errno;
if (stat("/some/file/that/doesn't/exist", &sb) != 0) {
o_errno = errno;
printf("Errno: %d\n", errno);
err(errno, "%s", strerror(o_errno));
}
return 0;
}
[gcoo...@optimus ~]$ ./badfile
Errno: 2
badfile: Segmentation fault: 11 (core dumped)
I rebuilt my kernel and installed it, and I rebuilt world, but
haven't installed it yet though, so let me reboot the amd64 machine
and see what happens (may be a mismatched ABI issue)...
Cheers,
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's
On Fri, Jan 16, 2009 at 10:44 AM, Garrett Cooper wrote:
> On Fri, Jan 16, 2009 at 12:41 AM, Garrett Cooper wrote:
>> Hi amd64 and Hackers,
>>Uh, I'm really confused why 1) this error (errno => ENOMEM) would
>> occur when I have more than enough free memory (both on x86 and amd64)
>> and 2) why strerror would segfault in the call to errx in the attached
>> sourcefile on amd64 only. Not initializing len causes the second
>> output sample (errno => 14, which is EFAULT).
>>Any ideas?
>>Please CC me if mailing on amd64@ as I'm not subscribed to the list.
>> Thanks,
>> -Garrett
>>
>> /* Program */
>> #include
>> #include
>> #include
>> #include
>> #include
>>
>> int
>> main() {
>>
>>int mib[4];
>>
>>size_t len;
>>
>>if (sysctlnametomib("kern.ipc.shmmax", mib, &len) != 0) {
>>printf("Errno: %d\n", errno);
>>errx(errno, "Error: %s", strerror(errno));
>>}
>>
>>printf("%lu\n", len);
>>
>>return 0;
>>
>> }
>>
>> # output for len preset to 0:
>> [gcoo...@optimus ~]$ ./test2
>> Errno: 12
>> test2: Segmentation fault: 11 (core dumped)
>> [gcoo...@optimus ~]$ uname -a
>> FreeBSD optimus.gateway.2wire.net 8.0-CURRENT FreeBSD 8.0-CURRENT #4:
>> Sun Jan 11 12:30:31 PST 2009
>> r...@optimus.gateway.2wire.net:/usr/obj/usr/src/sys/OPTIMUS amd64
>>
>> [gcoo...@orangebox /usr/home/gcooper]$ ./test
>> Errno: 12
>> test: Error: Cannot allocate memory
>> [gcoo...@orangebox /usr/home/gcooper]$ uname -a
>> FreeBSD orangebox.gateway.2wire.net 8.0-CURRENT FreeBSD 8.0-CURRENT
>> #4: Sat Jan 3 22:54:52 PST 2009
>> gcoo...@orangebox.gateway.2wire.net:/usr/obj/usr/src/sys/ORANGEBOX
>> i386
>>
>> # output for len not preset to 0:
>> [gcoo...@optimus ~]$ ./test2
>> Errno: 14
>> test2: Segmentation fault: 11 (core dumped)
>
> Almost forgot -- here are the actual values reported by sysctl(1),
> just for reference:
>
> [gcoo...@optimus ~]$ sysctl kern.ipc.shmall kern.ipc.shmmin kern.ipc.shmmax
> kern.ipc.shmall: 8192
> kern.ipc.shmmin: 1
> kern.ipc.shmmax: 33554432
>
> [gcoo...@orangebox /usr/src/sys]$ sysctl kern.ipc.shmall
> kern.ipc.shmmin kern.ipc.shmmax
> kern.ipc.shmall: 8192
> kern.ipc.shmmin: 1
> kern.ipc.shmmax: 33554432
>
> Thanks,
> -Garrett
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
>
You need to initialize len to the number of entries in the mib array.
Try adding 'len = 4' before calling sysctlnametomib() and see if your
issues go away.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's
On Fri, Jan 16, 2009 at 12:57 AM, Christoph Mallon wrote: > Garrett Cooper schrieb: >> >> Good point. I modified the source to do that. >> Thanks, >> -Garrett > > You should reply to all so the discussion stays on the list. Yeah, that was a goofup on my part. Go-go Gmail web interface! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's
On Fri, Jan 16, 2009 at 10:47 AM, Jacques Fourie
wrote:
> On Fri, Jan 16, 2009 at 10:44 AM, Garrett Cooper wrote:
>> On Fri, Jan 16, 2009 at 12:41 AM, Garrett Cooper wrote:
>>> Hi amd64 and Hackers,
>>>Uh, I'm really confused why 1) this error (errno => ENOMEM) would
>>> occur when I have more than enough free memory (both on x86 and amd64)
>>> and 2) why strerror would segfault in the call to errx in the attached
>>> sourcefile on amd64 only. Not initializing len causes the second
>>> output sample (errno => 14, which is EFAULT).
>>>Any ideas?
>>>Please CC me if mailing on amd64@ as I'm not subscribed to the list.
>>> Thanks,
>>> -Garrett
>>>
>>> /* Program */
>>> #include
>>> #include
>>> #include
>>> #include
>>> #include
>>>
>>> int
>>> main() {
>>>
>>>int mib[4];
>>>
>>>size_t len;
>>>
>>>if (sysctlnametomib("kern.ipc.shmmax", mib, &len) != 0) {
>>>printf("Errno: %d\n", errno);
>>>errx(errno, "Error: %s", strerror(errno));
>>>}
>>>
>>>printf("%lu\n", len);
>>>
>>>return 0;
>>>
>>> }
>>>
>>> # output for len preset to 0:
>>> [gcoo...@optimus ~]$ ./test2
>>> Errno: 12
>>> test2: Segmentation fault: 11 (core dumped)
>>> [gcoo...@optimus ~]$ uname -a
>>> FreeBSD optimus.gateway.2wire.net 8.0-CURRENT FreeBSD 8.0-CURRENT #4:
>>> Sun Jan 11 12:30:31 PST 2009
>>> r...@optimus.gateway.2wire.net:/usr/obj/usr/src/sys/OPTIMUS amd64
>>>
>>> [gcoo...@orangebox /usr/home/gcooper]$ ./test
>>> Errno: 12
>>> test: Error: Cannot allocate memory
>>> [gcoo...@orangebox /usr/home/gcooper]$ uname -a
>>> FreeBSD orangebox.gateway.2wire.net 8.0-CURRENT FreeBSD 8.0-CURRENT
>>> #4: Sat Jan 3 22:54:52 PST 2009
>>> gcoo...@orangebox.gateway.2wire.net:/usr/obj/usr/src/sys/ORANGEBOX
>>> i386
>>>
>>> # output for len not preset to 0:
>>> [gcoo...@optimus ~]$ ./test2
>>> Errno: 14
>>> test2: Segmentation fault: 11 (core dumped)
>>
>> Almost forgot -- here are the actual values reported by sysctl(1),
>> just for reference:
>>
>> [gcoo...@optimus ~]$ sysctl kern.ipc.shmall kern.ipc.shmmin kern.ipc.shmmax
>> kern.ipc.shmall: 8192
>> kern.ipc.shmmin: 1
>> kern.ipc.shmmax: 33554432
>>
>> [gcoo...@orangebox /usr/src/sys]$ sysctl kern.ipc.shmall
>> kern.ipc.shmmin kern.ipc.shmmax
>> kern.ipc.shmall: 8192
>> kern.ipc.shmmin: 1
>> kern.ipc.shmmax: 33554432
>>
>> Thanks,
>> -Garrett
>> ___
>> freebsd-hackers@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
>>
>
> You need to initialize len to the number of entries in the mib array.
> Try adding 'len = 4' before calling sysctlnametomib() and see if your
> issues go away.
>
Sorry, I only scanned through the code without reading the whole
message before replying :) Please ignore...
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's
On Fri, 16 Jan 2009, 00:44-0800, Garrett Cooper wrote: > On Fri, Jan 16, 2009 at 12:41 AM, Garrett Cooper wrote: > > Hi amd64 and Hackers, > >Uh, I'm really confused why 1) this error (errno => ENOMEM) would > > occur when I have more than enough free memory (both on x86 and amd64) > > and 2) why strerror would segfault in the call to errx in the attached > > sourcefile on amd64 only. Not initializing len causes the second > > output sample (errno => 14, which is EFAULT). > >Any ideas? - size_t len; + size_t len = 4; -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's
On Fri, Jan 16, 2009 at 12:47 AM, Jacques Fourie wrote: > > You need to initialize len to the number of entries in the mib array. > Try adding 'len = 4' before calling sysctlnametomib() and see if your > issues go away. Ok, that solution works (I think). So, problem 2 down. Now: what about the segfaulting strerror(3) call on amd64 ;\? -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's
Garrett Cooper schrieb:
Hi amd64 and Hackers,
Uh, I'm really confused why 1) this error (errno => ENOMEM) would
occur when I have more than enough free memory (both on x86 and amd64)
and 2) why strerror would segfault in the call to errx in the attached
sourcefile on amd64 only. Not initializing len causes the second
output sample (errno => 14, which is EFAULT).
Any ideas?
Please CC me if mailing on amd64@ as I'm not subscribed to the list.
Thanks,
-Garrett
len is not uninitialised. This leads to undefined behaviour. Anything
can happen. Probably the syscall overwrites parts of the stack because
len has some (random) high value.
/* Program */
#include
#include
#include
#include
#include
int
main() {
int mib[4];
size_t len;
if (sysctlnametomib("kern.ipc.shmmax", mib, &len) != 0) {
printf("Errno: %d\n", errno);
errx(errno, "Error: %s", strerror(errno));
The use of errno is wrong. printf might change errno. Store the errno
into a local variable before you do any call, which might modify it.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's
On Fri, Jan 16, 2009 at 12:41 AM, Garrett Cooper wrote:
> Hi amd64 and Hackers,
>Uh, I'm really confused why 1) this error (errno => ENOMEM) would
> occur when I have more than enough free memory (both on x86 and amd64)
> and 2) why strerror would segfault in the call to errx in the attached
> sourcefile on amd64 only. Not initializing len causes the second
> output sample (errno => 14, which is EFAULT).
>Any ideas?
>Please CC me if mailing on amd64@ as I'm not subscribed to the list.
> Thanks,
> -Garrett
>
> /* Program */
> #include
> #include
> #include
> #include
> #include
>
> int
> main() {
>
>int mib[4];
>
>size_t len;
>
>if (sysctlnametomib("kern.ipc.shmmax", mib, &len) != 0) {
>printf("Errno: %d\n", errno);
>errx(errno, "Error: %s", strerror(errno));
>}
>
>printf("%lu\n", len);
>
>return 0;
>
> }
>
> # output for len preset to 0:
> [gcoo...@optimus ~]$ ./test2
> Errno: 12
> test2: Segmentation fault: 11 (core dumped)
> [gcoo...@optimus ~]$ uname -a
> FreeBSD optimus.gateway.2wire.net 8.0-CURRENT FreeBSD 8.0-CURRENT #4:
> Sun Jan 11 12:30:31 PST 2009
> r...@optimus.gateway.2wire.net:/usr/obj/usr/src/sys/OPTIMUS amd64
>
> [gcoo...@orangebox /usr/home/gcooper]$ ./test
> Errno: 12
> test: Error: Cannot allocate memory
> [gcoo...@orangebox /usr/home/gcooper]$ uname -a
> FreeBSD orangebox.gateway.2wire.net 8.0-CURRENT FreeBSD 8.0-CURRENT
> #4: Sat Jan 3 22:54:52 PST 2009
> gcoo...@orangebox.gateway.2wire.net:/usr/obj/usr/src/sys/ORANGEBOX
> i386
>
> # output for len not preset to 0:
> [gcoo...@optimus ~]$ ./test2
> Errno: 14
> test2: Segmentation fault: 11 (core dumped)
Almost forgot -- here are the actual values reported by sysctl(1),
just for reference:
[gcoo...@optimus ~]$ sysctl kern.ipc.shmall kern.ipc.shmmin kern.ipc.shmmax
kern.ipc.shmall: 8192
kern.ipc.shmmin: 1
kern.ipc.shmmax: 33554432
[gcoo...@orangebox /usr/src/sys]$ sysctl kern.ipc.shmall
kern.ipc.shmmin kern.ipc.shmmax
kern.ipc.shmall: 8192
kern.ipc.shmmin: 1
kern.ipc.shmmax: 33554432
Thanks,
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's
Hi amd64 and Hackers,
Uh, I'm really confused why 1) this error (errno => ENOMEM) would
occur when I have more than enough free memory (both on x86 and amd64)
and 2) why strerror would segfault in the call to errx in the attached
sourcefile on amd64 only. Not initializing len causes the second
output sample (errno => 14, which is EFAULT).
Any ideas?
Please CC me if mailing on amd64@ as I'm not subscribed to the list.
Thanks,
-Garrett
/* Program */
#include
#include
#include
#include
#include
int
main() {
int mib[4];
size_t len;
if (sysctlnametomib("kern.ipc.shmmax", mib, &len) != 0) {
printf("Errno: %d\n", errno);
errx(errno, "Error: %s", strerror(errno));
}
printf("%lu\n", len);
return 0;
}
# output for len preset to 0:
[gcoo...@optimus ~]$ ./test2
Errno: 12
test2: Segmentation fault: 11 (core dumped)
[gcoo...@optimus ~]$ uname -a
FreeBSD optimus.gateway.2wire.net 8.0-CURRENT FreeBSD 8.0-CURRENT #4:
Sun Jan 11 12:30:31 PST 2009
r...@optimus.gateway.2wire.net:/usr/obj/usr/src/sys/OPTIMUS amd64
[gcoo...@orangebox /usr/home/gcooper]$ ./test
Errno: 12
test: Error: Cannot allocate memory
[gcoo...@orangebox /usr/home/gcooper]$ uname -a
FreeBSD orangebox.gateway.2wire.net 8.0-CURRENT FreeBSD 8.0-CURRENT
#4: Sat Jan 3 22:54:52 PST 2009
gcoo...@orangebox.gateway.2wire.net:/usr/obj/usr/src/sys/ORANGEBOX
i386
# output for len not preset to 0:
[gcoo...@optimus ~]$ ./test2
Errno: 14
test2: Segmentation fault: 11 (core dumped)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
