libossia icon indicating copy to clipboard operation
libossia copied to clipboard

Published 20 hours ago • verified publisher icon ossia

osc to parameter to jitter (GL3) : crash Max

Open matcham opened this issue 2 years ago • 12 comments

I know that some of your are going to hate me for posting this !!

Here is a simple patch demonstrating some priority/threading/... issues with messages coming from osc.

this crash Max 8.2.2 / 8.3 on Mac and Windows, ONLY when using GL3 with Max default gl2 settings, no problem... (install gl3 from package manager, and enable it in Max preferences) (That only means that with openGL3, Max is even more sensitive to this kind of thing ! But gl3 is not the only culprit, because the same patch using native osc (udpreceive) objects doesn't crash... )

crash with or without overdrive enabled.

I tried with different ossia-max version, some very old (2021..) , up the the latest nighty build : all versions : same crash

I tried to create a file ossia-max.conf containing { "default_deferlow": true}

On Mac: /Users//Library/Application Support/ossia-max/ossia-max.conf

On Win: c:\Users\Application Data\Roaming\ossia-max\ossia-max.conf

doesn't solve the issue.

adding a deferlow after the ossia.parameter DOES fix it.

so I'm pretty confident that this is a thread / priority / queued ... message thing.

I can't make Max crash in GL3 with native objects, so there is something "special" happening when messages come from ossia parameters...


----------begin_max5_patcher----------
2543.3oc4akziiiaE9b0.8+AAi4nGOjT64TkbI.ASNkSAEZHPawxVcKKJHQU
KYP9uGtHIKpU5kxcmdlFisJRYR99d6OR9Ge9SOrZK8MR4Jq+h0SVO7veva4A
YahVdnogGVcD+1tTbo7EWkQdkt8qqVW2Gi7FS1dJEGuEmsusGZEKkvXumSTS
vJYuVeoo+rpiIY72PNrvlVShkiFeJ9Uu1gJGy1cHIaeTAYGSMZHn2FvZKaj3
SOGwmH9yZCuZEnFeYq+2O+Iw27uVaL8VllDSJZWJOyoSFefyqXZq6ATaGJsL
4+HaExWksTTA9HgQJhHY3soxtAFiLvf4fFGaWAb.skfBT9rC3i.a1QOdjjwF
JLfSyOfWYN83NK8DJoDXfjK6FHIqYnGvESOblKenlVBd05ARwyxHelVbDKoB
OywBaS3sARHwEtjbO5hwhijxR7dxPd6u8BWgfFkmhemT7aRNs0u.WYhhfFwi
Fg3cMf1Q.ekHM7iSoeJibUw4kjrXqT5Nb5AZIyJ...lKnaBuEUyhWl9.2dlK
4sbZIwhVtSiFC.5D5Uwj8AFXX2UwjC.2elLsrLAe9j5X7aGGCHUkcMG26Okl
a0UWdbwXvXhwl3ZF5nXgfEYg.sAiuPTjRCsvsiljRdgTTlPy5hzOrBmm2o8G
59iDPvWoxwJX8o1RxTsYepsBxKIMCA3Ty3BNgw3TUUgj0u5MuVtoXjn7vBxp
RNwYTLklklD8y39FJyw6TCffK01+I7JDTqoKwKeOId4n4giyg2y0G+FIVaQt
hlSxRxxKHbqRLLqOQrJl7LtJkE8LMi0FEBZy3uvy0qyw6UPJRp3uVjfSOQG6
KRhoYhEhNqQzdyT9jETYSyUiljuRFNereNWLiCPS0aImXqJ2hKDbtZutn1dY
TZpdem9kojmY08mmjk0GPYz7Y5sHY+g490ao7dON6vK6pLpJS0cDWJgEUheo
Gxyvoo0Zs8lg2vYI7fJHrDE+.AN0qJDjCk6Jnoo5zspqWFqqXt7+NxqIwrCx
ISS7f+CRxaDrVchsGmrmTx50HCuurWSkr2UrftsUssVSOhQNxM9v5+FbUmjR
V4A5qk0uYi3mFTbJ2EMM+t1C06X1X6mK99kbELQb9KFh3ztQF3JYk9XNvrqq
xOBDglJt+I8o7vI+JMlwtXLU2WyHdV2TPNRYDKsbDT5lIYjczpLll57jQhK+
+AD2xHo8RHomJqRnWWGX1dyij12UjTjssHHNK3pyQB0H7AtD9fToaW6leD+6
+fHn0p3oj0rdT.LVRMbqGq8swM24tZYQsK.FC7WDGU4uYqRT2KvDbD8c.GEg
5jNZnhmsZ6kntBVBGgJjy6LzVu8hi++jujS0OZAQSuuu9R5UeoYpwzYP6tKQ
61fPEUOU8llLU7aIsqWKJSqGkYBICqK0Yfe1FJ6ffSUip6hYsdk3PW1YeZzN
ZJsvBJ+2ubEdQQSgS.SwIeoDFT4N8GK+neMgsYe5Fooetk+LB2GZANqTH.EI
x5jYgrdjKhkEWKqwQyG6gtfo8V3LKrym8HtbZQxaWpOXjYgxXWGvma6tIbek
UEvrvwZJOoGsUbbA9UFUO4HIHRo45UwXJ7iyKDbSQMLpCYNNYmHeNbw6mqYC
yrOXZ3iJvFAjeIJ1o9pYWZR9AhHgaofBP2OnxqZKo0e8zKzbMHEyvc3IcYJp
IUKmx9ugH2zskzzJFgSYGTdoNjr6ajrxMGy0RRqoxUsUNYoW7aIYJb7H8kDh
nk9uUMNWACDki0y2q+KzHX.609NZFi6IMRT3DRWxe.80YLzZuird8eZ8kSMz
sWcshN06Qn5OUF6R4DwKLg9RIspXWifcS30V8jYhIkrjr15f8zoncDuo4psm
8hwwz0h8G9Rw1zkhyG9RoA3MfE8wiKPiAFgm6O5ECzzEC5ies.9AZsXLOBN6
ZoiQGYAHmxpyohZWEmP+WxpJG8OIYUcrq1TE7Ings64FpSkw6LoaEdH500n1
W2OFuqJFceANNgnhHRu21g8IKvFTnCDFvI6M1Paejm7I9Ctt7PWz.s5eHr4W
535DBPh22wC463JeJ.Y6ZKdBL1uEcZVAvP0bABC.Npm3MAWaAG7ayKn4zh1M
hXicnV2MAmTSXS5+XcWYnBNzLRYjEAQwYKIZoeMtbXKa9efOROhiNvCqHUDZ
AINhximUKMgE323c63qmNLFYP7fMRPETiI2CZA+7auSRSouNXTpKEwTxq5BU
.GnRz.xyGITJdA.HawSCiIa.UG.C7r8MfzaRG69nDswObN8nyQhVWS5bfq9Z
RdARYjtec4JPsjqlNjdR9m1ztmZ11Nc9Y2sETT2i97aQ30RZHJISrOqjKi2y
vamfuqwW77CcARD00M.pLMA7fBCcCjDIoji5pgBqbvPNeezmfFRZbphO0.IG
Z3SyQjM0pZbB8rYFHmIWwMqT2ZY1tOcKL.AMz.zARZtHIknT7VRp11FrfMzy
FMDkR5BPC2tZ02Caxesd2JA.Mz3lNGGcdAeNgmngR9AB29RYZ4GNhPIFFDvE
vgPFqgAV24i6FqQ.ahkz1JFiab8J82q8gNc22AqGO5KoGCjimCr9IenMx.Gr
yLMiYA7rlqd7uA1aJ4yfrRQZSQnGvOP5xLPDIoTMC55w8DbO4kpfI5okc8wo
qClq67wbwWu.mZP.0yMtK3e2PvsAItFLVUV3+VZE4brrOPaQjrhumizFiWaZ
HghltmFl6PMnepnF6eVnl+dAgjckhZpDwrE+mztD2rDx+6Dkf9ogRr+IfR92
xLkuRwq.dJeRkEedpOpvscCccbW14JR7l.Pv2ARF8mOR19OEjbQ1V5QZF8a3
jqhdkIIIBpSVUQ20F1zRw8NLJ+0ejE7Yl5lN6JoeAd.J5yQViHU0Hfs+oj7k
QtAkNNAtA0UQcwf97r8BPpRZviQWIVYG3G5eiqhp9VnRvE5Qu2YUiBkgw2kq
5HqYRHT6slOMEdjC8whQQL+9y7vDZhSXhMJtmbzMZIOV5R9cWjpzfCrCQxzY
pStY7bu5kc7uiE6Q+Wz2fdwg0+ChVJYEI4DcRY33f51..MEsLnPJPw9LTWhy
9Oc27ZWlbLWa6uusCOCmewUqRvss9c0AS3lgEMizogYk3RADGotGDQXFmmus
ho1IKsKGyYdF82mR2hS6cp5G8L72tht426Hw4c4UZQZr0iMmZn1WZzSS5RmM
H0EO97taVv4uyoxSBj6TGozQO72WBDIXrUsNvk+o5h3oNBNlbKztt6RLZYXv
1cxKxkfkF0d0Q7c2.L6tqoFA8SDRMf0eSiafsAaVru9FWO0wbn64bXTNjwSn
mIymO3lMetlLe12roCYxzAuYSWuSGhImLjqbBsMYBcGc9pkW6ceCkSU+6YX+
6X3H2uvYtagCtWg0dDl59D94Oweg+Gf0ftnI
-----------end_max5_patcher-----------

matcham avatar Apr 28 '22 15:04 matcham

I would like to add that especially when using osc with jitter, I took the habit to always deferlow all upd messages arriving in Max, so I never had this kind of issue using vanilla objects. From what I've read in some other recent discussions, messages from parameters are deferlowed by default, and adding ossia-max.conf with { "default_deferlow": false} should disable it, am i right ? maybe I'm misusing the ossia-max.conf file ? is it used in the nighty-build ?

I've been using ossia-max with jitter / gl2 quite a lot during the last 2 years, without any issues. Now I start using gl3, it becomes a problem... I've sent a message to Rob Ramirez @cycling74 about it, maybe he can give us a hint...

matcham avatar Apr 28 '22 15:04 matcham

hi all. I can reproduce this crash, and it's not clear to me why output from ossia is not properly deferring to the main thread. Looking at the crash log I see the crash occuring in a non-main thread:

Thread 71 Crashed: 0 libGL.dylib 0x00007fff370ce9fc glDeleteVertexArrays + 18 1 com.cycling74.gl3 0x000000010f0d7454 jit_gl_vao_free + 36 2 com.cycling74.Max 0x00000001080043ee freeobject + 190 3 com.cycling74.Max 0x0000000107ffb28b object_free + 27 4 com.cycling74.JitterAPIImpl 0x000000010e247519 jit_object_free + 9 5 com.cycling74.gl3 0x000000010f107e6b jit_gl_geometry_free + 27 6 com.cycling74.Max 0x00000001080043ee freeobject + 190 7 com.cycling74.Max 0x0000000107ffb28b object_free + 27 8 com.cycling74.JitterAPIImpl 0x000000010e247519 jit_object_free + 9 9 com.cycling74.gl3 0x000000010f10e77b jit_gl_gridshape_resubmit + 171 10 com.cycling74.gl3 0x000000010f10e69b jit_gl_gridshape_color_filter + 155 11 com.cycling74.JitterAPIImpl 0x000000010e174e5a jit_attr_filter_proc_filter + 42 12 com.cycling74.Max 0x0000000107ff7710 object_method_imp + 352 13 com.cycling74.JitterAPIImpl 0x000000010e1737bf jit_attr_filterset_wrap + 191 14 com.cycling74.Max 0x000000010804eda0 object_attr_setvalueof_imp + 480 15 com.cycling74.gl3 0x000000010f11f930 jit_gl_videoplane_gshapeattr_filter + 80 16 com.cycling74.JitterAPIImpl 0x000000010e174e5a jit_attr_filter_proc_filter + 42 17 com.cycling74.Max 0x0000000107ff7710 object_method_imp + 352 18 com.cycling74.JitterAPIImpl 0x000000010e1737bf jit_attr_filterset_wrap + 191 19 com.cycling74.Max 0x000000010804eda0 object_attr_setvalueof_imp + 480 20 com.cycling74.Max 0x0000000107ff77d3 object_method_imp + 547 21 com.cycling74.JitterAPIImpl 0x000000010e24c1b2 max_jit_attr_set + 146 22 com.cycling74.JitterAPIImpl 0x000000010e24c07b max_jit_usurp_qfn + 171 23 com.cycling74.JitterAPIImpl 0x000000010e24d0d5 max_jit_usurp_method + 149 24 com.cycling74.Max 0x0000000108033c09 typedmess_fun + 377 25 com.cycling74.Max 0x000000010801f112 outlet_anything + 1426 26 com.cycling74.Max 0x0000000108033c09 typedmess_fun + 377 27 com.cycling74.Max 0x0000000107ffdada aeval + 2314 28 com.cycling74.Max 0x0000000107ffd17e atombuf_eval + 142 29 com.cycling74.message 0x00000001129bda17 jmessage_atombuf_eval + 567 30 com.cycling74.message 0x00000001129bb751 jmessage_float + 177 31 com.cycling74.Max 0x00000001080324d2 outlet_float + 1458 32 com.cycling74.Max 0x00000001080324d2 outlet_float + 1458 33 com.cycling74.Max 0x00000001080324d2 outlet_float + 1458 34 libossia-max.dylib 0x0000000129b65f84 ossia::max_binding::value_visitorossia::max_binding::object_base::operator()(float) const + 100 35 libossia-max.dylib 0x0000000129b65ddc auto ossia::apply<ossia::max_binding::value_visitorossia::max_binding::object_base&>(ossia::max_binding::value_visitorossia::max_binding::object_base&, ossia::value_variant_type&) + 76 36 libossia-max.dylib 0x0000000129b6494d decltype(auto) ossia::value::apply<ossia::max_binding::value_visitorossia::max_binding::object_base&>(ossia::max_binding::value_visitorossia::max_binding::object_base&) + 45 37 libossia-max.dylib 0x0000000129b64722 ossia::max_binding::matcher::output_value(ossia::value) + 834 38 libossia-max.dylib 0x0000000129b90149 ossia::max_binding::matcher::matcher(ossia::net::node_base*, ossia::max_binding::object_base*)::$_0::operator()(ossia::value const&) const + 57 39 libossia-max.dylib 0x0000000129b900f2 decltype(std::__1::forward<ossia::max_binding::matcher::matcher(ossia::net::node_base*, ossia::max_binding::object_base*)::$_0&>(fp)(std::__1::forward<ossia::value const&>(fp0))) std::__1::__invoke<ossia::max_binding::matcher::matcher(ossia::net::node_base*, ossia::max_binding::object_base*)::$_0&, ossia::value const&>(ossia::max_binding::matcher::matcher(ossia::net::node_base*, ossia::max_binding::object_base*)::$_0&, ossia::value const&) + 50 40 libossia-max.dylib 0x0000000129b90092 void std::__1::__invoke_void_return_wrapper<void, true>::__call<ossia::max_binding::matcher::matcher(ossia::net::node_base*, ossia::max_binding::object_base*)::$_0&, ossia::value const&>(ossia::max_binding::matcher::matcher(ossia::net::node_base*, ossia::max_binding::object_base*)::$_0&, ossia::value const&) + 50 41 libossia-max.dylib 0x0000000129b90042 std::__1::__function::__alloc_func<ossia::max_binding::matcher::matcher(ossia::net::node_base*, ossia::max_binding::object_base*)::$_0, std::__1::allocator<ossia::max_binding::matcher::matcher(ossia::net::node_base*, ossia::max_binding::object_base*)::$_0>, void (ossia::value const&)>::operator()(ossia::value const&) + 50 42 libossia-max.dylib 0x0000000129b8ed71 std::__1::__function::__func<ossia::max_binding::matcher::matcher(ossia::net::node_base*, ossia::max_binding::object_base*)::$_0, std::__1::allocator<ossia::max_binding::matcher::matcher(ossia::net::node_base*, ossia::max_binding::object_base*)::$_0>, void (ossia::value const&)>::operator()(ossia::value const&) + 49 43 libossia-max.dylib 0x000000012a0c05ba std::__1::__function::__value_func<void (ossia::value const&)>::operator()(ossia::value const&) const + 74 44 libossia-max.dylib 0x000000012a0c043d std::__1::function<void (ossia::value const&)>::operator()(ossia::value const&) const + 45 45 libossia-max.dylib 0x000000012a0ac682 void ossia::callback_container<std::__1::function<void (ossia::value const&)> >::sendossia::value&(ossia::value&) + 194 46 libossia-max.dylib 0x000000012a0ac88c ossia::net::generic_parameter::set_value(ossia::value&&) + 428 47 libossia-max.dylib 0x0000000129fcf9b5 ossia::net::device_base::apply_incoming_message(ossia::net::message_origin_identifier const&, ossia::net::parameter_base&, ossia::value&&) + 69 48 libossia-max.dylib 0x000000012a354fb0 ossia::net::osc_message_applier::on_value(ossia::net::parameter_base&, ossia::net::device_base&) + 112 49 libossia-max.dylib 0x000000012a2f5153 void ossia::net::on_input_message<false, ossia::net::osc_message_applier>(std::__1::basic_string_view<char, std::__1::char_traits >, ossia::net::osc_message_applier&&, ossia::locked_map<tsl::hopscotch_map<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, ossia::net::parameter_base*, ossia::string_hash, ossia::string_equal, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, ossia::net::parameter_base*> >, 4u, false, tsl::hh::power_of_two_growth_policy<2ul> > > const&, ossia::net::device_base&, ossia::net::network_logger&) + 243 50 libossia-max.dylib 0x000000012a2f5055 ossia::net::osc_protocol::on_received_message(oscpack::ReceivedMessage const&, oscpack::IpEndpointName const&) + 197 51 libossia-max.dylib 0x000000012a333bf8 ossia::net::osc_protocol::update_receiver()::$_0::operator()(oscpack::ReceivedMessage const&, oscpack::IpEndpointName const&) const + 40 52 libossia-max.dylib 0x000000012a33186e osc::listenerossia::net::osc_protocol::update_receiver()::$_0::ProcessMessage(oscpack::ReceivedMessage const&, oscpack::IpEndpointName const&) + 62 53 libossia-max.dylib 0x000000012a3316e2 osc::listenerossia::net::osc_protocol::update_receiver()::$_0::ProcessPacket(char const*, int, oscpack::IpEndpointName const&) + 514 54 libossia-max.dylib 0x000000012a2fc260 oscpack::posix::SocketReceiveMultiplexerImplementationoscpack::posix::UdpSocketImplementation::Run() + 2528 55 libossia-max.dylib 0x000000012a2fb875 oscpack::detail::SocketReceiveMultiplexeroscpack::posix::Implementation::Run() + 21 56 libossia-max.dylib 0x000000012a2fb859 oscpack::detail::UdpListeningReceiveSocketoscpack::posix::Implementation::Run() + 25 57 libossia-max.dylib 0x000000012a2fb807 osc::receiver::run_impl() + 55 58 libossia-max.dylib 0x000000012a2fb7c8 osc::receiver::run()::'lambda'()::operator()() const + 24 59 libossia-max.dylib 0x000000012a2fb76d decltype(std::__1::forwardosc::receiver::run()::'lambda'()(fp)()) std::__1::__invokeosc::receiver::run()::'lambda'()(osc::receiver::run()::'lambda'()&&) + 29 60 libossia-max.dylib 0x000000012a2fb705 void std::__1::__thread_execute<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_deletestd::__1::__thread_struct >, osc::receiver::run()::'lambda'()>(std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_deletestd::__1::__thread_struct >, osc::receiver::run()::'lambda'()>&, std::__1::__tuple_indices<>) + 37 61 libossia-max.dylib 0x000000012a2fafb5 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_deletestd::__1::__thread_struct >, osc::receiver::run()::'lambda'()> >(void*) + 101 62 libsystem_pthread.dylib 0x00007fff672b1109 _pthread_start + 148 63 libsystem_pthread.dylib 0x00007fff672acb8b thread_start + 15

If I synthesize a patch using vanilla max and udp the crash does not occur, and indeed debugging this patch shows proper deferring of jitter attribute setters to the main thread:


----------begin_max5_patcher----------
974.3ocwWssbihCD8Y6uBJp8QuoPby16S4+XqobICZvJCHQIIbblol7susZA
1LY.aBiyF6xfoQnVmS28oE+X4B+8xSLsu2+38udKV7ikKVflrFVzd8B+J5or
RpFGlO664zrW8W4tEOGMJ2+zeS5rUSMYG3hhcJVlwM0jnnGBV4sI0dLNo6n2
WZeDQSEWTxLnKBuXT1X5rFXM9ykKsGVMw05WKkvjLvZM77h04AyK0L2J02ek
m+dpnv+7hqlpnULCSsiIn6KwAFLNVi2Rr3KJFAaRf8XX3XfkLHX6nfuJUUTb
dSmA7ErmAv1gTC6DNS9M40vpkwOx71BeFJTtcb5oGsL.zcncan8z10yA5j6J
P0LQtGIDVIvWxn3cs+sAEYi8DIZybPUv8CUZAsVePZd0iDL.VVOZnCpFr4RW
K9QPnRVim1PtNRC+nie0GnZo5UOHxM.PSGEnZdgfVNIjFf5RqC++BoFYQAnf
76nIYTzvElYqEE4P4VDdwcG+jJGehad3YopLe.3GMJ7gmZGnAp3mNqLu5FxP
oHpWinNd6bJWilAp0k7blZH0kMSRM8cEXCSvhyTWhK9eRbv6Lz10jwpK.1qa
L8Mq4eGWEvjOC1HSVUwfL22lDPKgp5gHoD+qkF6hhDLENwo.G7wq.O59GHQe
b6enMzFRPooDxm29GpXZMsf8awvhxcYxRoxife+qgTmuza58sEhNzu10skj9
I2CxJZUT9vQn1VVWRELuGMJpPaYVXYqYFuPuGgnpHuM7BLxiuggNyEkbAKS1
Hv4Ndf8kNQYvqSgXURTDpMPRB6DJdWIPyfAsTEPQuTx0lgxHHWEb.kYI8FEC
AH7KmmY3RAU8xE3lUxqOv3EGbLnUnedEYtlgNxIL.OEStEGUJk0X6g1qyUzm
MRDg9C2G4BhA00y.r2TlSMzVNskTcf776j06Fvsn60xxFCCfzAmN6Ad12XB8
CU0wsqArvmCYj.gbqw7MtvEgpjG4LqkdCnM30P1rIHHHccZu60QEjKlxjBCH
4uSanFVGl5u568TclvTL2e79xxKVZS8vvAV07l2QECoV6+Z9nV1nx5xpZ2Mr
2kfZNSa3BpMqp2XHsCZvT9o5nzI3n6geRlfeh9kwHU1skLpp38zw1R7g7b3G
umG1wA+QN19Zv2zygedt1twx6ef9My5HtN5NjKShlhmBtGdhLkH48vQAyxQN
cNZc8QlR2NXzGPG1mjXPcyJ7RtvcI1YwWwNx6FO1symp.0dCzmqsOi+oTmlO
nvCoGhFdaFBftk1VMP2aaiBcM0ADrI+xet7+.XrdhdC
-----------end_max5_patcher-----------

The difference between gl2 and gl3 is due to how the gl3 color setter performs the coloring. Taking a closer look at this it seems not ideal, so I've modified how the color setter works, and this does indeed fix the crash in this case. This will be in the next update to gl3 (or 8.3.1 whichever comes first).

but it seems odd that it the stack trace from the ossia handler shows it is not handing off to the main thread as expected, and may be the cause of other crashes.

robtherich avatar Apr 29 '22 14:04 robtherich

hi @robtherich thanks a lot for taking the time to look at this. Libossia is highly multithreaded and network message are processed in a separate thread, thus the parameter callback occur in the network thread. We experienced a lot of crashes in the past with this design and we implemented a message queue to avoid them. An internal metro was polling the queue every 10ms from the main thread. But this was terribly slow and at some point we realised that Max changes and the outlet_* methods appeared thread safe. Then we remove the message queue and we now use directly outlet_* methods from any thread. If outlet_* methods are not thread safe then I'll be happy to know what is the best practice to output values from another thread.

avilleret avatar Apr 29 '22 19:04 avilleret

Thanks very much Rob for your feedback. I did noticed that this issue only concerns setting color of jit.gl.videoplane (and in some cases, jit.gl.layer) ; other parameters of other jit.gl objects do not crash so far. For the time being, I will add deferlow everywhere between ossia.parameters and jit.gl params ; not ideal but at least I can keep on working :-)

