This is the mail archive of the
glibc-linux@ricardo.ecn.wfu.edu
mailing list for the glibc project.
sysconf(_SC_NPROCESSORS_CONF) core dump?
- To: <glibc-linux@ricardo.ecn.wfu.edu>
- Subject: sysconf(_SC_NPROCESSORS_CONF) core dump?
- From: "Phil Estes" <estesp@austin.ibm.com>
- Date: Tue, 13 Jul 1999 11:13:15 -0500
- Reply-To: glibc-linux@ricardo.ecn.wfu.edu
Has anyone else encountered the subject mentioned problem under glibc 2.1.1
(RH 6.0)? Under gdb the stack trace is quite confusing since sysconf calls
get_nprocs which then does something with the floppy drive (?!?) /dev/fd0,
which finally fails in a memcpy after some IO_ calls. This also seems to
occur with _SC_NPROCESSORS_ONLN. I was simply looking for a nice programmatic
way to determine number of processors and also whether it was uni- or multi-
processor mode. I guess the other solution is to read /proc/cpuinfo--the
reason I wasn't too excited about that was that I'm not sure if the format is
different on different kernel levels and whether someone will have a patch
which changes the format or uses a different process to show multiple cpus
(xosview recommends a patch that does something like this?).
Anyway, if I'm not using the glibc 2.1.1 sysconf() call correctly, can someone
give me a pointer. And if it is a glibc bug, should I open a problem on this?
Thanks,
Phil Estes
IBM Austin, Linux JVM development
estesp@austin.ibm.com