[01:21] *** sena_kun left [01:36] *** sena_kun joined [01:36] odd, enabling asan has no effect [02:39] does the whole rakudo test suite (not necessarily the spec tests) pass? [03:10] yes [03:20] *** sena_kun left [03:35] *** sena_kun joined [04:35] *** statisfiable6 left [04:35] *** committable6 left [04:35] *** notable6 left [04:35] *** shareable6 left [04:35] *** benchable6 left [04:35] *** coverable6 left [04:35] *** evalable6 left [04:35] *** squashable6 left [04:35] *** linkable6 left [04:35] *** bloatable6 left [04:35] *** unicodable6 left [04:35] *** releasable6 left [04:35] *** notable6 joined [04:35] *** quotable6 joined [04:35] *** bisectable6 joined [04:35] *** releasable6 joined [04:35] *** evalable6 joined [04:36] *** squashable6 joined [04:36] *** tellable6 joined [04:36] *** benchable6 joined [04:36] *** greppable6 joined [04:37] *** nativecallable6 joined [04:37] *** coverable6 joined [04:37] *** statisfiable6 joined [04:37] *** reportable6 joined [04:37] *** shareable6 joined [04:37] *** committable6 joined [04:37] *** linkable6 joined [04:38] *** unicodable6 joined [04:38] *** sourceable6 joined [04:38] *** bloatable6 joined [04:47] now I'm confused [04:47] I got it running with debugsyms, and the last bit of code in moar before it's libc error detection is nativecall_dyncall.c:362 [04:47] which is break; [04:50] ah-hmmm. I recompiled just that file without optimizations, to see if that would change the location of the error. With that change, there's no stack smashing error [04:53] here we go, ubsan to the rescue! [04:54] runtime error: member access within misaligned address ... for type MVMObject/MVMCollectable/MVMCode/MVMCodeBody/MVMStaticFrame */MVMSTable * [04:55] lines 86, 91, and 207 of nativecall_dyncall.c [05:18] *** moritz joined [05:21] *** sena_kun left [05:36] *** sena_kun joined [05:53] *** harrow joined [07:21] *** squashable6 left [07:21] *** sena_kun left [07:22] *** squashable6 joined [07:37] *** sena_kun joined [08:37] moon-child: that error may indicate that your native function returns NULL instead of a function pointer [08:38] moon-child: apparently we don't have any NULL checks there [09:10] *** zakharyas joined [09:21] *** sena_kun left [09:23] *** hankache joined [09:35] *** hankache left [09:35] *** sena_kun joined [11:21] *** sena_kun left [11:36] *** sena_kun joined [12:48] *** zakharyas left [12:51] *** lucasb joined [13:21] *** sena_kun left [13:36] *** sena_kun joined [14:16] *** squashable6 left [14:16] *** squashable6 joined [14:17] *** zakharyas joined [15:20] *** sena_kun left [15:36] *** sena_kun joined [17:20] *** sena_kun left [17:36] *** sena_kun joined [18:06] *** MasterDuke left [18:16] *** squashable6 left [18:19] *** squashable6 joined [19:00] *** MasterDuke joined [19:21] *** sena_kun left [19:37] *** sena_kun joined [19:41] *** zakharyas left [20:34] nine: I don't think so. Execution enters the function properly and I can do stuff inside of it. It's just the return that causes those errors. And ubsan mentions addresses of actual pointers, and it all works fine without optimizations [21:03] *** zakharyas joined [21:20] *** sena_kun left [21:35] *** sena_kun joined [21:36] *** hankache joined [21:57] *** zakharyas left [22:01] *** hankache_ joined [22:04] *** hankache left [22:10] *** lucasb left [22:12] *** hankache_ left [22:48] *** jjatria left [22:48] *** jjatria joined [23:18] *** dogbert17 left [23:21] *** sena_kun left [23:27] *** dogbert17 joined [23:36] *** sena_kun joined [23:40] *** Kaiepi joined [23:41] *** Kaiepi left [23:42] *** Kaiepi joined [23:52] *** AlexDani` joined [23:53] *** AlexDaniel left