matcham avatar Apr 30 '22 08:04 matcham

hi @avilleret

We don't recommend or support calling outlet_* from any thread other than the scheduler thread or low-priority UI thread, so this is likely the culprit here. However you don't need to implement a custom polling scheme or message queue, and can instead use the max scheduler by calling schedule or defer as described in the sdk docs here - https://cycling74.com/sdk/max-sdk-8.2.0/chapter_scheduler.html

My guess is you want to call schedule to keep things high priority. Jitter objects will handle deferring to low priority internally in this case.

Happy to provide more info if this isn't clear.

robtherich avatar May 02 '22 22:05 robtherich

thanks @robtherich for the details, I'll try that soon

avilleret avatar May 08 '22 08:05 avilleret

hmmm, I think that the main reason is that we had interpreted so far the sentence in the Max docs:

In addition, Max provides thread protection between the timer thread and the main thread for many of its common operations, such as sending messages and using outlets.

to assume that writing to outlets from any thread was ok, but this is not really the case if I understand correctly @robtherich ?

jcelerier avatar May 12 '22 12:05 jcelerier

correct.

robtherich avatar May 12 '22 13:05 robtherich

Looks like the patch I posted in my first message doesn't crash any more. Did you changed something ? Or is it Max 8.5 and updated GLcore engine that is more permissive ?...

