[Kroupware] Seg Fault during installation
Bill
bhalpin at collaborativefusion.com
Mon Apr 14 16:08:35 CEST 2003
Stephan
Yes its possible. I checked top and I was running kinda high, so i
rebooted. Once I came back up, I started turning off services I could
do without.
I still couldnt install without a segfault. top reported 233460K of ram
available and 1534136 of swap before attempting to install.
This box has 384M ram and 1489M swap partition. What are the min memory
requirements for this system? I couldnt find a number in any of the
docs online.
thanks
-b
On Mon, 2003-04-14 at 11:51, Stephan Buys wrote:
> Hi Bill,
>
> Ok. Had a closer look at your strace. The segfault occurs after:
>
> socket(PF_UNIX, SOCK_STREAM, 0) = 12
>
> Now according to /usr/include/asm/errno.h that return value means
> that the is no memory.
>
> #define·ENOMEM· · 12· /* Out of memory */
>
> Is this possible? Are you running on a small swap file or possibly running
> out of memory? Maybe you dont have a swap partition and your disk is
> running our of space?
>
> Regards,
> Stephan
>
>
> On Monday 14 April 2003 16:49, Bill wrote:
> > Stephan
> >
> > I had nss_ldap installed so I uninstalled it and began the process from
> > "rpm -bb make.spec" but it still seg faulted.
> >
> > I do not have any ldap services running...
> >
> > -b
> >
> > On Mon, 2003-04-14 at 10:24, Stephan Buys wrote:
> > > This is a long shot but you aren't perhaps running NSS or PAM LDAP?
> > >
> > > I see the something is accessing the password file directly and not
> > > using "getent". We had an issue where Postfix kept on crashing because
> > > of nss.
> > >
> > > On Monday 14 April 2003 16:06, you wrote:
> > > > On Sun, 2003-04-13 at 04:11, Stephan Buys wrote:
> > > > > What about using strace with the command? This should show you
> > > > > where the segfault occurs.
> > > > >
> > > > > > strace rpm -bb make.spec
> > > > >
> > > > > You might want to redirect the output to a file and step through it.
> > > > > (There will be a lot of information)
> > > >
> > > > This is the trace just before the fault. It doesnt say much to me,
> > > > maybe it will spark something for someone else:
> > > >
> > > > open("/lib/libc.so.6", O_RDONLY) = 12
> > > > read(12, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0hr\1\000"...,
> > > > 1024) = 1024
> > > > fstat64(12, {st_mode=S_IFREG|0755, st_size=1344152, ...}) = 0
> > > > old_mmap(NULL, 1207648, PROT_READ|PROT_EXEC, MAP_PRIVATE, 12, 0) =
> > > > 0x402a7000
> > > > mprotect(0x403c5000, 36192, PROT_NONE) = 0
> > > > old_mmap(0x403c5000, 20480, PROT_READ|PROT_WRITE,
> > > > MAP_PRIVATE|MAP_FIXED, 12, 0x11e000) = 0x403c5000
> > > > old_mmap(0x403ca000, 15712, PROT_READ|PROT_WRITE,
> > > > MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x403ca000
> > > > close(12) = 0
> > > > open("/lib/ld-linux.so.2", O_RDONLY) = 12
> > > > read(12, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\v\0\000"...,
> > > > 1024) = 1024
> > > > fstat64(12, {st_mode=S_IFREG|0755, st_size=85420, ...}) = 0
> > > > old_mmap(NULL, 75472, PROT_READ|PROT_EXEC, MAP_PRIVATE, 12, 0) =
> > > > 0x403ce000
> > > > mprotect(0x403e0000, 1744, PROT_NONE) = 0
> > > > old_mmap(0x403e0000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED,
> > > > 12, 0x12000) = 0x403e0000
> > > > close(12) = 0
> > > > brk(0) = 0x8218000
> > > > brk(0x8218030) = 0x8218030
> > > > brk(0) = 0x8218030
> > > > brk(0x8219000) = 0x8219000
> > > > open("/etc/passwd", O_RDONLY) = 12
> > > > fcntl64(12, F_GETFD) = 0
> > > > fcntl64(12, F_SETFD, FD_CLOEXEC) = 0
> > > > fstat64(12, {st_mode=S_IFREG|0644, st_size=1567, ...}) = 0
> > > > old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
> > > > -1, 0) = 0x403e1000
> > > > read(12, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 1567
> > > > close(12) = 0
> > > > munmap(0x403e1000, 4096) = 0
> > > > chdir("/") = 0
> > > > chroot("/") = 0
> > > > open("/etc/passwd", O_RDONLY) = 12
> > > > fcntl64(12, F_GETFD) = 0
> > > > fcntl64(12, F_SETFD, FD_CLOEXEC) = 0
> > > > fstat64(12, {st_mode=S_IFREG|0644, st_size=1567, ...}) = 0
> > > > old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
> > > > -1, 0) = 0x403e1000
> > > > read(12, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 1567
> > > > close(12) = 0
> > > > munmap(0x403e1000, 4096) = 0
> > > > brk(0) = 0x8219000
> > > > brk(0x821a000) = 0x821a000
> > > > brk(0) = 0x821a000
> > > > brk(0x821b000) = 0x821b000
> > > > socket(PF_UNIX, SOCK_STREAM, 0) = 12
> > > > --- SIGSEGV (Segmentation fault) ---
> > > > +++ killed by SIGSEGV +++
> > > >
> > > > What seemed more important in the trace were repeated errors about an
> > > > inappropriate device:
> > > >
> > > > ioctl(1, SNDCTL_TMR_TIMEBASE, 0xbffff280) = -1 ENOTTY (Inappropriate
> > > > ioctl for device)
> > > >
> > > > This is a sound card call isnt it? How do I fix that and could that
> > > > cause the seg fault?
> > > >
> > > > Also, to address the suggestions of others:
> > > >
> > > > 1) I am definitely using /kolab/bin/rpm and not the local version.
> > > > 2) Generated a core file and ran it thru gdb but all it gave me was
> > > > memory addresses with '??' for labels.
> > > >
> > > > thanks for the help thus far...
> > > >
> > > > -b
> > > >
> > > > -b
> >
> > _______________________________________________
> > Kroupware mailing list
> > Kroupware at mail.kde.org
> > http://mail.kde.org/mailman/listinfo/kroupware
>
More information about the Kroupware
mailing list