Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash after deleting characters #35

Open
0ion9 opened this issue Feb 28, 2015 · 2 comments
Open

Crash after deleting characters #35

0ion9 opened this issue Feb 28, 2015 · 2 comments

Comments

@0ion9
Copy link
Collaborator

0ion9 commented Feb 28, 2015

This is kind of a vague bug report, but I've been experiencing this with some consistency:

  1. Type a short string, candidates show, no crash
  2. Type an additional character, no candidates are available, no crash
  3. Delete additional character
  4. Lighthouse immediately crashes, segmentation fault.

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:

==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.

@dzan
Copy link
Contributor

dzan commented Dec 20, 2015

@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;

        find_array = subprocess.check_output('find %s %s' % (user, command),
                                             shell=True,
                                             executable='/bin/sh').split('\n')

Resulting in;

grep: write error: Broken pipe
grep: write error
find: `standard output': Broken pipe
find: write error
find: `standard output': Broken pipe
find: write error

Seems like this ends up crashing it all (not sure, just a guess).

@0ion9
Copy link
Collaborator Author

0ion9 commented Dec 21, 2015

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants