Fix exception tracebacks

[tuetschek]

When Alex crashes, there's usually no detailed information about the exception in the logs.

If an exception occurs in DM, it is caught here and passed on to the logs here. The code should print a traceback, but this tends to be None. Anyone knows why and/or how to solve this?

[ticcky]

I think I figured out the problem. It is this code: https://github.com/UFAL-DSG/alex/blob/master/alex/utils/mproc.py#L84-L111 Which runs the exception handler in a different thread, therefore looses the stack and traceback cannot print it.

Filip says:
"The logging used to be synchronous. The issue is that logging to a NFS file system causes delays (when NFS is under a load writes can wait up to 1 second). This async mess is just was hot fix to existing problem of synchronous logging in original processes.

Therefore, there is a need for a separate logging process. Ideally, equivalent to other processes such as VAD, ASR, SLU, ...."

=> Let's implement the logging process.

[tuetschek]

Well, actually that would be the solution to messed-up logs, not exception tracebacks ;-). This means we must implement the logging process and move traceback handling to the other processes (the ready traceback must be passed to the logger, the logger won't be able to create it by itself).

[jurcicek]

When we talk about processes in Alex,

I think that there should be one more, for sending messages between
processes.

Now it is implemented using pipes, the connections structure is roughly
everyone with everyone. It seems to me that a star like structure would be
more appropriate.

Best regards,
Filip Jurcicek

---

Work tel. (CZ): +420221914402
Personal tel. (CZ): +420777805048
Skype: bozskyfilip

http://ufal.mff.cuni.cz/filip-jurcicek
http://ufal.mff.cuni.cz/grants

On 28 October 2014 13:15, Lukas Zilka [email protected] wrote:

I think I figured out the problem. It is this code:
https://github.com/UFAL-DSG/alex/blob/master/alex/utils/mproc.py#L84-L111
Which runs the exception handler in a different thread, therefore looses
the stack and traceback cannot print it.

Filip says:
"The logging used to be synchronous. The issue is that logging to a NFS
file system causes delays (when NFS is under a load writes can wait up to 1
second). This async mess is just was hot fix to existing problem of
synchronous logging in original processes.

Therefore, there is a need for a separate logging process. Ideally,
equivalent to other processes such as VAD, ASR, SLU, ...."

=> Let's implement the logging process.

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

[tuetschek]

I don't know... wouldn't that create a bottleneck?