No announcement yet.

ip.pex and ip6tables-control.pex segfault

  • Filter
  • Time
  • Show
Clear All
new posts

  • ip.pex and ip6tables-control.pex segfault

    I've installed ruxit on a server that had InterWorx running. I had to restart all webservers to have ruxit monitor it, and that's the last I've heard from InterWorx' webserver.
    [root@dev ~]# /usr/local/interworx/etc/init.d/iworx restart
    Stopping InterWorx-web: [ OK ]
    Stopping InterWorx-db: [ OK ]
    Starting InterWorx-db: [ OK ]
    Starting InterWorx-web: [ OK ]
    /usr/local/interworx/etc/init.d/iworx: line 255: 5759 Segmentation fault $IWORXHOME/bin/ip.pex --bind-aliases 2> /dev/null
    Binding IP Aliases: [FAILED]
    /usr/local/interworx/etc/init.d/iworx: line 97: 5764 Segmentation fault $IWORXHOME/bin/ip6tables-control.pex --iptables-to-ip6tables
    Has anyone else had this happen before? I'm gonna get to the bottom of this in the meantime.

    Edit1: Found which line makes it segfault. From /usr/local/interworx/bin/ (to which ip.pex is a symlink to), line 13
    exec /home/interworx/bin/php -c /home/interworx/etc `basename $0 .pex`.php "$@"
    Edit2: I think I got it. I needed to copy /home/interworx/bin/php to /root and chmod 777 it, cause otherwise it refused to run inside of Valgrind. I remember that ruxit was messing about with SELinux, and this is what I got from Valgrind:
    [root@dev ~]# valgrind ./php
    ==6487== Memcheck, a memory error detector
    ==6487== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
    ==6487== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
    ==6487== Command: ./php
    vex amd64->IR: unhandled instruction bytes: 0x7 0x11 0x0 0x0 0x0 0x0 0x0 0x0
    vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
    vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
    vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0
    ==6487== Invalid read of size 1
    ==6487== at 0x5315002: ??? (in /usr/lib64/
    ==6487== by 0x4E33FB3: fclose (in /lib64/
    ==6487== by 0xB82DE6E: ??? (in /lib64/
    ==6487== by 0xB836CB5: ??? (in /lib64/
    ==6487== by 0xB825FA2: ??? (in /lib64/
    ==6487== Address 0x0 is not stack'd, malloc'd or (recently) free'd
    ==6487== Process terminating with default action of signal 11 (SIGSEGV)
    ==6487== Access not within mapped region at address 0x0
    ==6487== at 0x5315002: ??? (in /usr/lib64/
    ==6487== by 0x4E33FB3: fclose (in /lib64/
    ==6487== by 0xB82DE6E: ??? (in /lib64/
    ==6487== by 0xB836CB5: ??? (in /lib64/
    ==6487== by 0xB825FA2: ??? (in /lib64/
    ==6487== If you believe this happened as a result of a stack
    ==6487== overflow in your program's main thread (unlikely but
    ==6487== possible), you can try to increase the size of the
    ==6487== main thread stack using the --main-stacksize= flag.
    ==6487== The main thread stack size used in this run was 10485760.
    ==6487== HEAP SUMMARY:
    ==6487== in use at exit: 568 bytes in 1 blocks
    ==6487== total heap usage: 2 allocs, 1 frees, 688 bytes allocated
    ==6487== LEAK SUMMARY:
    ==6487== definitely lost: 0 bytes in 0 blocks
    ==6487== indirectly lost: 0 bytes in 0 blocks
    ==6487== possibly lost: 0 bytes in 0 blocks
    ==6487== still reachable: 568 bytes in 1 blocks
    ==6487== suppressed: 0 bytes in 0 blocks
    ==6487== Rerun with --leak-check=full to see details of leaked memory
    ==6487== For counts of detected and suppressed errors, rerun with: -v
    ==6487== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 6)
    Segmentation fault
    Edit3: Contrary to my suspicions, SELinux is not running.
    [root@dev ~]# sestatus
    SELinux status: disabled
    Last edited by grep; 10-24-2014, 09:23 AM.