[OpenBSD] Cannot run much of anything without MVM_JIT_DISABLE #2824
Comments
|
Whatever's responsible for the trace trap is legojit related since it still happens with |
|
I'll bisect the two bugs myself later. I'm writing a script that'll bisect them for me since I really don't want to bisect code that spans across three repos manually (which I'll distribute after this), so it may take a little while. |
AlexDaniel
added
the
BLOCKER
|
The error is telling me that the default |
|
Where are those repos? |
|
This will show you where a named repo is for a given perl6: |
|
They should be writable, but aren't by perl6 for some reason: Running |
|
The trace traps can be fixed by passing perl6 is failing to find any modules because it's getting its own executable name wrong: |
|
Cannot reproduce this: |
|
I'm pretty sure this is a bug in libuv specific to OpenBSD. I wasted a good chunk of the day trying to get I looked through libuv's code and what they do to get the path to the executable is to make a Both of these bugs are OpenBSD specific, so someone should slap the BSD tag on this. Edit: I've patched these bugs myself to get Perl 6 running on my machine, so this isn't highly urgent to fix |
|
I'm fairly sure it's possible to do with sysctl(2), but I need to learn its API and do more testing before I can say for sure whether or not it is |
|
Also see (whereami is a minimal C library to return the current executable path): |
|
You're right, OpenBSD's We can't use sysctl to get the process' argv like libuv does either because surprise! There seems to be a bug in OpenBSD as well. I wrote a short program that just outputs the argv: #include <sys/types.h>
#include <sys/mount.h>
#include <sys/param.h>
#include <sys/sysctl.h>
#include <errno.h>
#include <fcntl.h>
#include <kvm.h>
#include <limits.h>
#include <paths.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
char **
get_argv(int pid)
{
int mib[4];
size_t len;
char **argv;
char **p;
mib[0] = CTL_KERN;
mib[1] = KERN_PROC_ARGS;
mib[2] = pid;
mib[3] = KERN_PROC_ARGV;
sysctl(mib, 4, &argv, &len, NULL, 0);
return argv;
}
int
main(int argc, char **argv)
{
int pid, fd, e;
char **args, **p;
if (argc != 2) {
fprintf(stderr, "Usage: ./test <pid>\n");
return 1;
}
pid = atoi(argv[1]);
p = args = get_argv(pid);
do {
printf("%s\n", *p);
} while (++p != NULL);
free(args);
return 0;
}This is its output: bastille% ./test 81968
1ýÿ��
test
zsh: segmentation fault (core dumped) ./test 81968So I think it'd be best just not to use |
Fixess one of two parts to rakudo#2824
|
I forgot to link it here, but I made a separate issue for the JIT problems on OpenBSD on MoarVM's repo because the cause of them is highly technical and only deals with a very specific part of MoarVM's JIT compiler MoarVM/MoarVM#1091 |
lizmat
changed the title
lizmat
removed
the
BLOCKER
|
Closing this issue since the JIT issue is now handled with MoarVM/MoarVM#1091, and the execname issue has been fixed. |
The Problem
This is really two separate issues, but I didn't want to be too spammy with them. See title.
Everything worked fine in 2019.03.
Expected Behavior
zef should be possible to install and it should be possible to run scripts without
MVM_JIT_DISABLE=1in the env.Actual Behavior
See "Steps to Reproduce" since I don't want to repeat myself.
Steps to Reproduce
Let's try installing zef normally:
Oops. This also happens when trying to install nqp and Rakudo, for the record. The backtrace from the core dump doesn't give much info:
When I had moar compiled without
--optimize=0 --debug=3, one of the JIT ops popped up in the backtrace, so the JIT appears to be to blame. The output ofMVM_SPESH_LOGshows that it can't find the templates forgetattr_oandsp_fastbox_i_icin particular, with these also failing, but for different reasons (such as being legojit and thus having no expr template, for instance):bindlexcoerce_incoerce_nieq_ngt_nlt_nprepargssp_bind_s_nowbsp_getlex_inssp_getlex_osp_guardsfthrowpayloadlexAnyway, let's try again with
MVM_JIT_DISABLE=1:And again, as root:
These errors could possibly be OS-dependent since I just upgraded to OpenBSD 6.5. Someone else should test this to see if it works on other OSes.
Environment
OpenBSD bastille.kennel.qt 6.5 GENERIC.MP#839 amd64
perl6 -v):This is Rakudo version 2019.03.1-167-gcd52d404b built on MoarVM version 2019.03-68-g25b486dee
implementing Perl 6.d.
The text was updated successfully, but these errors were encountered: