syn icon indicating copy to clipboard operation
syn copied to clipboard

Investigate CI crashes

Open ysbaddaden opened this issue 2 years ago • 2 comments

If you needed proof that Syn isn't production-ready :see_no_evil:

Note: they're both related to Syn::Future (Syn::Core::Future) & may be related to the recent Syn::Core::WaitList::Iterator that hasn't been tested much and maybe just plain wrong.

One segfault: https://github.com/ysbaddaden/syn/actions/runs/4593492258/jobs/8111470592

Invalid memory access (signal 11) at address 0x78
[0x562bdd7370a6] *Exception::CallStack::print_backtrace:Nil +118 in /home/runner/.cache/crystal/crystal-run-future_test.tmp
[0x562bdd722816] ~procProc(Int32, Pointer(LibC::SiginfoT), Pointer(Void), Nil) +310 in /home/runner/.cache/crystal/crystal-run-future_test.tmp
[0x7fe740fa9420] ?? +140631204336672 in /lib/x86_64-linux-gnu/libpthread.so.0
[0x562bdd7fcda1] *Syn::Core::WaitList#delete<Fiber>:Nil +241 in /home/runner/.cache/crystal/crystal-run-future_test.tmp
[0x562bdd7fd61f] *Syn::Core::ConditionVariable#wait<Nil, Time::Span>:Bool +255 in /home/runner/.cache/crystal/crystal-run-future_test.tmp
[0x562bdd80c159] *Syn::Core::Future(Int32) +105 in /home/runner/.cache/crystal/crystal-run-future_test.tmp
[0x562bdd80bea9] *Syn::Future(Int32) +57 in /home/runner/.cache/crystal/crystal-run-future_test.tmp
[0x562bdd7256e4] ~procProc(Nil) +84 in /home/runner/.cache/crystal/crystal-run-future_test.tmp
[0x562bdd77e6e2] *Fiber#run:(IO::FileDescriptor | Nil) +114 in /home/runner/.cache/crystal/crystal-run-future_test.tmp
[0x562bdd722336] ~proc2Proc(Fiber, (IO::FileDescriptor | Nil)) +6 in /home/runner/.cache/crystal/crystal-run-future_test.tmp
[0x0] ???

One failure: https://github.com/ysbaddaden/syn/actions/runs/4590432460/jobs/8105974390

Syn::FutureTest#test_get_timeout [test/future_test.cr:65]:
Expected 980 but got nil

They both occurred in Syn::FutureTest#test_get_timeout.

ysbaddaden avatar Apr 03 '23 08:04 ysbaddaden

I can't reproduce either on local. That would have been too easy.

In the segfault case, the timeout triggered (ConditionVariable#wait only calls WaitList#delete when timeout was reached). Maybe the spawned fibers are continuing to write the result and counter locals after the function returns, since I don't verify that they're all done (oops).

In the failure case, result never got to become an actual value.

ysbaddaden avatar Apr 03 '23 08:04 ysbaddaden

I distinguished multiple tests in 147ed26 to have only one timeout per test, to better understand what's happening.

ysbaddaden avatar Apr 03 '23 08:04 ysbaddaden