<enebo[m]>
headius: so without looking I would say base process loads native and subprocess fails for some reason and the test is spawning another jruby
<headius[m]>
yeah I'm trying to figure out how it's launching stuff
<headius[m]>
aha I think I might have had jruby in PATH but also something from rvm
<headius[m]>
I did rvm system on a hunch and the errors went away
<headius[m]>
👍
<headius[m]>
down to 5F
<headius[m]>
weird, something that is masked to not run when on Windows fails for us, but seems like just some env difference
<headius[m]>
ok nevermind, it came back
<headius[m]>
how peculiar
<headius[m]>
enebo: this is weird
<headius[m]>
java.lang.UnsatisfiedLinkError: dlopen(liblibcrypt.so.1.dylib, 9): image not found
<headius[m]>
at jnr.ffi.provider.jffi.NativeLibrary.loadNativeLibraries(NativeLibrary.java:93)
<headius[m]>
liblib
<headius[m]>
perhaps weirder is that I'm on MacOS and there's not such library even with the right name
<headius[m]>
I'm wondering if this is some kind of threading thing where it's lazily loading on two threads and one sees a partial result
<enebo[m]>
weird
<enebo[m]>
liblib how can that happen...
<headius[m]>
oh I see how it fails over library names
<headius[m]>
so it does try "libcrypt" which gets prepended with lib elsewhere
<headius[m]>
it later tries "crypt" which should work if it exists
<enebo[m]>
SyntaxError: -e:1: Invalid redo
<headius[m]>
but these exceptions shouldn't be getting out in any case
<headius[m]>
hah I forgot about redo
<enebo[m]>
When did error not end up on the front or even on the same line
<headius[m]>
what do you mean?
<enebo[m]>
mri26 -e redosdklfj
<enebo[m]>
I am guessing this was quite a while ago
<enebo[m]>
we output in an older format
<enebo[m]>
we do NameError: vs (NameError) at end
<headius[m]>
oh this is probably from the reversed trace
<enebo[m]>
when was that I think we have been wrong for years
<headius[m]>
hmm
<headius[m]>
I don't get your error
<headius[m]>
$ rvm ruby-2.6.5 do ruby -e redoasdfasdf
<headius[m]>
Traceback (most recent call last):
<headius[m]>
-e:1:in `<main>': undefined local variable or method `redoasdfasdf' for main:Object (NameError)
<enebo[m]>
we prepend error name on the front of the error string
<headius[m]>
the first set of question marks are expected
<headius[m]>
the second set is borked clearly
<enebo[m]>
I did make two fixes to tests which I will need to upstream to MRI but I will do that later (and probably ask headius to help me get started with performing commits to MRI)
<enebo[m]>
I have been too lazy to not just start committing directly
<headius[m]>
nice
<enebo[m]>
Last one is a doozy
<headius[m]>
they just need your pubkey and then you can clone the repo from ruby-lang.org
<enebo[m]>
All name identifiers I will need to make be the value and a position
<enebo[m]>
yeah I will ask later on that
<headius[m]>
as far as process goes... 🤷♂️
<headius[m]>
they don't seem to have any sort of rigid PR or review process
<enebo[m]>
I am going to finish this first because I am doing it and I will end up maybe having more
<headius[m]>
yeah cool get that stuff upstreamed
<headius[m]>
probably best to join ruby-core slack and someone can help you
<enebo[m]>
this last commit I changed from assert_syntax_error to having to spawn processes
<headius[m]>
when the time comes
<enebo[m]>
unfortunately they are doing a lot of iseq compile and left us eval but in these cases eval of an invalid break/next is a different message
<lopex>
you mean mri doesnt have proper pr process ?
<headius[m]>
I believe you can use PRs but they have a separate repo and I've never seen anything indicating when you should use a PR versus committing directly
<headius[m]>
this will be a good chance to clarify that I suppose, I have not committed in a while
<headius[m]>
enebo: ah so eval has a different message from just iseq compiling as a root script
<headius[m]>
you could use our parser
<enebo[m]>
in some cases it does
<headius[m]>
JRuby.parse
<enebo[m]>
but there is no consistency in error messages
<enebo[m]>
parse will not work for us
<headius[m]>
I have used our parser and compiler to replace iseq in a few places
<enebo[m]>
it has to be build + parse
<headius[m]>
JRuby.compile_ir then
<enebo[m]>
so I guess in essence I could make code to do that and then submit that
<enebo[m]>
but for now this is ok...we can probably make our tests faster for some files once I go that route
<enebo[m]>
It is interesting though. in cases I see they still do process spawn but naively I would think they could assert_syntax_error
<enebo[m]>
so there may be other weird wrinkles they hit as well
<enebo[m]>
So the generic error is 'Invalid break'. It is simple but lack context...but you know...it is a break on a line. Seems fine right?
<headius[m]>
I know I patched some of our MRI test files to use JRuby.compile instead of iseq
<enebo[m]>
If you do the same thing within an eval it is: ' Can't escape from eval with break".'
<headius[m]>
yeah
<enebo[m]>
Sure it is more helpful so I could see push back but is this really worth of different text?
<enebo[m]>
I probably would suggest 'Invalid break (within eval)'
<enebo[m]>
Then tests would work and eval could be used but we would then be exercising different pieces of code
<enebo[m]>
which is also interesting because compile_iseq means what? Never an eval I guess?
<headius[m]>
passing garbage through Java String and then forcing to some arbitrary encoding... seems legit
<enebo[m]>
yep...too legit to quite
<headius[m]>
MRI doesn't seem to do anything at all to the incoming string before calling setenv
<headius[m]>
ick
<headius[m]>
our native setenv call uses java.lang.String so I have to conform to that at some point
<lopex>
lol RubyString constructors
<headius[m]>
hmph
<headius[m]>
I can't figure out how to get this string to decode right
<headius[m]>
to be fair I'm not even sure what encoding it's supposed to be, if any
<headius[m]>
%A4%DB%A4%B2
<headius[m]>
somehow that needs to go into a Java string and come through setenv as those bytes
<headius[m]>
lopex: any thoughts on that?
<headius[m]>
I don't even know if this is supposed to be utf-8 or not
<lopex>
headius[m]: no idea
<lopex>
what is this ?
<lopex>
os depentant ?
<headius[m]>
there's a webrick test that uses a CGI script in a subprocess and environment variables to drive it
<lopex>
so transcoding ?
<headius[m]>
that string appears in the request URI, and eventually goes into the env, but I can't figure out how to get it there without it getting mangled into <?> characters
<lopex>
hmm
<headius[m]>
the logic that breaks it is in our ENV impl, where we treat it as UTF_8 and try to decode to a Java string
<lopex>
baybe burp culd help...
<lopex>
*maybe
<headius[m]>
it's only UTF-8 because that's default encoding... but I don't know if it should be utf-8 bytes or what
<lopex>
so, it's like misstranscode on env reads ?
<lopex>
or bad escapes ?
<headius[m]>
it's on the way out
<headius[m]>
I have stepped through an I can see the string we try to use for setenv is already screwed up
<lopex[m]>
and all that in/out encoding settings are the same ?
<lopex[m]>
what env, system and locale ?
<headius[m]>
well it boils down to having a string in hand that's got the bytes \xA4\xDB\xA4\xB2 and then trying to pass that to setenv as a Java string
<headius[m]>
they are being interpreted as UTF-8 because that's the default encoding
<headius[m]>
I need to read up on setenv... if it's legal for it to contain random bytes in no particular encoding then our use of String isn't going to fly
<lopex>
headius[m]: setenv on what os ?
<headius[m]>
well I'm on macos
<headius[m]>
they all just accept char* though so that could be just about anything
<headius[m]>
what did you mean by burp?
<lopex>
headius[m]: sec test analytic tool
<lopex>
@google burp
<headius[m]>
yeah I basically want to understand what these bytes are supposed to be
<headius[m]>
input as SOME_ENCODING => output as UTF-16
<lopex>
no idea
<headius[m]>
ok
<headius[m]>
good news is that it seems to come back in ok: