I got these errors in the H2O error log with the lastest h2o-devel-2.3.0.d.20230427 port. As result server is not responding to requests. # uname -v FreeBSD 13.2-RELEASE releng/13.2-n254617-525ecfdad597 GENERIC # pkg info | grep ruby | head -1 ruby-3.1.4_1,1 Object-oriented interpreted scripting language
thanks for the PR. Can you provide any context? I don't see this locally. Any specific HTTP requests, config, mruby settings? BTW due to summer period, response will be delayed.
(In reply to Dave Cottlehuber from comment #1) Yes, of course. I use mruby in a configuration to control access to various resources using the standard acl.rb mruby class, e.g. like this "myhost:443": http2-casper: on listen: port: 443 ssl: <<: *default_ssl paths: "/": reproxy: ON header.add: "Strict-Transport-Security: max-age=15768000; includeSubDomains; preload" mruby.handler: | acl { deny { path.match("^/?(\.git|\.ht)") } } file.dir: /usr/local/www/kostikov.co and it looks like the issue is in this class usage, because after commenting it out, everything works fine. With the previous version of H2O-devel (which I believe uses a previous version of Ruby 2.x) everything is fine.
Created attachment 244553 [details] patch and pet portlinters Max - I'll roll a patch for the latest h2o and attach it here, just in case its locally fixed. If not, can you report it upstream to h2o project please, feel free to @ me I'm dch there too. Uwe - have you had any mruby issues from the last update? Also, try the new patch if you can.
Thanks for the update. In my case the patch didn't help and I still get the "mruby raised: stack level too deep (SystemStackError)" errors.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=638826ec084420e4ea7cbb5c0c55d0d92a8b7b99 commit 638826ec084420e4ea7cbb5c0c55d0d92a8b7b99 Author: Dave Cottlehuber <dch@FreeBSD.org> AuthorDate: 2023-09-05 20:34:37 +0000 Commit: Dave Cottlehuber <dch@FreeBSD.org> CommitDate: 2023-09-05 20:34:37 +0000 www/h2o-devel: update to 20230817 snapshot Reported by: Max Kostikov <max@kostikov.co> Sponsored by: SkunkWerks, GmbH PR: 271239 www/h2o-devel/Makefile | 51 ++++++++--------- www/h2o-devel/distinfo | 6 +- www/h2o-devel/pkg-plist | 146 ++++++++++++++++++++++++------------------------ 3 files changed, 99 insertions(+), 104 deletions(-)
Max can you raise this upstream at https://github.com/h2o/h2o/issues/ please?
Done. https://github.com/h2o/h2o/issues/3304
I've just tried to build h2o with both ruby 3.1 and 3.3. The failure seems to be here: [00:00:04] /wrkdirs/usr/ports/www/h2o/work/h2o-2.2.6/deps/libgkc -I/wrkdirs/usr/ports/www/h2o/work/h2o-2.2.6/deps/libyrmcds -I/wrkdirs/usr/ports/www/h2o/work/h2o-2.2.6/deps/klib -I/wrkdirs/usr/ports/www/h2o/work/h2o-2.2.6/deps/neverbleed -I/wrkdirs/usr/ports/www/h2o/work/h2o-2.2.6/deps/picohttpparser -I/wrkdirs/usr/ports/www/h2o/work/h2o-2.2.6/deps/picotest -I/wrkdirs/usr/ports/www/h2o/work/h2o-2.2.6/deps/yaml/include -I/wrkdirs/usr/ports/www/h2o/work/h2o-2.2.6/deps/yoml -I/usr/local/include -I/wrkdirs/usr/ports/www/h2o/work/h2o-2.2.6/deps/picotls/deps/cifra/src/ext -I/wrkdirs/usr/ports/www/h2o/work/h2o-2.2.6/deps/picotls/deps/cifra/src -I/wrkdirs/usr/ports/www/h2o/work/h2o-2.2.6/deps/picotls/deps/micro-ecc -I/wrkdirs/usr/ports/www/h2o/work/h2o-2.2.6/deps/picotls/include -O2 -g -Wall -Wno-unused-value -Wno-unused-function -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -DH2O_ROOT="/usr/local" -DH2O_CONFIG_PATH="etc/h2o.conf" -pthread -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -DNDEBUG -fPIC -MD -MT CMakeFiles/libh2o.dir/lib/handler/configurator/headers_util.c.o -MF CMakeFiles/libh2o.dir/lib/handler/configurator/headers_util.c.o.d -o CMakeFiles/libh2o.dir/lib/handler/configurator/headers_util.c.o -c /wrkdirs/usr/ports/www/h2o/work/h2o-2.2.6/lib/handler/configurator/headers_util.c [00:00:04] --- CMakeFiles/mruby.dir/all --- [00:00:04] rake aborted! [00:00:04] undefined method `exists?' for class File [00:00:04] Rakefile:28:in `load' Is this related?
this has been resolved upstream now, closing. TLDR yaml is tricky.