matcham avatar Nov 23 '22 10:11 matcham

from the comment above

The difference between gl2 and gl3 is due to how the gl3 color setter performs the coloring. Taking a closer look at this it seems not ideal, so I've modified how the color setter works, and this does indeed fix the crash in this case. This will be in the next update to gl3 (or 8.3.1 whichever comes first).

robtherich avatar Nov 23 '22 18:11 robtherich

@matcham can I close this ?

jcelerier avatar Nov 23 '22 20:11 jcelerier

Thanks Rob

@matcham can I close this ?

not sure... from the comment above :

but it seems odd that it the stack trace from the ossia handler shows it is not handing off to the main thread as expected, and may be the cause of other crashes.

We don't recommend or support calling outlet_* from any thread other than the scheduler thread or low-priority UI thread, so this is likely the culprit here. However you don't need to implement a custom polling scheme or message queue, and can instead use the max scheduler by calling schedule or defer as described in the sdk docs here - https://cycling74.com/sdk/max-sdk-8.2.0/chapter_scheduler.html

My guess is you want to call schedule to keep things high priority. Jitter objects will handle deferring to low priority internally in this case.

If nothing has changed on ossia side, I'm afraid that we will bump into other issues / crash with other externals... Shouldn't it be fixed following Rob advices ?

matcham avatar Nov 24 '22 09:11 matcham