Announcement

Collapse
No announcement yet.

Segmentation fault

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Zaister
    replied
    Here's how I patched my glibc 2.18, so it no longer tries to use the SSE42 version of strstr:

    extract the glibc-2.18.tar.xz archive, then open the file

    glibc-2.18/sysdeps/i386/i686/multiarch/strstr-c.c

    in an editor. In line 26, replace "HAS_SSE4_2" with "false". Then save the file and compile and install glibc as usual.

    Leave a comment:


  • Zaister
    replied
    The new version seems to work fine now, thanks!

    Leave a comment:


  • Zaister
    replied
    That's' great!

    Leave a comment:


  • Tim
    replied
    We hope to get a release out today.

    Leave a comment:


  • Zaister
    replied
    Can you project a date for that release? These crashes are really annoying.

    Thank you.

    Leave a comment:


  • David
    replied
    Yes. There is a fix in the repository for this that will be in the next release.

    Leave a comment:


  • Zaister
    replied
    I'm getting more spurious segmentationfaults now that the strstr issue seems to be handled. Here's a backtrace from a crash I just experienced from calling the program with two files as arguments:

    Program received signal SIGSEGV, Segmentation fault.
    0xf7d7303a in QPixmap_isNull () from /opt/beyondcompare/lib64/libqtc.so.1
    (gdb) backtrace
    #0 0xf7d7303a in QPixmap_isNull () from /opt/beyondcompare/lib64/libqtc.so.1
    #1 0x080e3689 in ?? ()
    #2 0x081805fc in ?? ()
    #3 0x081a827e in ?? ()
    #4 0x084b24c5 in ?? ()
    #5 0x084dd5d3 in ?? ()
    #6 0x084db2a0 in ?? ()
    #7 0x08197e01 in ?? ()
    #8 0xf7792dab in makecontext () from /lib32/libc.so.6
    #9 0x081a8cd4 in ?? ()
    #10 0x08afe858 in ?? ()
    Backtrace stopped: previous frame inner to this frame (corrupt stack?)

    Can you help with this?

    Leave a comment:


  • Zaister
    replied
    Done! And thanks.

    Leave a comment:


  • David
    replied
    I have recompiled the lib and it still works for BC on my build machine. Send an email to support@scootersoftware.com with a link to this thread and we will get you a link to download the -msse2 test library.

    Leave a comment:


  • Zaister
    replied
    Thanks, that sounds good. I will try your recompiled lib then, if it workds for you.

    Leave a comment:


  • David
    replied
    I am not sure. I think that compiling glibc, on your end, with -mno-sse would work. I think this should work since on our side the libqt-mt.so.3 library that we provide is just calling symbol 'strstr' and doesn't know anything about __strstr_sse42 and so it must be the glibc code that is compiled to change that call into a call to sse42 code. Compiling glibc with -mno-see would prevent a strstr call being turned into a __strstr_msee42 call. The downside, from the bug report, seems to be a performance hit.

    At first I thought that that was the only option (we are using an old old Delphi/Kylix toolset to build linux BC and have yet to find an adequate upgrade). However, the gcc compiler we build libqt-mt.so.3 is from 2005 (not quite as old as Kylix that build BCompare) and should have a -msee mode. I will trying doing a rebuild of libqt-mt.so.3 with -msee on. If it compiles and works locally then I will pass it on to you to try on your system.

    Leave a comment:


  • Zaister
    replied
    Oh, interesting report about the glibc problem there. Is this something I can fix on my side (it seem my gcc should be new enough), or is that something you need to take into account when building Beyond Compare? I'm not quite sure.

    Leave a comment:


  • Zaister
    replied
    Sure, here's the backtrace info (unfortunately it seems glibc symbols are missing):

    Program received signal SIGSEGV, Segmentation fault.
    0xf787767d in __strstr_sse42 (s1=0xf7e583b7 "objectDestroyedSlot(QObject*)", s2=0xf75b442d "()")
    at ../sysdeps/x86_64/multiarch/strstr.c:385
    385 ../sysdeps/x86_64/multiarch/strstr.c: No such file or directory.
    (gdb) backtrace
    #0 0xf787767d in __strstr_sse42 (s1=0xf7e583b7 "objectDestroyedSlot(QObject*)", s2=0xf75b442d "()")
    at ../sysdeps/x86_64/multiarch/strstr.c:385
    #1 0xf7215213 in QConnection::QConnection(QObject const*, int, char const*, int) ()
    from /opt/beyondcompare/lib64/libqt-mt.so.3
    #2 0xf72713a5 in QObject::connectInternal(QObject const*, int, QObject const*, int, int) ()
    from /opt/beyondcompare/lib64/libqt-mt.so.3
    #3 0xf7271d27 in QObject::connect(QObject const*, char const*, QObject const*, char const*) ()
    from /opt/beyondcompare/lib64/libqt-mt.so.3
    #4 0xf7c8d8d6 in SignalHookBase::SignalHookBase(QObject*) () from /opt/beyondcompare/lib64/libqtc.so.1
    #5 0xf7e42eca in new_QTimerSignalHook () from /opt/beyondcompare/lib64/libqtc.so.1
    #6 0x08095239 in ?? ()
    #7 0x080ea7dd in ?? ()
    #8 0x080f8d7a in ?? ()
    #9 0x08061b90 in ?? ()
    #10 0x08068d80 in ?? ()
    #11 0x08068e0e in ?? ()
    #12 0xf7765ea3 in __libc_start_main (main=0x8068d9c, argc=1, argv=0xffffce24, init=0x8068e65, fini=0x8068e65,
    rtld_fini=0xf7feb800 <_dl_fini>, stack_end=0xffffce18) at libc-start.c:285
    #13 0x08068e64 in ?? ()

    I posted a link to the strace output in a previous post, but here it is again: http://pastebin.kde.org/ptpoh4lwj

    Yes, the ebuild I'm currently using installs under /opt/beyondcompare. It is customary for Gentoo ebuilds to install to /opt any package that is not compiled from sources. Only the documentation is installed into /usr. Here's the find dump:

    stefan@juliet ~ 2 $ find /opt/beyondcompare/
    /opt/beyondcompare/
    /opt/beyondcompare/bin
    /opt/beyondcompare/bin/bcompare.sh
    /opt/beyondcompare/bin/BCompare
    /opt/beyondcompare/bin/help
    /opt/beyondcompare/lib64
    /opt/beyondcompare/lib64/kde_context_menu.sh
    /opt/beyondcompare/lib64/libqtc.so.1
    /opt/beyondcompare/lib64/kde_context_menu
    /opt/beyondcompare/lib64/context_init.sh
    /opt/beyondcompare/lib64/libqt-mt.so.3

    Leave a comment:


  • David
    replied
    Did a google on __strstr_sse42 and hit this on the glibc wiki page

    https://sourceware.org/glibc/wiki/Release/2.18

    5.3.2. Issues with ``__strstr_sse42``

    It has been reported that after upgrading to 2.18 some users have experienced crashes in __strstr_sse42. The first reports of this were from Allan McRae (Arch Linux) here: http://www.sourceware.org/ml/libc-al.../msg00257.html. It appears that this is a compiler issue, but none the less it results in a non-functioning glibc 2.18 that passes the testsuite cleanly but then causes most of x86 userspace to crash. The fundamental issue is that the psABI is not followed and the stack is not maintained aligned. If __strstr_sse42 is called with an unaligned stack it will fault as this violates the psABI. The only real solution is to patch glibc to make these functions inline again, but that isn't a real fix and only papers over the actual problem which will eventually occur if any of the code is perturbed enough to get a misaligned stack again. At present there are two potential solutions. The first solution is to disable the use of the SSE42 routines in glibc, but that has a performance penalty. The consensus around a correct solution is to rebuild the faulty code that calls __strstr_sse42 with a new enough compiler (any gcc released after the year 2000 when -msse went in with the 16 byte stack alignment) that always ensures the stack is aligned modulo 16 bytes, or to correct any assembly that may leave the stack unaligned. There is still some debate over the issue since glibc should try to be as backwards compatible as possible and should therefore support older binaries with misaligned stacks calling SSE42 strstr, and doing this would require new entry points that do dynamic stack realingment. However, doing the dynamic stack realignment is an added cost to the SSE42 strstr routine which already has poor asymptotic performance whom several argue should be removed entirely or fixed, see bug https://sourceware.org/bugzilla/show_bug.cgi?id=12100.

    Leave a comment:


  • David
    replied
    Given that someone else has seen a similar issue I am also not convinced that you have a bad glibc build i.e. I am not expecting that rebuilding will fix the problem.

    The other piece of information that you can get from gdb, is after the program segfaults call 'thread apply all backtrace' (though in this case I don't think any additional threads have been spun up yet so 'backtrace' is probably sufficient). This will print out a stack trace of where the program was when things went south - or approximately.

    running

    'strace LD_LIBRARY_PATH="$LD_LIBRARY_PATH;/opt/beyondcompare/lib64" /opt/beyondcompare/bin/BCompare'

    Will show the system calls being made as it crashes.

    You are most welcome to post an updated ebuild here. It would probably be useful to me so see where everything is installed on your machine with the current ebuild. I am assuming that everything is sitting under /opt/beyondcompare? So maybe a 'find /opt/beyondcompare' dump.

    Leave a comment:

Working...
X