This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Segmentation fault upon a startup
#1
Hi,
after building the last version on Arch Linux I am not able to start the Hybrid due to segmentation fault immediately after startup.
Unfortunately, I am not able to get any debug or info whatsoever except this:

$ Hybrid
Segmentation fault (core dumped)

The output from the journal:

systemd-coredump[207125]: Process 207123 (Hybrid) of user 1000 dumped core.
            
                                                      Stack trace of thread 207123:
                                                      #0  0x00007fa7711e1100 n/a (n/a + 0x0)


I also tried to run Hybrid with valgrind to get more debug info:

$ valgrind -v Hybrid
==92525== Memcheck, a memory error detector
==92525== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==92525== Using Valgrind-3.15.0-608cb11914-20190413X and LibVEX; rerun with -h for copyright info
==92525== Command: Hybrid
==92525==
--92525-- Valgrind options:
--92525--    -v
--92525-- Contents of /proc/version:
--92525--  Linux version 5.6.10-arch1-1 (linux@archlinux) (gcc version 9.3.0 (Arch Linux 9.3.0-1)) #1 SMP PREEMPT Sat, 02 May 2020 19:11:54 +0000
--92525--
--92525-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-lzcnt-rdtscp-sse3-ssse3-avx-avx2-bmi-f16c-rdrand
--92525-- Page sizes: currently 4096, max supported 4096
--92525-- Valgrind library directory: /usr/lib/valgrind
--92525-- Reading syms from /usr/lib/valgrind/memcheck-amd64-linux
--92525--    object doesn't have a dynamic symbol table
--92525-- Scheduler: using generic scheduler lock implementation.
--92525-- Reading suppressions file: /usr/lib/valgrind/default.supp
==92525== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-92525-by-johnyr-on-???
==92525== embedded gdbserver: writing to  /tmp/vgdb-pipe-to-vgdb-from-92525-by-johnyr-on-???
==92525== embedded gdbserver: shared mem  /tmp/vgdb-pipe-shared-mem-vgdb-92525-by-johnyr-on-???
==92525==
==92525== TO CONTROL THIS PROCESS USING vgdb (which you probably
==92525== don't want to do, unless you know exactly what you're doing,
==92525== or are doing some strange experiment):
==92525==  /usr/lib/valgrind/../../bin/vgdb --pid=92525 ...command...
==92525==
==92525== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==92525==  /path/to/gdb Hybrid
==92525== and then give GDB the following command
==92525==  target remote | /usr/lib/valgrind/../../bin/vgdb --pid=92525
==92525== --pid is optional if only one valgrind process is running
==92525==
--92525-- Reading syms from /usr/lib/ld-2.31.so
--92525-- REDIR: 0x69c82b0 (ld-linux-x86-64.so.2:strlen) redirected to 0x580c7532 (vgPlain_amd64_linux_REDIR_FOR_strlen)
==92525== Invalid read of size 4
==92525==    at 0x69AABEE: dl_main (in /usr/lib/ld-2.31.so)
==92525==    by 0x69C225A: _dl_sysdep_start (in /usr/lib/ld-2.31.so)
==92525==    by 0x69A9FDB: _dl_start (in /usr/lib/ld-2.31.so)
==92525==    by 0x69A9107: ??? (in /usr/lib/ld-2.31.so)
==92525==  Address 0x208040 is not stack'd, malloc'd or (recently) free'd
==92525==
==92525==
==92525== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==92525==  Access not within mapped region at address 0x208040
==92525==    at 0x69AABEE: dl_main (in /usr/lib/ld-2.31.so)
==92525==    by 0x69C225A: _dl_sysdep_start (in /usr/lib/ld-2.31.so)
==92525==    by 0x69A9FDB: _dl_start (in /usr/lib/ld-2.31.so)
==92525==    by 0x69A9107: ??? (in /usr/lib/ld-2.31.so)
==92525==  If you believe this happened as a result of a stack
==92525==  overflow in your program's main thread (unlikely but
==92525==  possible), you can try to increase the size of the
==92525==  main thread stack using the --main-stacksize= flag.
==92525==  The main thread stack size used in this run was 8388608.
==92525==
==92525== HEAP SUMMARY:
==92525==    in use at exit: 0 bytes in 0 blocks
==92525==  total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==92525==
==92525== All heap blocks were freed -- no leaks are possible
==92525==
==92525== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
==92525==
==92525== 1 errors in context 1 of 1:
==92525== Invalid read of size 4
==92525==    at 0x69AABEE: dl_main (in /usr/lib/ld-2.31.so)
==92525==    by 0x69C225A: _dl_sysdep_start (in /usr/lib/ld-2.31.so)
==92525==    by 0x69A9FDB: _dl_start (in /usr/lib/ld-2.31.so)
==92525==    by 0x69A9107: ??? (in /usr/lib/ld-2.31.so)
==92525==  Address 0x208040 is not stack'd, malloc'd or (recently) free'd
==92525==
==92525== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)

