On Sep 09, Alan Cox wrote:
> > dpkg under my self-compiled Linux 2.3.17 seg faults on startup if a
> > non-dpkg-deb option is given. The problem is avoided if the call to
> > sysinfo() in main/filesdb.c is bypassed. I can't see what's going
> > wrong (it's probably something in kernel space clobbering user space,
> > but the code seems fine and probably hasn't changed in a while).
>
> sysinfo() was broken by people adding fields. I thought I had it all put
> back right in the last patches I sent Linus. Check the user and kernel
> opinion of struct sysinfo on your machine match
Here's sysinfo according to userspace headers from glibc 2.1.2 on
Debian:
struct sysinfo {
long uptime; /* Seconds since boot */
unsigned long loads[3]; /* 1, 5, and 15 minute load averages */
unsigned long totalram; /* Total usable main memory size */
unsigned long freeram; /* Available memory size */
unsigned long sharedram; /* Amount of shared memory */
unsigned long bufferram; /* Memory used by buffers */
unsigned long totalswap; /* Total swap space size */
unsigned long freeswap; /* swap space still available */
unsigned short procs; /* Number of current processes */
char _f[22]; /* Pads structure to 64 bytes */
};
Here it is according to 2.3.17:
struct sysinfo {
long uptime; /* Seconds since boot */
unsigned long loads[3]; /* 1, 5, and 15 minute load averages */
unsigned long totalram; /* Total usable main memory size */
unsigned long freeram; /* Available memory size */
unsigned long sharedram; /* Amount of shared memory */
unsigned long bufferram; /* Memory used by buffers */
unsigned long totalswap; /* Total swap space size */
unsigned long freeswap; /* swap space still available */
unsigned short procs; /* Number of current processes */
unsigned long totalbig; /* Total big memory size */
unsigned long freebig; /* Available big memory size */
char _f[22-2*sizeof(long)]; /* Padding: libc5 uses this.. */
};
I see two new fields, but the change in the size of the _f[] array
seems to account for this (since sizeof(long) == sizeof(unsigned
long)). Unless some alignment (long after a short) is going on in
here...
Chris
