Interrupted System Call

[snare]

Interrupted System Call

[richo]

I've reprod this (independantly, I actually thought I broke something).

I'm digging into this atm, however it's definitely a regression, so in the very short term you can probably wind back about ~a month of git history and have this bug go away.

[richo]

Separately, you should not have the init line in your .gdbinit.

You should load voltron, load the inferior, the voltron init

[snare]

No, it’s fine to voltron init in your gdbinit. Doing it after loading a target is only required for LLDB due to the way it manages the stop hooks (you add stop hooks on a per-target basis).

Thanks for looking into it Richo.

On 15 Jan 2015, at 6:18 am, Richo Healey [email protected] wrote:

Separately, you should not have the init line in your .gdbinit.

You should load voltron, load the inferior, the voltron init

—
Reply to this email directly or view it on GitHub.

[richo]

Ah! my bad.

(Interestingly, sometimes this issue did not happen to me when I started
my inferior, and stepped through a few instructions before init'ing voltron
and attaching some views. I really doubt they're related, but it might be a
Thing You Could Do to get moving with it.

Will hopefully make time to dig into the underlying issue this week some
time, but nfi when.

On Wed, Jan 14, 2015 at 4:32 PM, snare [email protected] wrote:

No, it’s fine to voltron init in your gdbinit. Doing it after loading a
target is only required for LLDB due to the way it manages the stop hooks
(you add stop hooks on a per-target basis).

Thanks for looking into it Richo.

On 15 Jan 2015, at 6:18 am, Richo Healey [email protected]
wrote:

Separately, you should not have the init line in your .gdbinit.

You should load voltron, load the inferior, the voltron init

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#65 (comment).

[snare]

Didn't mean to close this. THANKS GITHUB. Let me know if this solves your problem, @theqlabs. Thanks!

[theqlabs]

Will test again this week, got a little busy. Will post back results. Thanks guys for digging into this! Been dying to use this tool.

[theqlabs]

Looks like it's still occurring, just pulled the newest commit and installed on a 32-bit Ubuntu 12.04 VM again:

Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 551, in __bootstrap_inner
    self.run()
  File "/usr/local/lib/python2.7/dist-packages/voltron-0.1-py2.7.egg/voltron/core.py", line 202, in run
    rfds, _, _ = select.select([serv, self.exit_pipe] + self.clients, [], [])
error: (4, 'Interrupted system call')

[theqlabs]

Ok, it looks like if I load the inferior first (as you suggested) and then source dbgentry.py and run voltron init, I don't seem to get the Interrupted System call exception.

And I also just got views working, this seems a little shaky but it's currently working (if I do it in the above order)

[theqlabs]

The first "ni" I take in GDB, I check the views and instead of refreshing I get: Failed getting registers: Exception getting registers from debugger: Couldn't get extended state status: No such process.

I will try to dig into this as I have time. Am I the only one having these issues?

[richo]

Wow, that's weird. I don't suppose you can bundle up a VM that does this for me to poke?

[richo]

Can you try the branch at https://github.com/richo/voltron/tree/debug/theqlabs ?

It'll most likely barf about a jillion messages into your console. It seems likely that something is leaking tons of signals (especially if they're batched) and causing the bug.

[theqlabs]

Sure, can do either. I can try the branch above first, if that doesn't work I'll bundle up the VM.

[snare]

@theqlabs re: you being the only one having the issue, I really only use this on OS X with LLDB and it kinda only gets tested on Linux/GDB when @richo has to do something on Linux.

There's a test suite which runs some tests against the GDB CLI but they're really unreliable at the moment so you have to run them a few times and only treat a failure that occurred every time as a true failure. I've been meaning to try to do something to make these more reliable, but that might also be a good starting point.

In general if you're having issues, enable debug_logging in your config (as per the configuration page). You'll get voltron_main.log and voltron_debugger.log created in your ~/.voltron dir, which are the log files for the views/clients and debugger respectively. These might be helpful in finding the issues (either for us or you).

I guess I should probably write a "troubleshooting" section for the wiki :)

[snare]

GDB tests should be more reliable now. Waiting for the debugger to restart sucks.

[snare]

BTW you'll also get a tests/test.log when you run the tests.

[snare]

Which you do with nosetests -sv in the root of the repo, or nosetests -sv tests/gdb_cli_tests.py for just the GDB tests.

[snare]

This will probably be resolved now since the core comms has been completely rewritten and is not using the sockets code any more