Failed to run redbean on MacOS Catalina 10.15.7 #54
Labels
duplicate
This issue or pull request already exists
Comments
|
Same error. [166563.139703] traps: redbean.com[1446960] general protection fault ip:423002 sp:6ffffffff4e0 error:0 in redbean.com[400000+2a000] OS: Ubuntu 20.1 Linux kernel - 5.8.0-43-generic |
|
Same error no MacOS |
|
Same on MacOS Mojave 10.14.6: $ ./redbean.com -vv
W2021-02-26T07:27:10.790739:tool/net/redbean.c:1144:redbean-2021-02-25:43350] setsockopt(server, IPPROTO_TCP, TCP_FASTOPEN, &yes, sizeof(yes)) → EINVAL/err=22/errno:22/GetLastError:0
W--------------------000012:tool/net/redbean.c:1145:redbean-2021-02-25:43350] setsockopt(server, IPPROTO_TCP, TCP_QUICKACK, &yes, sizeof(yes)) → ENOPROTOOPT/err=42/errno:42/GetLastError:0
V--------------------000011:tool/net/redbean.c:1166:redbean-2021-02-25:43350] 0.0.0.0:8080 listen
D2021-02-26T07:27:13.347579:tool/net/redbean.c:1128:redbean-2021-02-25:43352] 127.0.0.1:58322 accept
V--------------------001005:tool/net/redbean.c:940:redbean-2021-02-25:43352] 127.0.0.1:58322 GET /tool/net/redbean.html referer
^CV2021-02-26T07:27:36.167375:tool/net/redbean.c:1183:redbean-2021-02-25:43350] 0.0.0.0:8080 terminated
D2021-02-26T07:27:36.167393:tool/net/redbean.c:1112:redbean-2021-02-25:43352] 127.0.0.1:58322 terminated
D--------------------000010:tool/net/redbean.c:1130:redbean-2021-02-25:43352] 127.0.0.1:58322 close
W--------------------000141:tool/net/redbean.c:466:redbean-2021-02-25:43350] 0.0.0.0:8080 server killed
$ echo '<html><body><b>hello</b></body></html>' >index.html
$ zip redbean.com index.html
adding: index.html (deflated 18%)
$ ./redbean.com -vv
Killed: 9Not sure if it's to do with the version of $ zip -v
Copyright (c) 1990-2008 Info-ZIP - Type 'zip "-L"' for software license.
This is Zip 3.0 (July 5th 2008), by Info-ZIP.
Currently maintained by E. Gordon. Please send bug reports to
the authors using the web page at www.info-zip.org; see README for details.
Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip,
as of above date; see http://www.info-zip.org/ for other sites.
Compiled with gcc 4.2.1 Compatible Apple LLVM 10.0.1 (clang-1001.0.37.14) for Unix (Mac OS X) on Feb 22 2019.
Zip special compilation options:
USE_EF_UT_TIME (store Universal Time)
SYMLINK_SUPPORT (symbolic links supported)
LARGE_FILE_SUPPORT (can read and write large files on file system)
ZIP64_SUPPORT (use Zip64 to store large files in archives)
STORE_UNIX_UIDs_GIDs (store UID/GID sizes/values using new extra field)
UIDGID_16BIT (old Unix 16-bit UID/GID extra field also used)
[encryption, version 2.91 of 05 Jan 2007] (modified for Zip 3)
Encryption notice:
The encryption code of this program is not copyrighted and is
put in the public domain. It was originally written in Europe
and, to the best of our knowledge, can be freely distributed
in both source and object forms from any country, including
the USA under License Exception TSU of the U.S. Export
Administration Regulations (section 740.13(e)) of 6 June 2002.
Zip environment options:
ZIP: [none]
ZIPOPT: [none] |
|
Thanks for filing this report. I've fixed this issue in 218ef49 and pushed a new binary release here: https://justine.lol/redbean/index.html I'm marking this as a duplicate of #68 for posterity since it was an impactful issue. |
jart
added a commit
that referenced
this issue
Feb 28, 2021
Here's why we got those `Killed: 11` failures on MacOS after modifying the contentns of the redbean.com executable. If you were inserting a small file, such as a HelloWorld.html file, then InfoZIP might have decreased the size of the executable to less than what the Mach-O section had been expecting. That's because when zipobj.com put things like time zone data in the executable, it aligned each zip file entry on a 64-byte boundary, simply for the sake of readability in binary dumps. But when InfoZIP edited the file it would rewrite every entry using ZIP's usual 2-byte alignment. Thus causing shrinkage. The solution was to reconfigure the linker script so that zip file bits that get put into the executable at link-time, such as timezone data, aren't officially part of the executable image, i.e. we don't want the operating system to load that part. The original decision to put the linked zip files into the .data section was mostly made so that when the executable was run in its .com.dbg form it would still have the zip entries be accessible, even though there was tons of GNU debug data following the central directory. We're not going to be able to do that. The .com executable should be the canonical executable. We have really good tools for automatically attaching and configuring GDB correctly with debug symbols even when the .com is run. We'll have to rely on those in cases where zip embedding is used. See #53 See #54 See #68
|
Confirmed this works as documented for me now. @jart your work is remarkable - thank you! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
I could not make the redbean server work on my MacOS Catalina 10.15.7 with a 2,2 GHz Dual-Core Intel Core i7, after adding files via
zip.I tried the following steps:
curl https://justine.lol/redbean/redbean-latest.com >redbean.comecho '<b>hello</b>' >index.htmlzip redbean.com index.htmlchmod +x redbean.combash -c './redbean.com -vv'and I get
[1] 32656 killed ./redbean.comUnfortunately I don't know how to find out the RIP address. Running the unmodified binary works great, though.
When adding a jpg, I get a different error message.
curl https://justine.lol/redbean/redbean-latest.com >redbean.comzip redbean.com some_image.jpgchmod +x redbean.combash -c './redbean.com -vv'Any idea what went wrong?
The text was updated successfully, but these errors were encountered: