github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
Geth MoarVM/foreach-inline: bf5fa9bc33 | (Nicholas Clark)++ | 2 files
Make `MVM_fixkey_hash_foreach` static inline.

This permits the C compiler optimiser to inline the callback into it, and hence remove the indirect function call.
Moving `MVM_fixkey_hash_foreach` to fixkey_hash_table_funcs.h means that
  `calc_entries_in_use` also has to move to that file. Hence (re)name that
function to `MVM_fixkey_hash_kompromat` to be consistent with StrHashTable, and re-order the functions in fixkey_hash_table_funcs.h to be consistent with the order in str_hash_table_funcs.h.		 09:22
nwc10 oops, I did that without a final proofread...
MoarVM: nwc10++ created pull request #1495:
Make `MVM_fixkey_hash_foreach` static inline.		 09:23
nwc10 yet again, inline, the gateway to other optimisations 09:25
lizmat nwc10++ 09:26
MasterDuke segv here dev.azure.com/MoarVM/MoarVM/_build...5&l=43 should we just restart that job? 09:30
tellable6 2021-05-18T06:41:27Z #raku <patrickb> MasterDuke: I can't remember talking about Windows VMs. Can you recall what I wrote about?
MasterDuke patrickb: colabti.org/irclogger/irclogger_lo...-04-19#l86 but it turns out i do have a virtualbox win 10 vm lying around that may suffice 09:31
patrickb MasterDuke: Ah! I have a bare metal Windows 10 installation available and can do what ever is necessary with it. 09:33
MasterDuke i'll keep working in/on/with my vm for now (did already get nqp cloned and built for some jvm work i'm in the middle of), but if it turns out to not be usable i'll ping you again 09:35
nine Is there a way to always print a stacktrace on segfaults? 09:58
nwc10 IIRC I once managed this (but then lost the code) with an extreme hack - a SEGV handler that forked, attached gdb to the parent, then told gdb to print a backtrace. 10:00
I don't know of a better way 10:01
MasterDuke stackoverflow.com/questions/77005/...am-crashes looks like there may be a way...ish 10:02
gist.github.com/MasterDuke17/a5e9e...f2137a6090 has some catchsegv vs gdb output 10:26
Geth MoarVM: bf5fa9bc33 | (Nicholas Clark)++ | 2 files
Make `MVM_fixkey_hash_foreach` static inline.

This permits the C compiler optimiser to inline the callback into it, and hence remove the indirect function call.
Moving `MVM_fixkey_hash_foreach` to fixkey_hash_table_funcs.h means that
  `calc_entries_in_use` also has to move to that file. Hence (re)name that
function to `MVM_fixkey_hash_kompromat` to be consistent with StrHashTable, and re-order the functions in fixkey_hash_table_funcs.h to be consistent with the order in str_hash_table_funcs.h.		 10:29
nine I'll take gdb-nojit.log :) 10:36
MasterDuke heh. but is the catchsegv output useful enough to always use it in our ci pipelines? 10:37
nine It's certainly better than nothing at all. I see daily failures 10:38
MasterDuke or maybe try to enable core dumping, check for core files at the end of each step, if there are any, open in gdb and print a backtrace? 10:39
 i don't know if `catchsegv make test` will work 10:42
nine LD_PRELOAD=/lib/libSegFault.so make test maybe
lizmat nwc10: can we expect visible perf improvement from Make `MVM_fixkey_hash_foreach` static inline. ? 10:43
nwc10 probably not!
but I did look at the generated assembler, and it did what I hoped
it's only called for --full-cleanup
lizmat too bad :-) 10:44
I see... ok :-)
nine MasterDuke: or just link it statically: -lSegFault
nwc10 but the initial "foreach" thing does get us to zero reported leaks from valgrind for --full-cleanup for compiling the empty program
MasterDuke i just tried and it did work with make
i.e., `catchsegv make m-test` with my segv example added to a test file seemed to create similar output to running it directly 10:45
ugh, would have to break out all the CI jobs into separate ones for linux/windows again 10:49
lizmat is there a way to re-open STDIN after it has been closed? nqp::getstdin does not seem to cut it :-( 11:05
maybe nqp::getstdin needs to cut it ? 11:09
alternately, is there a way of dupping the PIO ?
jnthn Is this about Ctrl+D? Because according to stackoverflow.com/questions/511948...fter-ctrld it's not really closing the file handle in this case 11:13
lizmat checks 11:16
so do we have a way to clearerr() on the stdin handle ? 11:17
that is, without needing to resort to NativeCall, as this is in the setting ? 11:18
jnthn No
lizmat meh... ok
jnthn Well, if we do I don't know about it
I've also no idea about the portability of clearerr 11:19
So, needs some research
lizmat workaround for now: github.com/rakudo/rakudo/commit/bca6d72917
nwc10 This linux man page says: The functions clearerr(), feof(), and ferror() conform to C89, C99, POSIX.1-2001, and POSIX.1-2008. 11:20
Geth MoarVM: MasterDuke17++ created pull request #1496:
Run NQP/Rakudo under catchsegv in non-Win32 CI jobs		 11:55
MasterDuke i should have added a task that ran my segfaulting example just to see what the output would be like there... 12:01
MasterDuke dev.azure.com/MoarVM/MoarVM/_build...825fd2b939 an example of catchsegv output in the CI pipeline 12:21
useful enough to clean up github.com/MoarVM/MoarVM/pull/1496 and merge? 12:22
nine Only if in a real world case the backtrace is a little bit more extensive than in the example :) 12:34
MasterDuke Backtrace: 12:43
/home/dan/Source/perl6/install/lib/libmoar.so(MVM_spesh_frame_walker_move_outer+0x2b)[0x7fe16e70794b]
/home/dan/Source/perl6/install/lib/libmoar.so(+0x27897b)[0x7fe16e6b897b]
/home/dan/Source/perl6/install/lib/libmoar.so(MVM_context_apply_traversal+0x88)[0x7fe16e6b9348]
/home/dan/Source/perl6/install/lib/libmoar.so(MVM_interp_run+0x11dd)[0x7fe16e64350d]
./install/bin/raku(+0x17ce)[0x564e498c57ce]
./install/bin/raku(+0x19de)[0x564e498c59de]
that's a different segv run locally
nine is that with or without debug symbols? 12:44
MasterDuke with, but not disabling the jit
nine Well getting the function names is already a huge win
MasterDuke cleanup and merge the PR? 12:47
nine please :)
lizmat will that be for CI only? Or could that be for all cases of running Rakudo ? 13:01
lizmat had a segfault on logs.liz.nl last night :-(
MasterDuke i just changed how the CI call nqp/rakudo. but it looks like maybe there's something we could add to moarvm that would "just work" in some cases/configurations 13:03
lizmat that would be very nice, I think 13:10
Geth MoarVM: 67f5dddb4a | (Daniel Green)++ | azure-pipelines.yml
Run NQP/Rakudo under catchsegv in Linux CI jobs

This will give use more useful information if there's a random error. To help, also build MoarVM with debugging symbols.		 13:26
MoarVM: 0cf502a682 | MasterDuke17++ (committed using GitHub Web editor) | azure-pipelines.yml
Merge pull request #1496 from MasterDuke17/use_catchsegv_in_CI_pipelines

Run NQP/Rakudo under catchsegv in Linux CI jobs

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!