Could you please point me to some way I could debug better and discover what could be the issue?
Thanx,
Jan
Reply
#2
Quote:after building the last version on Arch Linux I am not able to start the Hybrid due to segmentation fault immediately after startup
confused since:
a. I'm not sure what you are building, but Hybrid isn't open source, so not sure what you are doing.
b. Do previous versions work? The binaries I released now use are compiled with Qt 5.9.5 old versions used Qt 5.5.1.

Does Hybrid output anything if you start is with './Hybrid --debug' in a terminal?
What does 'ldd Hybrid' output for you?
On my build system I get:
ldd Hybrid
    linux-vdso.so.1 (0x00007ffdd19fc000)
    libQt5Widgets.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 (0x00007f091157f000)
    libQt5Multimedia.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Multimedia.so.5 (0x00007f0911268000)
    libQt5Gui.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5 (0x00007f0910aff000)
    libQt5Xml.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Xml.so.5 (0x00007f09108c3000)
    libQt5Network.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Network.so.5 (0x00007f0910537000)
    libQt5DBus.so.5 => /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5 (0x00007f09102ad000)
    libQt5Core.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 (0x00007f090fb62000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f090f7d9000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f090f43b000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f090f223000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f090ee32000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f090ec13000)
    libpulse.so.0 => /usr/lib/x86_64-linux-gnu/libpulse.so.0 (0x00007f090e9c3000)
    libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x00007f090e737000)
    libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007f090e505000)
    libharfbuzz.so.0 => /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0 (0x00007f090e267000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f090e04a000)
    libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007f090ddfd000)
    libicui18n.so.60 => /usr/lib/x86_64-linux-gnu/libicui18n.so.60 (0x00007f090d95c000)
    libicuuc.so.60 => /usr/lib/x86_64-linux-gnu/libicuuc.so.60 (0x00007f090d5a4000)
    libdouble-conversion.so.1 => /usr/lib/x86_64-linux-gnu/libdouble-conversion.so.1 (0x00007f090d393000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f090d18f000)
    libglib-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f090ce78000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f0913f6d000)
    libpulsecommon-11.1.so => /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-11.1.so (0x00007f090cbfa000)
    libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0 (0x00007f090c9c9000)
    libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007f090c713000)
    libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f090c45f000)
    libgraphite2.so.3 => /usr/lib/x86_64-linux-gnu/libgraphite2.so.3 (0x00007f090c232000)
    libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f090bfae000)
    libicudata.so.60 => /usr/lib/x86_64-linux-gnu/libicudata.so.60 (0x00007f090a405000)
    libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f090a193000)
    libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f0909f6b000)
    libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f0909d61000)
    libsndfile.so.1 => /usr/lib/x86_64-linux-gnu/libsndfile.so.1 (0x00007f0909ae8000)
    libasyncns.so.0 => /usr/lib/x86_64-linux-gnu/libasyncns.so.0 (0x00007f09098e2000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f09096da000)
    libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f09093a2000)
    liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f090917c000)
    liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f0908f60000)
    libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f0908c44000)
    libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f0908a40000)
    libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f090883a000)
    libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f0908620000)
    libFLAC.so.8 => /usr/lib/x86_64-linux-gnu/libFLAC.so.8 (0x00007f09083a9000)
    libogg.so.0 => /usr/lib/x86_64-linux-gnu/libogg.so.0 (0x00007f09081a0000)
    libvorbis.so.0 => /usr/lib/x86_64-linux-gnu/libvorbis.so.0 (0x00007f0907f75000)
    libvorbisenc.so.2 => /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2 (0x00007f0907ccc000)
    libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f0907ab1000)
    libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f090789c000)
    libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f0907687000)

