one that is really cosmetic and justs avoid Valgrind complaints (the "random" patch)
one that could produce some issues, as some fields of the model are not set properly, but I've never observed an actual bug due to this, so mostly to please Valgrind
one that is an actual problem that leads to crashes in production, especially when the number of threads is high with respect to number of CPU. This scenario is not unreasonable, it improves the stability a lot to have many threads in the presence of counter examples, so having e.g. 8 threads on a 2 CPU machine is still a good idea according to my experiments. With a single thread, you might get a run that last 10 secs, but another run with the same settings can time out ; with many threads the chance of this happening is reduced.
For the dlopen patch, I used a simple static version of pthread_mutex, but it does not match the code base so well, in the sense that I could not find similar code in ltsmin. There is also no special case to deal with "fork" scenario, although I believe the dlopen need not be protected in that case. The mutex does not really hurt anything however, and the contention only happens once at options parse time, so should be overall negligible.
So three relativeley small patches,
For the dlopen patch, I used a simple static version of pthread_mutex, but it does not match the code base so well, in the sense that I could not find similar code in ltsmin. There is also no special case to deal with "fork" scenario, although I believe the dlopen need not be protected in that case. The mutex does not really hurt anything however, and the contention only happens once at options parse time, so should be overall negligible.