Summary: | xv crashed at _xcb_map_remove (list=0x828d9c0, key=2818) at xcb_list.c:89 | ||
---|---|---|---|
Product: | XCB | Reporter: | Martin Mokrejs <mmokrejs> |
Component: | Library | Assignee: | xcb mailing list dummy <xcb> |
Status: | RESOLVED MOVED | QA Contact: | xcb mailing list dummy <xcb> |
Severity: | normal | ||
Priority: | medium | ||
Version: | unspecified | ||
Hardware: | x86 (IA32) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Martin Mokrejs
2011-04-30 10:09:31 UTC
If the stack trace is accurate (and it might not be, due to compiler optimization) then the only way that line could have failed is due to *cur pointing some wild place. Would you try "p *cur" and "p **cur"? If you can reproduce the bug, running xv under valgrind may give more useful information. (gdb) p *cur $1 = (node *) 0x74697720 (gdb) p **cur Cannot access memory at address 0x74697720 (gdb) I tried again but got a different stacktrace (filed on Gentoo as http://bugs.gentoo.org/show_bug.cgi?id=365765) Regarding valgrind ... $ valgrind xv ../file.png ==2688== Memcheck, a memory error detector ==2688== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==2688== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==2688== Command: xv ../file.png ==2688== ==2688== Invalid read of size 8 ==2688== at 0x4391FE9: __strncmp_ssse3 (strcmp-ssse3.S:911) ==2688== by 0x43FD0B8: XauGetBestAuthByAddr (AuGetBest.c:154) ==2688== by 0x43DE7BA: get_authptr (xcb_auth.c:143) ==2688== by 0x43DEA09: _xcb_get_auth_info (xcb_auth.c:314) ==2688== by 0x43DE390: xcb_connect_to_display_with_auth_info (xcb_util.c:424) ==2688== by 0x43DE6B2: xcb_connect (xcb_util.c:395) ==2688== by 0x40ADDF4: _XConnectXCB (xcb_disp.c:78) ==2688== by 0x409E73D: XOpenDisplay (OpenDis.c:129) ==2688== by 0x80532A6: parseResources (xv.c:1243) ==2688== by 0x8054AC9: main (xv.c:375) ==2688== Address 0x44090e0 is 16 bytes inside a block of size 18 alloc'd ==2688== at 0x40256DD: malloc (vg_replace_malloc.c:195) ==2688== by 0x43FD40D: read_counted_string (AuRead.c:58) ==2688== by 0x43FD4FF: XauReadAuth (AuRead.c:86) ==2688== by 0x43FD003: XauGetBestAuthByAddr (AuGetBest.c:116) ==2688== by 0x43DE7BA: get_authptr (xcb_auth.c:143) ==2688== by 0x43DEA09: _xcb_get_auth_info (xcb_auth.c:314) ==2688== by 0x43DE390: xcb_connect_to_display_with_auth_info (xcb_util.c:424) ==2688== by 0x43DE6B2: xcb_connect (xcb_util.c:395) ==2688== by 0x40ADDF4: _XConnectXCB (xcb_disp.c:78) ==2688== by 0x409E73D: XOpenDisplay (OpenDis.c:129) ==2688== by 0x80532A6: parseResources (xv.c:1243) ==2688== by 0x8054AC9: main (xv.c:375) ==2688== vex x86->IR: unhandled instruction bytes: 0x66 0x66 0x66 0x2E ==2688== valgrind: Unrecognised instruction at address 0x4392c64. ==2688== Your program just tried to execute an instruction that Valgrind ==2688== did not recognise. There are two possible reasons for this. ==2688== 1. Your program has a bug and erroneously jumped to a non-code ==2688== location. If you are running Memcheck and you just saw a ==2688== warning about a bad jump, it's probably your program's fault. ==2688== 2. The instruction is legitimate but Valgrind doesn't handle it, ==2688== i.e. it's Valgrind's fault. If you think this is the case or ==2688== you are not sure, please let us know and we'll try to fix it. ==2688== Either way, Valgrind will now raise a SIGILL signal which will ==2688== probably kill your program. ==2688== ==2688== Process terminating with default action of signal 4 (SIGILL): dumping core ==2688== Illegal opcode at address 0x4392C64 ==2688== at 0x4392C64: __strncmp_ssse3 (strcmp-ssse3.S:1877) ==2688== by 0x43FD0B8: XauGetBestAuthByAddr (AuGetBest.c:154) ==2688== by 0x43DE7BA: get_authptr (xcb_auth.c:143) ==2688== by 0x43DEA09: _xcb_get_auth_info (xcb_auth.c:314) ==2688== by 0x43DE390: xcb_connect_to_display_with_auth_info (xcb_util.c:424) ==2688== by 0x43DE6B2: xcb_connect (xcb_util.c:395) ==2688== by 0x40ADDF4: _XConnectXCB (xcb_disp.c:78) ==2688== by 0x409E73D: XOpenDisplay (OpenDis.c:129) ==2688== by 0x80532A6: parseResources (xv.c:1243) ==2688== by 0x8054AC9: main (xv.c:375) ==2688== ==2688== HEAP SUMMARY: ==2688== in use at exit: 3,019 bytes in 13 blocks ==2688== total heap usage: 25 allocs, 12 frees, 3,192 bytes allocated ==2688== ==2688== LEAK SUMMARY: ==2688== definitely lost: 0 bytes in 0 blocks ==2688== indirectly lost: 0 bytes in 0 blocks ==2688== possibly lost: 0 bytes in 0 blocks ==2688== still reachable: 3,019 bytes in 13 blocks ==2688== suppressed: 0 bytes in 0 blocks ==2688== Rerun with --leak-check=full to see details of leaked memory ==2688== ==2688== For counts of detected and suppressed errors, rerun with: -v ==2688== ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 7 from 7) Illegal instruction $ (In reply to comment #1) > If the stack trace is accurate (and it might not be, due to compiler > optimization) then the only way that line could have failed is due to *cur BTW, I compile on this Gentoo box as follows: CFLAGS="-O2 -march=pentium4 -mmmx -msse -msse2 -pipe -fno-strict-aliasing -ggdb" -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/lib/libxcb/issues/28. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.