Cu Selur
Reply
#3
Sorry for the confusion. I am trying to create a new package version for AUR.

Previous versions were working, with the current version I get:

ldd ./Hybrid
      not a dynamic executable

./Hybrid --debug also gives Segmentation fault

As for dependencies, I have qt5-base-5.14.2-2 installed.
Reply
#4
To be sure there wasn't a problem with the upload I attached the binary I did run ldd on.

Quote:As for dependencies, I have qt5-base-5.14.2-2 installed.
Not sure how the packaging on arch is, and whether qt5-base includes all of these:
  • Qt5Widgets
  • Qt5Multimedia
  • Qt5Gui
  • Qt5Xml
  • Qt5Network
  • Qt5DBus
  • Qt5Core

Cu Selur
Reply
#5
(06.05.2020, 15:33)Selur Wrote: To be sure there wasn't a problem with the upload I attached the binary I did run ldd on.

Quote:As for dependencies, I have qt5-base-5.14.2-2 installed.
Not sure how the packaging on arch is, and whether qt5-base includes all of these:
  • Qt5Widgets
  • Qt5Multimedia
  • Qt5Gui
  • Qt5Xml
  • Qt5Network
  • Qt5DBus
  • Qt5Core

Cu Selur



According to the qt5-base 5.14.2-2 File List, the package does include all "modules" specified, except Qt5Multimedia which is provided by the qt5-multimedia package. I have both installed.

The test file (Hybrid_test_64bit_binary_qt595.zipyou provided actually works fine (it's md5sum is 5c16ef8bd5982689f5080ae4a6b394a8).
md5sum of the Hybrid file in Hybrid_20200501_64bit_binary_qt595.zip is 6a76d4ea02742a941fdb0d4894faa0a5 though.

I suspect there might be something wrong with that particular build?
I tried to download it twice, first on Friday as well as now.

Sincerely,
Jan
Reply
#6
It's clear that the checksums differ since this is a new build. (at least the version info would be different)
My current guess is that I accidentally uploaded the static binary I build for the Ubuntu package instead of the dynamic binary.
-> using the Hybrid_test_64bit_binary_qt595 should be fine.

Cu Selur
Reply
#7
Dear Selur,
after recent updates, I've tried new builds (2020.07.11.1 and 2020.06.21.1) and unfortunately, the issue persists.
Could you please look at the issue and make the change you did in the "test" build also in the upstream?

Many thanks,
Jan
Reply
#8
What output do you get when you start Hybrid from a terminal? (also try when calling Hybrid with 'Hybrid --debug')
I did not really change anything in the last test build, I only accidentally uploaded a wrong version,..
I know there's a problem with a segfault when closing Hybrid, but startup works fine here,...
I attached my current dev version (which fixes the segfault on close), does it work better for you?

Cu Selur
Reply
#9
Hello,
both test version from your post and the current version on the web (without dependencies) dumps: segmentation fault (core dumped)
no matter if with --debug or not.
The only two versions which work at the moment are the one with dependencies and the test build you have posted in this thread before (the previous one, not from yesterday). 
Was there anything changed?

Sincerely,
Jan
Reply
#10
Tons of things change all the time,....
Does moving/deleting your settings folder change anything?
I thing I know where the problem is,...
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)