Results 1 to 9 of 9

Thread: Seg Fault building Majordomo

  1. #1
    Junior Member Newbie
    Join Date
    Apr 2007
    Posts
    23

    Default Seg Fault building Majordomo

    # make install
    Testing for perl (/usr/bin/perl)...
    Configuring scripts...
    ./install.sh -m 751 -O 503 -g 505 . /usr/majordomo-1.94.5
    ./install.sh: line 205: 16091 Segmentation fault {CHOWN} "${OWNER}" "${DEST}"
    make: *** [install-scripts] Error 1


    Anyone seen such an error just doing a make install with the freshest majordomo sources on Fedora Core 4?

  2. #2
    Former Employee Power Poster
    Join Date
    Apr 2005
    Location
    Seattle, WA
    Posts
    140

    Default

    This is a odd error as it would seem that chown is generating a segfault, which shouldn't happen. I would attempt to run the make again, but both before and after, take a look at failcounts within the /proc/user_beancounters file for kmemsize and privvmpages. If the failcounts has increased after a segfault occurs again, then the error is due to resource limits being reached.

    If this is the case, then you may be able to get it to compile by stopping other programs while you run the make command.

  3. #3
    Junior Member Newbie
    Join Date
    Apr 2007
    Posts
    23

    Default

    Before :


    12693: kmemsize 5344716 5656422 14790793 15569256 2119082
    privvmpages 13123 14109 124977 124977 40

    After :

    12693: kmemsize 5340982 5362788 14790793 15569256 2119082
    privvmpages 13124 13325 124977 124977 40

    Have I run out of resources? This wasn't even a retry of make. This is just trying to chown a file.

  4. #4
    Forum Administrator Power Poster Lyle@Spry's Avatar
    Join Date
    May 2005
    Posts
    455

    Default

    Yes.

    If the last column (labeled 'failcnt', short for 'failure count') reads anything other than 0 then you have maxed out that resource that many times since the last reboot.

  5. #5
    Junior Member Newbie
    Join Date
    Apr 2007
    Posts
    23

    Default

    Hrmm, oddly enough using Webmin I can chown files w/out problem. There must be something else wrong. strace chown provides this output :

    [root@vz64-012 dev]# strace chown
    execve("/bin/chown", ["chown"], [/* 21 vars */]) = 0
    brk(0) = 0x8052000
    uname({sys="Linux", node="vz64-012.spry.com", ...}) = 0
    access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
    open("/etc/ld.so.cache", O_RDONLY) = 3
    fstat64(3, {st_mode=S_IFREG|0644, st_size=36150, ...}) = 0
    old_mmap(NULL, 36150, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fdd000
    close(3) = 0
    open("/lib/libc.so.6", O_RDONLY) = 3
    read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\2 12N\1"..., 512) = 512
    fstat64(3, {st_mode=S_IFREG|0755, st_size=1482536, ...}) = 0
    old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fdc000
    old_mmap(NULL, 1215452, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7eb3000
    old_mmap(0xb7fd6000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x123000) = 0xb7fd6000
    old_mmap(0xb7fda000, 7132, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7fda000
    close(3) = 0
    old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7eb2000
    set_thread_area({entry_number:-1 -> 6, base_addr:0xb7eb26c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
    mprotect(0xb7fd6000, 8192, PROT_READ) = 0
    mprotect(0xb8000000, 4096, PROT_READ) = 0
    munmap(0xb7fdd000, 36150) = 0
    --- SIGSEGV (Segmentation fault) @ 0 (0) ---
    +++ killed by SIGSEGV +++

  6. #6
    Forum Administrator Power Poster Lyle@Spry's Avatar
    Join Date
    May 2005
    Posts
    455

    Default

    Running out of resources does not mean your server stops functioning completely. When a process completes, it gives back (frees) the memory it was using. The fact that you were able to do it via Webmin vs. command line only means that at the time you used Webmin to do it, you had enough resources. When you run out of memory, only the process(es) that tried to allocate the last bit and didn't get enough would fail.

    Long story short, you are running dangerously close to the edge if there are ANY failures listed in /proc/user_beancounters. You WILL have intermittent failures, that is a fact. They won't be consistent, and the only pattern would be that under high load/usage, the failures will increase in frequency.

  7. #7
    Junior Member Newbie
    Join Date
    Apr 2007
    Posts
    23

    Default

    Lyle,

    I completely understand the intermittent failures if I believed it was truly running out of memory.

    What I've experienced is different than intermittent failures. It *never* fails no matter what load is on the system using webmin and *always* fails using chown regardless of load. 100% and 100% of the time.

    What bugs me about it also is that I've never had any other seg faults on the system. Only the one associated with chown.

  8. #8
    Junior Member Newbie
    Join Date
    Apr 2007
    Posts
    23

    Default

    I tried again this evening just to 'chown myuser randomfile'. Here is the outpu cut and paste from an ssh session. Note the 0 failcount for kmemsize and privvmpages. There must be some other reason why it segfaults.

    sh-3.00# cat /proc/user_beancounters
    Version: 2.5
    uid resource held maxheld barrier limit failcnt
    12693: kmemsize 4253412 4273720 1 4790793 15569256 0
    lockedpages 0 0 512 512 0
    privvmpages 11763 11930 124977 124977 0

    sh-3.00# chown myuser myfile
    Segmentation fault

    sh-3.00# cat /proc/user_beancounters
    Version: 2.5
    uid resource held maxheld barrier limit failcnt
    12693: kmemsize 4237536 4261079 1 4790793 15569256 0
    lockedpages 0 0 512 512 0
    privvmpages 11765 11932 124977 124977 0

    sh-3.00# vmstat
    procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
    r b swpd free buff cache si so bi bo in cs us sy id wa
    0 0 42132 352384 473240 5398056 0 0 0 0 0 110 0 0 100 0

    sh-3.00#

  9. #9
    Forum Administrator Power Poster Lyle@Spry's Avatar
    Join Date
    May 2005
    Posts
    455

    Default

    Well then, sounds like the chown binary is corrupt. Please create a support request for our technicians so they may identify your account and investigate further.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •