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
The job produced no error. The tail of the log was:
[2017-07-28T17:28:17.972Z] INFO: medusa-agent/63636 on 9c1566b9-9f41-47f5-a108-d0ed79de08a6: started child process
[2017-07-28T19:29:19.402Z] INFO: medusa-agent/63579 on 9c1566b9-9f41-47f5-a108-d0ed79de08a6: connection ended (code=NORMAL, reason="remote connection reset")
I think that's consistent with mlogin on the client having blown an assertion in the middle of the session, but that means we've got very little to go on. I can't figure out where this assertion (or even its message) might come from. I don't see obvious candidates in bin/mlogin or lib/client.js's Medusa-related code. And it doesn't seem reproducible: Patrick and I were both able to re-run thoth debug on that dump and run ::stacks, but it completed normally (which I think rules out something about the output of ::stacks). I've also tried dropping fatal signals like SIGABRT onto mdb from within the job, but that causes the session to terminate (mostly) gracefully.
Ideally, we'd like to catch this with DEBUG=1 in the environment or --abort-on-uncaught-exception enabled.
The text was updated successfully, but these errors were encountered:
davepacheco
changed the title
mlogin crashed: AssertionError value
mlogin crashed: "AssertionError: value"
Jul 28, 2017
@pfmooney was using
thoth debug
to look at a kernel crash dump and ran into:The job looks like it was this one (account uuid elided):
The job produced no error. The tail of the log was:
I think that's consistent with mlogin on the client having blown an assertion in the middle of the session, but that means we've got very little to go on. I can't figure out where this assertion (or even its message) might come from. I don't see obvious candidates in bin/mlogin or lib/client.js's Medusa-related code. And it doesn't seem reproducible: Patrick and I were both able to re-run
thoth debug
on that dump and run::stacks
, but it completed normally (which I think rules out something about the output of ::stacks). I've also tried dropping fatal signals like SIGABRT onto mdb from within the job, but that causes the session to terminate (mostly) gracefully.Ideally, we'd like to catch this with DEBUG=1 in the environment or --abort-on-uncaught-exception enabled.
The text was updated successfully, but these errors were encountered: