| Summary: | "MyExe" received signal SIGSEGV, Segmentation fault | ||
|---|---|---|---|
| Product: | [Unmaintained] rust-qt-binding-generator | Reporter: | Bruno Bigras <bigras.bruno> |
| Component: | general | Assignee: | Jos van den Oever <jos> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | illis+kde, jlode90 |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
Patch to fix issue running the demo on Arch Linux
valgrind_log_testing_#D11232 |
||
|
Description
Bruno Bigras
2018-01-25 17:05:39 UTC
Does this happen at startup without any user interaction? (In reply to Jos van den Oever from comment #1) > Does this happen at startup without any user interaction? Yes at startup. Could you run the debug version in valgrind? cmake -GNinja -DCMAKE_BUILD_TYPE=Debug .. ninja valgrind MyExe ==2023== Memcheck, a memory error detector ==2023== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==2023== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==2023== Command: ./MyExe ==2023== --2023-- WARNING: unhandled amd64-linux syscall: 332 --2023-- You may be able to write your own handler. --2023-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --2023-- Nevertheless we consider this a bug. Please report --2023-- it at http://valgrind.org/support/bug_reports.html. ==2023== Syscall param ioctl(generic) points to uninitialised byte(s) ==2023== at 0x7B24D87: ioctl (in /usr/lib/libc-2.26.so) ==2023== by 0x1E1CD6C8: drmIoctl (in /usr/lib/libdrm.so.2.4.0) ==2023== by 0x1E1D063C: drmCommandWriteRead (in /usr/lib/libdrm.so.2.4.0) ==2023== by 0x1F746C7A: ??? (in /usr/lib/libdrm_nouveau.so.2.0.0) ==2023== by 0x1F747592: nouveau_device_new (in /usr/lib/libdrm_nouveau.so.2.0.0) ==2023== by 0x1E8F51F3: nouveau_drm_screen_create (in /usr/lib/dri/nouveau_dri.so) ==2023== by 0x1E45AB06: ??? (in /usr/lib/dri/nouveau_dri.so) ==2023== by 0x1E8F0720: ??? (in /usr/lib/dri/nouveau_dri.so) ==2023== by 0x1E7BEAF7: ??? (in /usr/lib/dri/nouveau_dri.so) ==2023== by 0x1E7B9AEF: ??? (in /usr/lib/dri/nouveau_dri.so) ==2023== by 0x1D355D0D: ??? (in /usr/lib/libGLX_mesa.so.0.0.0) ==2023== by 0x1D32DA6B: ??? (in /usr/lib/libGLX_mesa.so.0.0.0) ==2023== Address 0x1cdf3dc2 is 2 bytes inside a block of size 72 alloc'd ==2023== at 0x4C2CEDF: malloc (vg_replace_malloc.c:299) ==2023== by 0x1F746C1C: ??? (in /usr/lib/libdrm_nouveau.so.2.0.0) ==2023== by 0x1F747592: nouveau_device_new (in /usr/lib/libdrm_nouveau.so.2.0.0) ==2023== by 0x1E8F51F3: nouveau_drm_screen_create (in /usr/lib/dri/nouveau_dri.so) ==2023== by 0x1E45AB06: ??? (in /usr/lib/dri/nouveau_dri.so) ==2023== by 0x1E8F0720: ??? (in /usr/lib/dri/nouveau_dri.so) ==2023== by 0x1E7BEAF7: ??? (in /usr/lib/dri/nouveau_dri.so) ==2023== by 0x1E7B9AEF: ??? (in /usr/lib/dri/nouveau_dri.so) ==2023== by 0x1D355D0D: ??? (in /usr/lib/libGLX_mesa.so.0.0.0) ==2023== by 0x1D32DA6B: ??? (in /usr/lib/libGLX_mesa.so.0.0.0) ==2023== by 0x1D3296A2: ??? (in /usr/lib/libGLX_mesa.so.0.0.0) ==2023== by 0x1D32A9D1: ??? (in /usr/lib/libGLX_mesa.so.0.0.0) ==2023== ==2023== Syscall param ioctl(generic) points to uninitialised byte(s) ==2023== at 0x7B24D87: ioctl (in /usr/lib/libc-2.26.so) ==2023== by 0x1E1CD6C8: drmIoctl (in /usr/lib/libdrm.so.2.4.0) ==2023== by 0x1E1D063C: drmCommandWriteRead (in /usr/lib/libdrm.so.2.4.0) ==2023== by 0x1F746E79: nouveau_object_mthd (in /usr/lib/libdrm_nouveau.so.2.0.0) ==2023== by 0x1F7475AE: nouveau_device_new (in /usr/lib/libdrm_nouveau.so.2.0.0) ==2023== by 0x1E8F51F3: nouveau_drm_screen_create (in /usr/lib/dri/nouveau_dri.so) ==2023== by 0x1E45AB06: ??? (in /usr/lib/dri/nouveau_dri.so) ==2023== by 0x1E8F0720: ??? (in /usr/lib/dri/nouveau_dri.so) ==2023== by 0x1E7BEAF7: ??? (in /usr/lib/dri/nouveau_dri.so) ==2023== by 0x1E7B9AEF: ??? (in /usr/lib/dri/nouveau_dri.so) ==2023== by 0x1D355D0D: ??? (in /usr/lib/libGLX_mesa.so.0.0.0) ==2023== by 0x1D32DA6B: ??? (in /usr/lib/libGLX_mesa.so.0.0.0) ==2023== Address 0x1cdf3e52 is 2 bytes inside a block of size 136 alloc'd ==2023== at 0x4C2CEDF: malloc (vg_replace_malloc.c:299) ==2023== by 0x1F746E40: nouveau_object_mthd (in /usr/lib/libdrm_nouveau.so.2.0.0) ==2023== by 0x1F7475AE: nouveau_device_new (in /usr/lib/libdrm_nouveau.so.2.0.0) ==2023== by 0x1E8F51F3: nouveau_drm_screen_create (in /usr/lib/dri/nouveau_dri.so) ==2023== by 0x1E45AB06: ??? (in /usr/lib/dri/nouveau_dri.so) ==2023== by 0x1E8F0720: ??? (in /usr/lib/dri/nouveau_dri.so) ==2023== by 0x1E7BEAF7: ??? (in /usr/lib/dri/nouveau_dri.so) ==2023== by 0x1E7B9AEF: ??? (in /usr/lib/dri/nouveau_dri.so) ==2023== by 0x1D355D0D: ??? (in /usr/lib/libGLX_mesa.so.0.0.0) ==2023== by 0x1D32DA6B: ??? (in /usr/lib/libGLX_mesa.so.0.0.0) ==2023== by 0x1D3296A2: ??? (in /usr/lib/libGLX_mesa.so.0.0.0) ==2023== by 0x1D32A9D1: ??? (in /usr/lib/libGLX_mesa.so.0.0.0) ==2023== ==2023== Warning: set address range perms: large range [0x59e43040, 0x9cad093e) (undefined) ==2023== Invalid read of size 16 ==2023== at 0x6B2BD14: ??? (in /usr/lib/libQt5Core.so.5.10.0) ==2023== by 0x6B2C063: ??? (in /usr/lib/libQt5Core.so.5.10.0) ==2023== by 0x6958592: QString::fromUtf8_helper(char const*, int) (in /usr/lib/libQt5Core.so.5.10.0) ==2023== by 0x1488BB: QString::fromUtf8(char const*, int) (qstring.h:562) ==2023== by 0x148561: (anonymous namespace)::qstring_t::operator QString() const (Bindings.cpp:16) ==2023== by 0x1485AD: (anonymous namespace)::set_qstring(QString*, (anonymous namespace)::qstring_t*) (Bindings.cpp:21) ==2023== by 0x1491D7: simple_message_get (interface.rs:104) ==2023== by 0x14878B: Simple::message() const (Bindings.cpp:58) ==2023== by 0x148A80: Simple::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (moc_Bindings.cpp:97) ==2023== by 0x58E1773: ??? (in /usr/lib/libQt5Qml.so.5.10.0) ==2023== by 0x58FA2CB: QV4::Runtime::method_getQmlQObjectProperty(QV4::ExecutionEngine*, QV4::Value const&, int, bool) (in /usr/lib/libQt5Qml.so.5.10.0) ==2023== by 0x405708D: ??? (in /home/bbigras/.cache/MyExe/qmlcache/22d0c1f3ae507d412dc519000ad4a4852a298091.ui.qmlc) ==2023== Address 0x6f57206f6c6c6548 is not stack'd, malloc'd or (recently) free'd ==2023== ==2023== ==2023== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==2023== General Protection Fault ==2023== at 0x6B2BD14: ??? (in /usr/lib/libQt5Core.so.5.10.0) ==2023== by 0x6B2C063: ??? (in /usr/lib/libQt5Core.so.5.10.0) ==2023== by 0x6958592: QString::fromUtf8_helper(char const*, int) (in /usr/lib/libQt5Core.so.5.10.0) ==2023== by 0x1488BB: QString::fromUtf8(char const*, int) (qstring.h:562) ==2023== by 0x148561: (anonymous namespace)::qstring_t::operator QString() const (Bindings.cpp:16) ==2023== by 0x1485AD: (anonymous namespace)::set_qstring(QString*, (anonymous namespace)::qstring_t*) (Bindings.cpp:21) ==2023== by 0x1491D7: simple_message_get (interface.rs:104) ==2023== by 0x14878B: Simple::message() const (Bindings.cpp:58) ==2023== by 0x148A80: Simple::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (moc_Bindings.cpp:97) ==2023== by 0x58E1773: ??? (in /usr/lib/libQt5Qml.so.5.10.0) ==2023== by 0x58FA2CB: QV4::Runtime::method_getQmlQObjectProperty(QV4::ExecutionEngine*, QV4::Value const&, int, bool) (in /usr/lib/libQt5Qml.so.5.10.0) ==2023== by 0x405708D: ??? (in /home/bbigras/.cache/MyExe/qmlcache/22d0c1f3ae507d412dc519000ad4a4852a298091.ui.qmlc) ==2023== ==2023== HEAP SUMMARY: ==2023== in use at exit: 1,124,057,002 bytes in 37,594 blocks ==2023== total heap usage: 242,291 allocs, 204,697 frees, 1,137,859,750 bytes allocated ==2023== ==2023== LEAK SUMMARY: ==2023== definitely lost: 72 bytes in 6 blocks ==2023== indirectly lost: 8,248 bytes in 1 blocks ==2023== possibly lost: 19,162 bytes in 229 blocks ==2023== still reachable: 1,123,946,992 bytes in 36,685 blocks ==2023== of which reachable via heuristic: ==2023== length64 : 4,872 bytes in 81 blocks ==2023== newarray : 40,032 bytes in 67 blocks ==2023== suppressed: 0 bytes in 0 blocks ==2023== Rerun with --leak-check=full to see details of leaked memory ==2023== ==2023== For counts of detected and suppressed errors, rerun with: -v ==2023== Use --track-origins=yes to see where uninitialised values come from ==2023== ERROR SUMMARY: 7 errors from 3 contexts (suppressed: 0 from 0) Does the demo in demo/ work? I've tried to reproduce the problem but cannot. I've tried on my machine and in the provided docker environment. The latter gives this output when running in valgrind: $ valgrind ./MyExe ==106== Memcheck, a memory error detector ==106== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==106== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==106== Command: ./MyExe ==106== QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-neon' libGL error: MESA-LOADER: failed to retrieve device information libGL error: Version 4 or later of flush extension not found libGL error: failed to load driver: i915 libGL error: failed to open drm device: No such file or directory libGL error: failed to load driver: i965 ==114== Warning: invalid file descriptor 1048564 in syscall close() ==114== Warning: invalid file descriptor 1048565 in syscall close() ==114== Warning: invalid file descriptor 1048566 in syscall close() ==114== Warning: invalid file descriptor 1048567 in syscall close() ==114== Use --log-fd=<number> to select an alternative log fd. ==114== Warning: invalid file descriptor 1048568 in syscall close() ==114== Warning: invalid file descriptor 1048569 in syscall close() ==114== ==114== HEAP SUMMARY: ==114== in use at exit: 1,459,601 bytes in 12,352 blocks ==114== total heap usage: 27,243 allocs, 14,891 frees, 32,317,012 bytes allocated ==114== ==114== LEAK SUMMARY: ==114== definitely lost: 4,816 bytes in 16 blocks ==114== indirectly lost: 23,697 bytes in 205 blocks ==114== possibly lost: 13,177 bytes in 188 blocks ==114== still reachable: 1,417,911 bytes in 11,943 blocks ==114== of which reachable via heuristic: ==114== newarray : 38,080 bytes in 16 blocks ==114== multipleinheritance: 840 bytes in 3 blocks ==114== suppressed: 0 bytes in 0 blocks ==114== Rerun with --leak-check=full to see details of leaked memory ==114== ==114== For counts of detected and suppressed errors, rerun with: -v ==114== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ==106== Thread 7 llvmpipe-3: ==106== Conditional jump or move depends on uninitialised value(s) ==106== at 0x40342BF: ??? ==106== by 0x156FFDF6: ??? (in /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so) ==106== by 0x157011A4: ??? (in /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so) ==106== by 0x156FF4DA: ??? (in /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so) ==106== by 0x156FFB82: ??? (in /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so) ==106== by 0x156FF9B6: ??? (in /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so) ==106== by 0x64EB7FB: start_thread (pthread_create.c:465) ==106== by 0x6DB4B5E: clone (clone.S:95) ==106== ==106== Conditional jump or move depends on uninitialised value(s) ==106== at 0x40343C6: ??? ==106== by 0x156FFDF6: ??? (in /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so) ==106== by 0x157011A4: ??? (in /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so) ==106== by 0x156FF4DA: ??? (in /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so) ==106== by 0x156FFB82: ??? (in /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so) ==106== by 0x156FF9B6: ??? (in /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so) ==106== by 0x64EB7FB: start_thread (pthread_create.c:465) ==106== by 0x6DB4B5E: clone (clone.S:95) ==106== ==106== Conditional jump or move depends on uninitialised value(s) ==106== at 0x40342BF: ??? ==106== by 0x156FFDF6: ??? (in /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so) ==106== by 0x157018EB: ??? (in /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so) ==106== by 0x156FF4DA: ??? (in /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so) ==106== by 0x156FFB82: ??? (in /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so) ==106== by 0x156FF9B6: ??? (in /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so) ==106== by 0x64EB7FB: start_thread (pthread_create.c:465) ==106== by 0x6DB4B5E: clone (clone.S:95) ==106== ==106== Conditional jump or move depends on uninitialised value(s) ==106== at 0x40343C6: ??? ==106== by 0x156FFDF6: ??? (in /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so) ==106== by 0x157018EB: ??? (in /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so) ==106== by 0x156FF4DA: ??? (in /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so) ==106== by 0x156FFB82: ??? (in /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so) ==106== by 0x156FF9B6: ??? (in /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so) ==106== by 0x64EB7FB: start_thread (pthread_create.c:465) ==106== by 0x6DB4B5E: clone (clone.S:95) ==106== ==106== ==106== HEAP SUMMARY: ==106== in use at exit: 391,816 bytes in 5,089 blocks ==106== total heap usage: 144,706 allocs, 139,617 frees, 103,767,803 bytes allocated ==106== ==106== LEAK SUMMARY: ==106== definitely lost: 1,672 bytes in 9 blocks ==106== indirectly lost: 17,269 bytes in 217 blocks ==106== possibly lost: 0 bytes in 0 blocks ==106== still reachable: 372,875 bytes in 4,863 blocks ==106== suppressed: 0 bytes in 0 blocks ==106== Rerun with --leak-check=full to see details of leaked memory ==106== ==106== For counts of detected and suppressed errors, rerun with: -v ==106== Use --track-origins=yes to see where uninitialised values come from ==106== ERROR SUMMARY: 3600 errors from 4 contexts (suppressed: 118 from 1) You can enter the docker environment with docker/docker-bash-session.sh What distro version are you running? I see you have the latest Qt. (In reply to Jos van den Oever from comment #5) > Does the demo in demo/ work? No I have a segmentation fault (see the end of my comment). > I've tried to reproduce the problem but cannot. I've tried on my machine and > in the provided docker environment. > [...] > You can enter the docker environment with docker/docker-bash-session.sh If I build the demo inside the docker environment, I can run it outside the environment and it works. I can't run it inside the environment because I get 'Could not connect to any X display' which I think is expected. > What distro version are you running? I see you have the latest Qt. Arch Here's if I try the demo (built with my distro stuff, not the docker env): bbigras@bruno ~/rust-qt-binding-generator/build/demo (git)-[1a5c019...] % ./Demo [1] 32441 segmentation fault (core dumped) ./Demo bbigras@bruno ~/rust-qt-binding-generator/build/demo (git)-[1a5c019...] % valgrind ./Demo :( ==32711== Memcheck, a memory error detector ==32711== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==32711== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==32711== Command: ./Demo ==32711== --32711-- WARNING: unhandled amd64-linux syscall: 332 --32711-- You may be able to write your own handler. --32711-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --32711-- Nevertheless we consider this a bug. Please report --32711-- it at http://valgrind.org/support/bug_reports.html. ==32711== Syscall param ioctl(generic) points to uninitialised byte(s) ==32711== at 0x8B7DD87: ioctl (in /usr/lib/libc-2.26.so) ==32711== by 0x1F5466C8: drmIoctl (in /usr/lib/libdrm.so.2.4.0) ==32711== by 0x1F54963C: drmCommandWriteRead (in /usr/lib/libdrm.so.2.4.0) ==32711== by 0x20ABFC7A: ??? (in /usr/lib/libdrm_nouveau.so.2.0.0) ==32711== by 0x20AC0592: nouveau_device_new (in /usr/lib/libdrm_nouveau.so.2.0.0) ==32711== by 0x1FC6E1F3: nouveau_drm_screen_create (in /usr/lib/dri/nouveau_dri.so) ==32711== by 0x1F7D3B06: ??? (in /usr/lib/dri/nouveau_dri.so) ==32711== by 0x1FC69720: ??? (in /usr/lib/dri/nouveau_dri.so) ==32711== by 0x1FB37AF7: ??? (in /usr/lib/dri/nouveau_dri.so) ==32711== by 0x1FB32AEF: ??? (in /usr/lib/dri/nouveau_dri.so) ==32711== by 0x1E6CED0D: ??? (in /usr/lib/libGLX_mesa.so.0.0.0) ==32711== by 0x1E6A6A6B: ??? (in /usr/lib/libGLX_mesa.so.0.0.0) ==32711== Address 0x1e38eb72 is 2 bytes inside a block of size 72 alloc'd ==32711== at 0x4C2CEDF: malloc (vg_replace_malloc.c:299) ==32711== by 0x20ABFC1C: ??? (in /usr/lib/libdrm_nouveau.so.2.0.0) ==32711== by 0x20AC0592: nouveau_device_new (in /usr/lib/libdrm_nouveau.so.2.0.0) ==32711== by 0x1FC6E1F3: nouveau_drm_screen_create (in /usr/lib/dri/nouveau_dri.so) ==32711== by 0x1F7D3B06: ??? (in /usr/lib/dri/nouveau_dri.so) ==32711== by 0x1FC69720: ??? (in /usr/lib/dri/nouveau_dri.so) ==32711== by 0x1FB37AF7: ??? (in /usr/lib/dri/nouveau_dri.so) ==32711== by 0x1FB32AEF: ??? (in /usr/lib/dri/nouveau_dri.so) ==32711== by 0x1E6CED0D: ??? (in /usr/lib/libGLX_mesa.so.0.0.0) ==32711== by 0x1E6A6A6B: ??? (in /usr/lib/libGLX_mesa.so.0.0.0) ==32711== by 0x1E6A20A4: ??? (in /usr/lib/libGLX_mesa.so.0.0.0) ==32711== by 0x1E6A29DC: ??? (in /usr/lib/libGLX_mesa.so.0.0.0) ==32711== ==32711== Syscall param ioctl(generic) points to uninitialised byte(s) ==32711== at 0x8B7DD87: ioctl (in /usr/lib/libc-2.26.so) ==32711== by 0x1F5466C8: drmIoctl (in /usr/lib/libdrm.so.2.4.0) ==32711== by 0x1F54963C: drmCommandWriteRead (in /usr/lib/libdrm.so.2.4.0) ==32711== by 0x20ABFE79: nouveau_object_mthd (in /usr/lib/libdrm_nouveau.so.2.0.0) ==32711== by 0x20AC05AE: nouveau_device_new (in /usr/lib/libdrm_nouveau.so.2.0.0) ==32711== by 0x1FC6E1F3: nouveau_drm_screen_create (in /usr/lib/dri/nouveau_dri.so) ==32711== by 0x1F7D3B06: ??? (in /usr/lib/dri/nouveau_dri.so) ==32711== by 0x1FC69720: ??? (in /usr/lib/dri/nouveau_dri.so) ==32711== by 0x1FB37AF7: ??? (in /usr/lib/dri/nouveau_dri.so) ==32711== by 0x1FB32AEF: ??? (in /usr/lib/dri/nouveau_dri.so) ==32711== by 0x1E6CED0D: ??? (in /usr/lib/libGLX_mesa.so.0.0.0) ==32711== by 0x1E6A6A6B: ??? (in /usr/lib/libGLX_mesa.so.0.0.0) ==32711== Address 0x1e38ec02 is 2 bytes inside a block of size 136 alloc'd ==32711== at 0x4C2CEDF: malloc (vg_replace_malloc.c:299) ==32711== by 0x20ABFE40: nouveau_object_mthd (in /usr/lib/libdrm_nouveau.so.2.0.0) ==32711== by 0x20AC05AE: nouveau_device_new (in /usr/lib/libdrm_nouveau.so.2.0.0) ==32711== by 0x1FC6E1F3: nouveau_drm_screen_create (in /usr/lib/dri/nouveau_dri.so) ==32711== by 0x1F7D3B06: ??? (in /usr/lib/dri/nouveau_dri.so) ==32711== by 0x1FC69720: ??? (in /usr/lib/dri/nouveau_dri.so) ==32711== by 0x1FB37AF7: ??? (in /usr/lib/dri/nouveau_dri.so) ==32711== by 0x1FB32AEF: ??? (in /usr/lib/dri/nouveau_dri.so) ==32711== by 0x1E6CED0D: ??? (in /usr/lib/libGLX_mesa.so.0.0.0) ==32711== by 0x1E6A6A6B: ??? (in /usr/lib/libGLX_mesa.so.0.0.0) ==32711== by 0x1E6A20A4: ??? (in /usr/lib/libGLX_mesa.so.0.0.0) ==32711== by 0x1E6A29DC: ??? (in /usr/lib/libGLX_mesa.so.0.0.0) ==32711== ==32711== Invalid read of size 4 ==32711== at 0x16B8A4: (anonymous namespace)::qbytearray_t::operator QByteArray() const (Bindings.cpp:70) ==32711== by 0x16B8F4: (anonymous namespace)::set_qbytearray(QByteArray*, (anonymous namespace)::qbytearray_t*) (Bindings.cpp:75) ==32711== by 0x17C7CF: file_system_tree_data_file_icon (interface.rs:743) ==32711== by 0x16C6B5: FileSystemTree::fileIcon(QModelIndex const&) const (Bindings.cpp:387) ==32711== by 0x16CC59: FileSystemTree::data(QModelIndex const&, int) const (Bindings.cpp:439) ==32711== by 0x7CFD528: QSortFilterProxyModel::data(QModelIndex const&, int) const (in /usr/lib/libQt5Core.so.5.10.0) ==32711== by 0x17920A: SortedModel::data(QModelIndex const&, int) const (SortedModel.h:33) ==32711== by 0x6E5A529: QStyledItemDelegate::initStyleOption(QStyleOptionViewItem*, QModelIndex const&) const (in /usr/lib/libQt5Widgets.so.5.10.0) ==32711== by 0x6E59A96: QStyledItemDelegate::sizeHint(QStyleOptionViewItem const&, QModelIndex const&) const (in /usr/lib/libQt5Widgets.so.5.10.0) ==32711== by 0x6E9E9E5: QTreeView::indexRowSizeHint(QModelIndex const&) const (in /usr/lib/libQt5Widgets.so.5.10.0) ==32711== by 0x6E9F39E: QTreeViewPrivate::layout(int, bool, bool) (in /usr/lib/libQt5Widgets.so.5.10.0) ==32711== by 0x6EA759F: QTreeView::doItemsLayout() (in /usr/lib/libQt5Widgets.so.5.10.0) ==32711== Address 0x9 is not stack'd, malloc'd or (recently) free'd ==32711== ==32711== ==32711== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==32711== Access not within mapped region at address 0x9 ==32711== at 0x16B8A4: (anonymous namespace)::qbytearray_t::operator QByteArray() const (Bindings.cpp:70) ==32711== by 0x16B8F4: (anonymous namespace)::set_qbytearray(QByteArray*, (anonymous namespace)::qbytearray_t*) (Bindings.cpp:75) ==32711== by 0x17C7CF: file_system_tree_data_file_icon (interface.rs:743) ==32711== by 0x16C6B5: FileSystemTree::fileIcon(QModelIndex const&) const (Bindings.cpp:387) ==32711== by 0x16CC59: FileSystemTree::data(QModelIndex const&, int) const (Bindings.cpp:439) ==32711== by 0x7CFD528: QSortFilterProxyModel::data(QModelIndex const&, int) const (in /usr/lib/libQt5Core.so.5.10.0) ==32711== by 0x17920A: SortedModel::data(QModelIndex const&, int) const (SortedModel.h:33) ==32711== by 0x6E5A529: QStyledItemDelegate::initStyleOption(QStyleOptionViewItem*, QModelIndex const&) const (in /usr/lib/libQt5Widgets.so.5.10.0) ==32711== by 0x6E59A96: QStyledItemDelegate::sizeHint(QStyleOptionViewItem const&, QModelIndex const&) const (in /usr/lib/libQt5Widgets.so.5.10.0) ==32711== by 0x6E9E9E5: QTreeView::indexRowSizeHint(QModelIndex const&) const (in /usr/lib/libQt5Widgets.so.5.10.0) ==32711== by 0x6E9F39E: QTreeViewPrivate::layout(int, bool, bool) (in /usr/lib/libQt5Widgets.so.5.10.0) ==32711== by 0x6EA759F: QTreeView::doItemsLayout() (in /usr/lib/libQt5Widgets.so.5.10.0) ==32711== If you believe this happened as a result of a stack ==32711== overflow in your program's main thread (unlikely but ==32711== possible), you can try to increase the size of the ==32711== main thread stack using the --main-stacksize= flag. ==32711== The main thread stack size used in this run was 8388608. ==32711== ==32711== HEAP SUMMARY: ==32711== in use at exit: 3,819,810 bytes in 36,186 blocks ==32711== total heap usage: 267,641 allocs, 231,455 frees, 23,142,477 bytes allocated ==32711== ==32711== LEAK SUMMARY: ==32711== definitely lost: 0 bytes in 0 blocks ==32711== indirectly lost: 0 bytes in 0 blocks ==32711== possibly lost: 19,146 bytes in 227 blocks ==32711== still reachable: 3,718,136 bytes in 35,286 blocks ==32711== of which reachable via heuristic: ==32711== length64 : 4,872 bytes in 81 blocks ==32711== newarray : 2,096 bytes in 51 blocks ==32711== suppressed: 0 bytes in 0 blocks ==32711== Rerun with --leak-check=full to see details of leaked memory ==32711== ==32711== For counts of detected and suppressed errors, rerun with: -v ==32711== Use --track-origins=yes to see where uninitialised values come from ==32711== ERROR SUMMARY: 7 errors from 3 contexts (suppressed: 0 from 0) [1] 32711 segmentation fault (core dumped) valgrind ./Demo valgrind ./Demo 16,23s user 0,65s system 84% cpu 20,076 total I have the same issue on Arch. The issue appears to be stem from a mismatch of the C++ and Rust interfaces:
In Rust (interface.rs), simple_message_get takes this type:
set: fn(*mut c_void, QString),
while in C++ (Bindings.cpp), it passes this type in:
typedef void (*qstring_set)(QString*, qstring_t*);
(Pass by value from Rust where C++ expects a pointer for the last param to `set`).
Created attachment 111195 [details]
Patch to fix issue running the demo on Arch Linux
Following on from jlode90's remark; I made some tweaks to get the demo working again on arch linux.
(In reply to illis+kde from comment #8) > Created attachment 111195 [details] > Patch to fix issue running the demo on Arch Linux > > Following on from jlode90's remark; I made some tweaks to get the demo > working again on arch linux. The patch works for me. Thanks. @illis+kde the patch looks good. Please add it to master. (In reply to Jos van den Oever from comment #10) > @illis+kde the patch looks good. Please add it to master. Have added a diff to phabricator, with a review tag. Pretty new to the phabricator/kde submission flow; so I'm not sure what else I need to do here to get it merged in to master. https://phabricator.kde.org/D11078 Cheers. I've built on the patch by illis. This is work in progress because it still crashes in tests. https://phabricator.kde.org/D11232 https://phabricator.kde.org/D11232 should work as a fix for this bug. Created attachment 111390 [details] valgrind_log_testing_#D11232 (In reply to Jos van den Oever from comment #13) > https://phabricator.kde.org/D11232 should work as a fix for this bug. I just tested the patch, and it still segfaults at set_qbytearray. Have attached a valgrind log. Still makes no difference for me if I launch/build in docker or not -- still havent worked out that one yet. The valgrind log is basically the same (apart from some pathing and the version of qt) if I build/launch in docker. Let me know if there is any other information that I could provide that could be useful. That is very disappointing. What would be the quickest way for me to replicate your setup in a VM? (In reply to Jos van den Oever from comment #15) > That is very disappointing. What would be the quickest way for me to > replicate your setup in a VM? I did test in an Antegros install -> same bug. Might be slightly easier then installing ArchLinux (Antegros has a GUI installer, that gets you into a X session alot quicker). https://antergos.com/try-it/ I quickly installed ubuntu into a VM, and your latest patch seems to work perfectly fine there. Got as far as setting breakpoints on Bindings.cpp:77 (with your latest patch). on Arch: (gdb) p val $5 = ((anonymous namespace)::qbytearray_t *) 0x1 on Ubuntu: (gdb) p val $9 = ((anonymous namespace)::qbytearray_t *) 0x7fffffffd020 (In reply to Jos van den Oever from comment #15) > That is very disappointing. What would be the quickest way for me to > replicate your setup in a VM? I did test in an Antegros install -> same bug. Might be slightly easier then installing ArchLinux (Antegros has a GUI installer, that gets you into a X session alot quicker). https://antergos.com/try-it/ This should hopefully get you most of your dependencies to build: pacman -S cargo git cmake qt5-base qt5-svg qt5-quickcontrols qt5-quickcontrols2 qt5-charts gdb valgrind I quickly installed ubuntu into a VM, and your latest patch seems to work perfectly fine there. Got as far as setting breakpoints on Bindings.cpp:77 (with your latest patch). on Arch: (gdb) p val $5 = ((anonymous namespace)::qbytearray_t *) 0x1 on Ubuntu: (gdb) p val $9 = ((anonymous namespace)::qbytearray_t *) 0x7fffffffd020 Ok. I managed to dial down the problem a bit more - you wont have to install a VM to reproduce :) Compiling with rustc 1.24.1 - crash. Compiling with rustc 1.22.1 - works fine. I haven't tried inbetween versions to dial down which rust change causes the regression yet. To reproduce, I think should just be able to: `cd demo/rust` `rustup override set 1.24.1` - then compile/run demo as usual Found why docker wasn't producing working binaries for me - I needed to clear out the demo/rust/target directory before rebuilding in docker :/ I can reproduce this error in a VirtualBox with Arch and rustc 1.25. This should be fixed as of 57d557378ee629496b4a6afc58022f0677cdff06. I've tested Demo, qt_widget and qt_quick in Arch. |