Odd Program Failure about includeos HOT 12 CLOSED

Interestingly enough...it appears the TKILL error is super random. Sometimes it does it, some times it doesn't. Sadly, specifying SMP and adequate memory was not the fix.

from includeos.

I don't know - thats a weird crash. You could always give it more RAM, just change the "mem" value in vm.json. Also, try updating your branch to my latest simpler_clone branch. No need to run conan for anything.

from includeos.

I will do that and let you know of the results. I think I am on the latest simpler_clone branch, but I will verify that.

from includeos.

I am STUMPED. I am able to run the program everywhere else without any problem but for some reason I get the error above when I run it inside IncludeOS. I made sure qemu had what it needed so I am perplexed.

from includeos.

It's probably a bug in IncludeOS then, it's calling TKILL on an invalid tid which is never good. I don't have any things for you to try, but can you show your code? Do you use cooperative threads? Are you using SMP for multiprocessing?

from includeos.

The code I am using is located at github.com/ProfessorWest/splash2-posix and I am using radix in the kernel folder.

Code isn't pretty, we just smashed everything into one file for simplicity. Also, no cooperative threads are being used and I updated src/musl/futex.cpp as you recommended to stabilize multi-processing.

from includeos.

I'll take a look at this when I have some time. Definitely interesting test. It looks like it uses all kinds of pthread stuff which might not be tested yet.

from includeos.

Awesome! Do let me know if your findings!

from includeos.

I fixed the problem. So inside of vm.json, I had to give more CPUs and had to make sure I gave enough memory too!

from includeos.

Good to hear! Yes, there is no SMP without -smp XXX to Qemu.

from includeos.

I will be attempting to bare metal boot it next with the benchmark to see the speed up from qemu -> bare metal

from includeos.

Yep, that's a known problem. I've been trying to fix it for a while but I'm having a break now. There is clearly some sharing in the thread code, so the only multiprocessing-safe interface is the SMP interface itself. Threads do work, but only if they can start properly. If you use a threadpool and create the threads on startup, then as long as it doesn't crash at the start, it will remain up forever.

So, the problem is during thread creation. I don't have any ideas atm.

from includeos.