agent can't create stacktrace #2105

Closed
Gibheer opened this Issue Dec 21, 2012 · 3 comments

Comments

Projects
None yet
2 participants
@Gibheer
Contributor

Gibheer commented Dec 21, 2012

When running a script which creates threads, the agent does not seem to be able to get a stacktrace.

Steps to reproduce

  • save the file
  • gem install rack-cache
  • rbx -Xagent.start file.rb
  • in a new console, connect to the instance with rbx console
  • stacktrace

What I see:
The command just hangs there and the process is still running. It looks like it never gets the chance to actually do the snapshot.

What I expect to see:
A snapshot of the stacktraces of all threads.

As a sidenode, I also had the problem of the console not being able to connect to an agent enabled process. Could be both the same problem.

@dbussink

This comment has been minimized.

Show comment Hide comment
@dbussink

dbussink Dec 21, 2012

Member

What if you type "get system.backtrace", since stacktrace isn't a command afaik. We should improve the error handling though so it doesn't hang but gives back something useful.

Member

dbussink commented Dec 21, 2012

What if you type "get system.backtrace", since stacktrace isn't a command afaik. We should improve the error handling though so it doesn't hang but gives back something useful.

@Gibheer

This comment has been minimized.

Show comment Hide comment
@Gibheer

Gibheer Dec 21, 2012

Contributor

You are right, stacktrace is wrong. With backtrace it returns and prints everything.

thank you very much :D

Should we leave that ticket open for fixing the error handling or should I create a new one?

Contributor

Gibheer commented Dec 21, 2012

You are right, stacktrace is wrong. With backtrace it returns and prints everything.

thank you very much :D

Should we leave that ticket open for fixing the error handling or should I create a new one?

@dbussink

This comment has been minimized.

Show comment Hide comment
@dbussink

dbussink Dec 28, 2012

Member

A new one which describes the actual problem is better, so closing this one :).

Member

dbussink commented Dec 28, 2012

A new one which describes the actual problem is better, so closing this one :).

@dbussink dbussink closed this Dec 28, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment