<ssaschaa[m]>
I wounder if I could do any further investigation/debugging. But where to begin...
TimGitter[m]1 has quit [Ping timeout: 240 seconds]
FlorianDoubletGi has quit [Ping timeout: 240 seconds]
basshelal[m] has quit [Ping timeout: 240 seconds]
liamwhiteGitter[ has quit [Ping timeout: 240 seconds]
UweKuboschGitter has quit [Ping timeout: 240 seconds]
JesseChavezGitte has quit [Ping timeout: 240 seconds]
MattWelke[m] has quit [Ping timeout: 240 seconds]
dangerousdave has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
basshelal[m] has joined #jruby
<headius>
ssaschaa: good morning and happy new year!
<headius>
I will look into that when I start work later this morning but there were some fixes to an upstream dependency that might have helped. Specifically any operation that involved getting file permissions was garbling the data
<headius>
I believe we have some snapshot builds of 9.3 with the fixed library in place
UweKuboschGitter has joined #jruby
JesseChavezGitte has joined #jruby
liamwhiteGitter[ has joined #jruby
MattWelke[m] has joined #jruby
TimGitter[m]1 has joined #jruby
FlorianDoubletGi has joined #jruby
dangerousdave has joined #jruby
<ssaschaa[m]>
Thanks for your reply! Just for your info: I had build 9.4-SNAPSHOT from the sources at github. I think there are some ffi patches (file stat bitmask on ARM Apple devices) included already.
<ssaschaa[m]>
It seems to happen only on new files, as File.chmod works as expected.
<ssaschaa[m]>
uups. Mistakenly claimed File.chmod was working, while it doesn‘t.
<headius>
Yeah that snapshot should have all the latest fixes
<headius>
The short-term workaround would be to use an x86 JDK for now but I will look into this shortly and see if we can do a localized fix
<ssaschaa[m]>
Thank you!
dangerousdave has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
subbu has joined #jruby
subbu has quit [Remote host closed the connection]
dangerousdave has joined #jruby
subbu has joined #jruby
<headius>
Ok I'm here now
<headius>
enebo: when you get a chance let
<headius>
let me know anything you did over the break
<headius>
I was pretty much out for two solid weeks plus yesterday
<headius>
hmmm
<headius>
ssaschaa: looking at your case now
<headius>
we do use fcntl here to set FD_CLOEXEC but the file permissions are just set during a call to `open` and I would have expected that to be ok
<headius>
aha no I wouldn't because it is also varargs past the filename and flags
<ssaschaa[m]>
Clarification: File.chmod works
<headius>
anything in varargs are still being passed wrong for M1 so it is likely getting garbled on the stack
<headius>
chmod on the other hand is not varargs
<headius>
int
<headius>
open(const char *path, int oflag, ...);
<ssaschaa[m]>
Sorry that I cannot help, I was already lost in the sysopen chain at RubyIO.java....
<headius>
yeah it bounces through a lot of interfaces but eventually bottoms out in our native call to `open`
<ssaschaa[m]>
Could be little- vs. big-endian, but that would have crashed earlier at other machines.
<headius>
yeah that should be ok... we did have aarch64 support previously but M1/Darwin structures varargs differently and fixing it has confounded me
<headius>
specifically it uses a combination of stack and heap to pass the arguments and we are only using the heap, so it looks for the varags in the wrong place
<headius>
the proper fix requires reworking how we dispatch in the native code of our FFI backend, so that it uses the standard libffi functions to set up the call args
<ssaschaa[m]>
Is there some debuging I could do?
<headius>
not really... I know the problem, I just haven't had much success fixing it (I did not write this part of the library and it is pretty complicated)
<ssaschaa[m]>
I agree ;-)
andreimaxim[m] has joined #jruby
<andreimaxim[m]>
Hello, folks. I'm trying to figure out if JRuby 9.3.0.0 (and later) introduced a change that might change the way JDOM works, especially with `ActiveSupport::XmlMini`. Seems like the following piece of code is crashing:
<andreimaxim[m]>
I was hoping I could get some hints on how to narrow down this issue or how to work around it as it's currently blocking our migration from JRuby 9.2.x.x to JRuby 9.3.x.x. Thanks!
<andreimaxim[m]>
with the error "NoMethodError: undefined method `ATTRIBUTE_NODE' for Java::OrgW3cDom::Node:Module".
<andreimaxim[m]>
* Hello, folks. I'm trying to figure out if JRuby 9.3.0.0 (and later) introduced a change that might change the way JDOM works, especially with `ActiveSupport::XmlMini`. Seems like the following piece of code is crashing:
<andreimaxim[m]>
I was hoping I could get some hints on how to narrow down this issue or how to work around it as it's currently blocking our migration from JRuby 9.2.x.x to JRuby 9.3.x.x. Thanks!
<andreimaxim[m]>
with the error "NoMethodError: undefined method `ATTRIBUTE_NODE' for Java::OrgW3cDom::Node:Module".
<andreimaxim[m]>
* Hello, folks. I'm trying to figure out if JRuby 9.3.0.0 (and later) introduced a change that might change the way JDOM works, especially with `ActiveSupport::XmlMini`. Seems like the following piece of code is crashing:
<andreimaxim[m]>
with the error `NoMethodError: undefined method `ATTRIBUTE_NODE' for Java::OrgW3cDom::Node:Module`.
<andreimaxim[m]>
I was hoping I could get some hints on how to narrow down this issue or how to work around it as it's currently blocking our migration from JRuby 9.2.x.x to JRuby 9.3.x.x. Thanks!
<headius>
andreimaxim: ok first off it would probably be good to file a bug, but I think I know the issue
<headius>
in 9.3 we stopped allowing access to static variables on interfaces because it was inconsistent with how classes work, and then should be accessed by `::` like other constants anyway
<headius>
I would guess that somewhere in that code it is trying to access org.w3c.dom.Node::Module.ATTRIBUTE_NODE when it should be Module::ATTRIBUTE_NODE
<headius>
er nevermind I got the output confused there
<headius>
org.w3c.dom.Node.ATTRIBUTE_NODE should be Node::ATTRIBUTE_NODE
<andreimaxim[m]>
headius: should I create a JRuby bug or an ActiveSupport bug?
<headius>
I'm not sure if this is in activesupport or not but you could look in the gems for `Node.ATTRIBUTE_NODE` and probably find the line
<headius>
workaround for you would be to reopen the interface module and add the equivalent method
<headius>
module org::w3c::dom::Node
<headius>
def self.ATTRIBUTE_NODE; ATTRIBUTE_NODE; end
<headius>
end
<headius>
but there may be other cases doing the same thing
<headius>
andreimaxim: so I would say file the bug against whatever library accesses this code (and your backtrace should show where too)
<headius>
it is not a bug in JRuby but it was a behavior change
<andreimaxim[m]>
headius: thanks, I will create a bug for `ActiveSupport::XmlMini`. I think it makes more sense to have the library access the constants correctly.
<headius>
yeah thank you, feel free to @ me and I can answer any questions
<headius>
the proper syntax will work in any JRuby so it is a pretty clean change
<andreimaxim[m]>
headius: awesome, thank you very much for your help and thank all of you for the hard work you've been putting into JRuby!
<headius>
no problem, we have a good community here that keeps things moving 😀
dangerousdave has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<headius>
ok that's progress... I have jffi tracking fixed arg count versus passed arg count and choosing vararg or normal ffi invocation
<headius>
nothing uses var path but the fixed count is at least propagating
<headius>
trying to make this a minimal change since the old logic basically sets up va_arg manually... hopefully I can localize this to M1 and only use the new logic there, until we can test and rebuild other platforms
<headius>
omg I think it called the varargs path properly
<headius>
if it was this easy all along I'm going to kick myself
<headius>
two out of three varargs tests are passing, so that seems to be a good sign
<headius>
the third is passing an int as a size_t to printf("%zu") and the value is getting garbled
<headius>
ok this is pretty close
<headius>
I have the varargs test passing on M1
<headius>
the fcntl tests in jnr-posix still seem off
<headius>
aha!
<headius>
fcntl is not called as varargs from jnr-posix
<headius>
so there's an issue here from the perspective of a jnr-ffi caller... if you specify no varargs, we do not know to branch into the varargs logic
<headius>
on platforms where FFI always passes fixed + varargs in the same way this works fine, but when varargs have special handling we need to know to use this other path
<headius>
we used to bind fcntl as a varargs function but since we only used the int form we added additional bindings for that and started to prefer them
<headius>
this works fine when the underlying FFI treats fixed args and varargs the same, because they all just go on the stack
<headius>
M1 FFI however passes fixed and varargs differently and so we need to know where the fixed args end and the varargs begin
<headius>
the non-varargs form here is therefore unsupportable as-is on M1
<headius>
I can see two options
<headius>
1. switch to the varargs form... this would be the easy short-term fix in jnr-posix since the libc interface is not public
<headius>
2. provide a way in jnr-ffi to specify where varargs start so we can set up the param counts properly
<headius>
@Variadic annotation or something
<headius>
I'm going to go with the first option to confirm this is working