Albert Zeyer

> make sure the sisyphus had enough time to handle everything else before starting the clean up processes. Yes, this would probably solve the problem at startup time, but the...

> introduce a separate database to keep track of the last know states Yeah see #168. > Is the file system currently slower than usual? No, it's just slow as...

Hm, my current situation is that most of the jobs are already finished. So in that case, such a DB would speed it up a lot, if it can skip...

> Do you have two managers running simultaneously that race to create the same work folder? No.

The relevant stack trace (demangled): ``` PROGRAM DEFECTIVE (TERMINATED BY SIGNAL): Segmentation fault Creating stack trace (innermost first): #2 /lib/x86_64-linux-gnu/libc.so.6( 0x42520) [0x7fc2485f8520] #3 /lib/x86_64-linux-gnu/libc.so.6(pthread_kill 0x12c) [0x7fc24864c9fc] #4 /lib/x86_64-linux-gnu/libc.so.6(raise 0x16) [0x7fc2485f8476]...

It would be helpful to have a RASR compiled with debugging information, and then to run this in GDB, such that you don't just get the crash, but that you...

> > Specifically interesting is maybe `Am::TransitionModel::apply`. > > Isn't the traceback showing `Ftl::TrimAutomaton::getState(unsigned int) ` as the last function call? Yes but my assumption is that the `this` pointer...

`TrimAutomaton` has this `getState`: ```cpp virtual _ConstStateRef getState(Fsa::StateId s) const { if (accAndCoacc_[s]) { _ConstStateRef _s = Precursor::fsa_->getState(s); _State* sp = new _State(_s->id(), _s->tags(), _s->weight_); for (typename _State::const_iterator a =...

But we should also avoid that it crashes in that case. At least it should raise a C++ exception, or use our `criticalError()`, `require` or whatever. At that place where...

I think #6 fixes this. I tried the code from the fork, however, I'm unable to come up with a valid modeline to use Python syntax. I'm trying this: #...