You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As far as I can tell, the input lighthouse is receiving is ordinary: it contains items like {%Iwords_with_underscores.png words_with_underscores|words_with_underscores}, no special characters like $&. Some or most of the images referred to do not exist yet, but Lighthouse normally handles that condition okay.
Frustratingly, it does not occur every time that the exact same sequence of keypresses is input. I'm considering looking into running it with valgrind to see if that reliably detects the problem.
==20471== Memcheck, a memory error detector
==20471== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==20471== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==20471== Command: lighthouse
==20471==
==20471== Syscall param writev(vector[...]) points to uninitialised byte(s)
==20471== at 0x5A96BDD: ??? (in /usr/lib/libc-2.21.so)
==20471== by 0x4E40CCA: ??? (in /usr/lib/libxcb.so.1.1.0)
==20471== by 0x4E410C0: ??? (in /usr/lib/libxcb.so.1.1.0)
==20471== by 0x4E417E6: ??? (in /usr/lib/libxcb.so.1.1.0)
==20471== by 0x4E419B3: xcb_flush (in /usr/lib/libxcb.so.1.1.0)
==20471== by 0x10B920: ??? (in /usr/bin/lighthouse)
==20471== by 0x59D67FF: (below main) (in /usr/lib/libc-2.21.so)
==20471== Address 0xc50301d is 5,245 bytes inside a block of size 21,144 alloc'd
==20471== at 0x4C2C080: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==20471== by 0x4E4066B: xcb_connect_to_fd (in /usr/lib/libxcb.so.1.1.0)
==20471== by 0x4E44120: xcb_connect_to_display_with_auth_info (in /usr/lib/libxcb.so.1.1.0)
==20471== by 0x10AB94: ??? (in /usr/bin/lighthouse)
==20471== by 0x59D67FF: (below main) (in /usr/lib/libc-2.21.so)
==20471==
[Lighthouse stderr messages complaining 'cannot open image file xyz.png' removed]
==20471==
==20471== HEAP SUMMARY:
==20471== in use at exit: 698,913 bytes in 19,018 blocks
==20471== total heap usage: 34,185 allocs, 15,167 frees, 132,211,385 bytes allocated
==20471==
==20471== LEAK SUMMARY:
==20471== definitely lost: 6,324 bytes in 319 blocks
==20471== indirectly lost: 31,285 bytes in 324 blocks
==20471== possibly lost: 37,150 bytes in 46 blocks
==20471== still reachable: 624,154 bytes in 18,329 blocks
==20471== suppressed: 0 bytes in 0 blocks
==20471== Rerun with --leak-check=full to see details of leaked memory
==20471==
==20471== For counts of detected and suppressed errors, rerun with: -v
==20471== Use --track-origins=yes to see where uninitialised values come from
==20471== ERROR SUMMARY: 175 errors from 1 contexts (suppressed: 0 from 0)
Note that the writev error is not printed immediately, rather it is printed after the first keypress.
The text was updated successfully, but these errors were encountered:
@0ion9 are you running the find.py script? I ran into this problem too and it seems like it doesn't happen when I remove the find.py script. Some debugging makes me suspect it has to do with these lines;
@dzan : Nope, using my own cmd; though mine is written in python too.
That line you quote is a bug waiting to happen, as are any calls to subprocess.* functions using string interpolation in combination with shell=True. Passing a list, with shell=False, like you can see in the below paragraph, is way less likely to blow up unexpectedly when you type characters that are special to the shell.
That said, my cmd does also invoke a command using check_output: _ = check_output(['notify-send', 'diff=%d (%s)' % (diff, diffdesc)]). This is a debugging information message.
I never get any 'broken pipe' errors from it though.
This is kind of a vague bug report, but I've been experiencing this with some consistency:
As far as I can tell, the input lighthouse is receiving is ordinary: it contains items like
{%Iwords_with_underscores.png words_with_underscores|words_with_underscores}
, no special characters like $&. Some or most of the images referred to do not exist yet, but Lighthouse normally handles that condition okay.Frustratingly, it does not occur every time that the exact same sequence of keypresses is input. I'm considering looking into running it with valgrind to see if that reliably detects the problem.
Lighthouse version: Current git head as of this writing
EDIT: valgrind output:
Note that the writev error is not printed immediately, rather it is printed after the first keypress.
The text was updated successfully, but these errors were encountered: