I have polyglot code. clojure jvm calling into code in the graal js environment. A call into the js code blows the stack on a native-image, but works when jarred and running under graals jvm.

if I dont stress the js stack, the code runs. But when I feed it something more complex, on native-image it explodes with:

#error {
 :cause RangeError: Maximum call stack size exceeded
 :via
 [{:type org.graalvm.polyglot.PolyglotException
   :message RangeError: Maximum call stack size exceeded
   :at [<js> Opal.send Unnamed 1671]}]
 :trace
 [[<js> Opal.send Unnamed 1671]
  [<js> alias Unnamed 1861]
  [<js> :anonymous Unnamed 22885]
  [<js> $$2 Unnamed 22884]
  [<js> Opal.yield1 Unnamed 1452]
  [<js> $$each Unnamed 12527]
  [<js> Opal.send Unnamed 1671]
  [<js> $$apply_subs Unnamed 22877]
  [<js> :anonymous Unnamed 26325]
  [<js> $$content Unnamed 26323]
  [org.graalvm.polyglot.Context eval Context.java 425]
  [bootleg.asciidoc$asciidoctor_convert invokeStatic asciidoc.clj 37]
  [bootleg.asciidoc$convert invokeStatic asciidoc.clj 46]
  [bootleg.asciidoc$convert doInvoke asciidoc.clj 46]
  [clojure.lang.RestFn invoke RestFn.java 410]
  [bootleg.asciidoc$asciidoc invokeStatic asciidoc.clj 68]
  [bootleg.asciidoc$asciidoc doInvoke asciidoc.clj 63]
  [clojure.lang.RestFn invoke RestFn.java 410]
  [clojure.lang.AFn applyToHelper AFn.java 154]
  [clojure.lang.RestFn applyTo RestFn.java 132]
  [clojure.core$apply invokeStatic core.clj 667]
  [bootleg.pod$main$fn__17406 invoke pod.clj 942]
  [bootleg.pod$main invokeStatic pod.clj 935]
  [bootleg.core$_main invokeStatic core.clj 96]
  [bootleg.core$_main doInvoke core.clj 91]
  [clojure.lang.RestFn invoke RestFn.java 397]
  [clojure.lang.AFn applyToHelper AFn.java 152]
  [clojure.lang.RestFn applyTo RestFn.java 132]
  [bootleg.core main nil -1]]}

anyone know how to set the js stack size in a native-image?

I tried all the obvious compile options, and I tried looking for a js option when building the context that altered stack size and their doesnt seem to be one. And the "sandbox" embedded language stack size controls are only available on enterprise edition

@retrogradeorbit I think this question is better suited for the GraalVM slack, they have a graal-js channel with one of the maintainers on there. There is also a Github Discussions on their repo.

yeah i asked over there too. still waiting for a response. if nothing happens theres always opening a ticket

@retrogradeorbit Is this happening with a musl-compiled binary? I have stack problems with those with a solution

yeah its musl compiled, let me try dynamic compile see if it also occurs there

@retrogradeorbit In that case, I may know a solution

Here is the issue, it's likely that you are hitting it too: https://github.com/oracle/graal/issues/3398

See this "solution": https://github.com/babashka/babashka/blob/638ae3aaeb8cc2c94502811546c2241fba3c63e5/src/babashka/main.clj#L950-L968

together with -H:CCompilerOption=-Wl,-z,stack-size=10485760 (or higher if needed)

I think it would be worth posting your findings there too.

yeah interesting

start a thread with a new stack and launch it there

yes + increase stack size

the increased stack size doesn't impact the main thread

I remember from my C days this stuff can be done in crt0.s

which is like the assembler bootstrap into main()

not gonna dive in... a work around that works is good enough for me

It's best if the graalvm team fixed this. They are aware but commenting on the issue may help

yeah replacing crt0.s requires the gcc/musl command line invocation, which we dont have access to, as native-image runs that

isn't that what -H:CCompilerOption=-Wl,-z,stack-size=10485760 is for?

ok, the problem doesnt occur on a dynamic link

yes, it is musl-specific

ah yeah, so you could hook in your own there if you really got serious

yes confirmed this is the same problem

so do you do this launch fork in bb?

ah yeah, I see it

the run macro in babashka.main

that fixed it. what would I do without you? 😄