segmentation fault when running cook server

[The-Ludwig]

Running on arch linux I get a segmentation fault on v0.1.3:

> cook server
Started server on http://127.0.0.1:9080, serving cook files from /home/ludwig/Documents/cook.
zsh: segmentation fault (core dumped)  cook server

but only after I open the webpage in my browser. I tried it both with the provided binary and with a self compiled binary.

Furthermore, with v0.1.2 I get an instant segmentation fault and with v0.0.13 it works.

I hope somebody can help me, or that this bug report will be of some help. Awesome project!

[dubadub]

@The-Ludwig thanks for reporting, this issue should be fixed in v0.1.4. I checked on my arch linux virtual machine and it works now. Please feel free to re-open the issue if not. Thanks!

[The-Ludwig]

Thanks for the quick response! Sadly I still get the same error. I also checked on a frech archlinux docker image, same problem.

But it only happens when I start cook server in directories with recipes. If the folder is empty, no segmentation fault. Output:

[root@3e63a98b52f4 ~]# ./cook version
v0.1.4 – in food we trust
[root@3e63a98b52f4 ~]# ./cook server
Started server on http://127.0.0.1:9080, serving cook files from /root.
Segmentation fault (core dumped)
[root@3e63a98b52f4 ~]# mkdir empty
[root@3e63a98b52f4 ~]# cd empty/
[root@3e63a98b52f4 empty]# ls
[root@3e63a98b52f4 empty]# ../cook server
Started server on http://127.0.0.1:9080, serving cook files from /root/empty.

[The-Ludwig]

@dubadub I can not reopen the Issue myself, since I did not close it myself.

[RottenFishbone]

I also get this seg fault on manjaro using cook 0.1.4

I have a fresh directory, unzipped cook 0.1.4 into it, ran ./cook seed, ran ./cook server and received the output: Started server on http://127.0.0.1:9080, serving cook files from /path/to/cook.d.

Immediately after loading the page in a browser I get fish: Job 1, './cook server' terminated by signal SIGSEGV (Address boundary error)

It may be noteworthy that no recipes actually loaded on the web page. I have tried running cook as root, to no avail.

[dpgeekzero]

Just for completeness, I launched cook server (0.1.6) from bash and it fails there as well, but I do run under fish normally.

I also tried deleting the subdirectories to see if it made any difference, but there was no change.

[dubadub]

Hmm, I don't think I can reproduce the error. Could you please share your macOS version @dpgeekzero?

[dpgeekzero]

@dubadub - Archlinux here

                   -`
                  .o+`                 
                 `ooo/                 OS: Arch Linux
                `+oooo:                Kernel: x86_64 Linux 5.18.14-arch1-1
               `+oooooo:               Uptime: 2d 3m
               -+oooooo+:              Packages: 1600
             `/:-:++oooo+:             Shell: fish 3.4.1
            `/++++/+++++++:            Resolution: 5120x1440
           `/++++++++++++++:           DE: KDE 5.96.0 / Plasma 5.25.3
          `/+++ooooooooooooo/`         WM: KWin
         ./ooosssso++osssssso+`        GTK Theme: Breeze [GTK2/3]
        .oossssso-````/ossssss+`       Icon Theme: breeze-dark
       -osssssso.      :ssssssso.      Disk: 260G / 477G (58%)
      :osssssss/        osssso+++.     CPU: Intel Core i7-9850H @ 12x 4.6GHz [51.0°C]
     /ossssssss/        +ssssooo/-     GPU: Quadro T1000
   `/ossssso+/:-        -:/+osssso+-   RAM: 10801MiB / 31731MiB
  `+sso+:-`                 `.-/+oso:
 `++:.                           `-/+/
 .`                                 `/

[ruudschouten]

I'm running into the same issue with 0.1.6, on WSL Ubuntu LTS. Tried with my existing recipes, and the ones generated from seed. Everything seems to work fine, until I navigate to localhost:9080, which is when Segmentation fault is printed in the log.

I did go ahead and tried a few previous versions, because it did work for me at one point, and 0.1.3 works without the error popping up, and I can navigate through my recipes.

also, screenfetch just in case you need it;

                          ./+o+-       ruuds@DESKTOP-5HH2MOP
                  yyyyy- -yyyyyy+      OS: Ubuntu 22.04 jammy(on the Windows Subsystem for Linux)
               ://+//////-yyyyyyo      Kernel: x86_64 Linux 5.4.72-microsoft-standard-WSL2
           .++ .:/++++++/-.+sss/`      Uptime: 13m
         .:++o:  /++++++++/:--:/-      Packages: 604
        o:+o+:++.`..```.-/oo+++++/     Shell: bash 5.1.16
       .:+o:+o/.          `+sssoo+/    Disk: 6.3T / 7.6T (84%)
  .++/+:+oo+o:`             /sssooo.   CPU: AMD Ryzen 7 3700X 8-Core @ 16x 3.593GHz
 /+++//+:`oo+o               /::--:.   GPU: NVIDIA GeForce RTX 2080
 \+/+o+++`o++o               ++////.   RAM: 474MiB / 25615MiB
  .++.o+++oo+:`             /dddhhh.  
       .+.o+oo:.          `oddhhhh+   
        \+.++o+o``-````.:ohdhhhhh+    
         `:o+++ `ohhhhhhhhyo++os:     
           .o:`.syhhhhhhh/.oo++o`     
               /osyyyyyyo++ooo+++/    
                   ````` +oo+++o\:    
                          `oo++.      

[mjsr]

Testing now on 0.1.6 and segfault also on my end.

$ cook server -b 192.168.178.245
Started server on http://192.168.178.245:9080, serving cook files from /home/marcos/github/receitas.
Segmentation fault (core dumped)

Trying to get more information with gdb:

$ gdb --args ~/.local/bin/cook server -b 192.168.178.245
(gdb) run
Starting program: /home/marcos/.local/bin/cook server -b 192.168.178.245
Started server on http://192.168.178.245:9080, serving cook files from /home/marcos/github/receitas.

At this point, I open the page on my browser.

warning: File "/usr/lib/x86_64-linux-gnu/libthread_db.so.1" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
        add-auto-load-safe-path /usr/lib/x86_64-linux-gnu/libthread_db.so.1
line to your configuration file "/home/marcos/.config/gdb/gdbinit".
To completely disable this security protection add
        set auto-load safe-path /
line to your configuration file "/home/marcos/.config/gdb/gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
        info "(gdb)Auto-loading safe path"
warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7f15ef4 in __GI___nss_readline (poffset=<optimized out>, len=<optimized out>, buf=<optimized out>, fp=<optimized out>) at ../include/ctype.h:41
41      ../include/ctype.h: No such file or directory.

Note: I also tried with add-auto-load-safe-path /usr/lib/x86_64-linux-gnu/libthread_db.so.1 and rerunning. Same results.

Following on:

(gdb) backtrace
#0  0x00007ffff7f15ef4 in __GI___nss_readline (poffset=<optimized out>, len=<optimized out>, buf=<optimized out>, fp=<optimized out>)
    at ../include/ctype.h:41
#1  __GI___nss_readline (fp=fp@entry=0x7ffff7c852a0, buf=buf@entry=0x319e7e0 "root:x:0:0:root:/root:/bin/bash\n", len=len@entry=1024, 
    poffset=poffset@entry=0x7fffffffc9c0) at ./nss/nss_readline.c:26
#2  0x00007ffff7f1bb92 in internal_getent (errnop=<optimized out>, buflen=<optimized out>, buffer=<optimized out>, result=<optimized out>, 
    stream=<optimized out>) at nss_files/files-XXX.c:124
#3  __GI__nss_files_getpwuid_r (uid=<optimized out>, result=0x31791c0 <resbuf>, buffer=0x319e7e0 "root:x:0:0:root:/root:/bin/bash\n", 
    buflen=1024, errnop=0x317b8f0) at nss_files/files-pwd.c:40
#4  0x0000000000f2b135 in getpwuid_r ()
#5  0x0000000000f2ab08 in getpwuid ()
#6  0x00000000005d8a58 in $s10Foundation11FileManagerC17_attributesOfItem6atPath26includingPrivateAttributesSDyAA0B12AttributeKeyVypGSS_SbtKF ()
#7  0x00000000006d499a in $s10Foundation24URLResourceValuesStorageC4read33_F90A2F480B61EE78BC0B3683A06A0466LL_3forSDyAA0B3KeyVypSgGSayAHG_AA5NSURLCtKF9attributeL_yAiA013FileAttributeP0VKF ()
#8  0x00000000006daaab in $s10Foundation24URLResourceValuesStorageC4read33_F90A2F480B61EE78BC0B3683A06A0466LL_3forSDyAA0B3KeyVypSgGSayAHG_AA5NSURLCtKFTf4nnd_n ()
#9  0x00000000006d1030 in $s10Foundation24URLResourceValuesStorageC08resourceC07forKeys3urlSDyAA0B3KeyVypGSayAHG_AA5NSURLCtKF ()
#10 0x00000000006d0735 in $s10Foundation5NSURLC14resourceValues7forKeysSDyAA14URLResourceKeyVypGSayAGG_tKF ()
#11 0x00000000007408db in $s10Foundation3URLV14resourceValues7forKeysAA011URLResourceD0VShyAA0G3KeyVG_tKF ()
#12 0x00000000004edac5 in $s6Server14CatalogHandlerV14callAsFunctionyySDySSypG_y10Foundation4DataVctFTf4dnn_n (sendData=..., self=...)
    at /src/Sources/Server/Handler/CatalogHandler.swift:27
#13 0x0000000000405ca5 in $s10Ambassador12DataResponseV3app_05startC08sendBodyySDySSypG_ySS_SaySS_SStGtcy10Foundation0B0VctF (environ=..., 
    startResponse=..., sendBody=..., self=...) at /src/.build/checkouts/Ambassador/Ambassador/Responses/DataResponse.swift:67
#14 $s10Ambassador12DataResponseVAA6WebAppA2aDP3app_05startC08sendBodyySDySSypG_ySS_SaySS_SStGtcy10Foundation0B0VctFTW ()
    at <compiler-generated>:62
#15 0x0000000000407f50 in $s10Ambassador6RouterC3app_13startResponse8sendBodyySDySSypG_ySS_SaySS_SStGtcy10Foundation4DataVctF (environ=..., 
    startResponse=..., sendBody=..., self=...) at /src/.build/checkouts/Ambassador/Ambassador/Router.swift:53
#16 0x00000000004d3e85 in $s7Embassy17DefaultHTTPServerC19handleNewConnection33_31083D60BDD86CDE5957D686669A6F07LLyyFySDySSypG_ySS_SaySS_SStGtcy10Foundation4DataVctcACcfu_yAF_ySS_AGtcyAJctcfu0_TA () at /src/.build/checkouts/Embassy/Sources/DefaultHTTPServer.swift:109
#17 0x00000000004d7db4 in $s7Embassy14HTTPConnectionC16handleHeaderData33_4BF5AC95662DB43C315E42DBAD465363LLyy10Foundation0E0VF (data=..., 
    self=...) at /src/.build/checkouts/Embassy/Sources/HTTPConnection.swift:174
#18 0x00000000004d6345 in $s7Embassy14HTTPConnectionC3app10serverName0D4Port9transport9eventLoop6logger14closedCallbackACySDySSypG_ySS_SaySS_SStGtcy10Foundation4DataVctc_SSSiAA9TransportCAA05EventI0_pAA6Logger_pyycSgtcfcyAOcfU_ ()
    at /src/.build/checkouts/Embassy/Sources/HTTPConnection.swift:85
#19 0x00000000004eb432 in $s7Embassy9TransportC10handleRead33_D69E68FF1E2243FD768A79B48851153FLLyyF (self=...)
    at /src/.build/checkouts/Embassy/Sources/Transport.swift:150
#20 0x00000000004e7a58 in $s7Embassy17SelectorEventLoopC7runOnce33_06B3F4C0618F0A8F55DD4BB5D7F965B9LLyyF (self=...)
    at /src/.build/checkouts/Embassy/Sources/SelectorEventLoop.swift:223
#21 0x00000000004e7715 in $s7Embassy17SelectorEventLoopC10runForeveryyF (self=...)
    at /src/.build/checkouts/Embassy/Sources/SelectorEventLoop.swift:177
#22 0x00000000004f2ef2 in $s6Server03WebA0V5start4root5aisle10inflectionySS_12ConfigParser04CookG0CSgAKtKF (root=..., aisle=..., inflection=..., 
    self=...) at /src/Sources/Server/WebServer.swift:52
#23 0x00000000004a5754 in $s7CookCLI0A0V6ServerV3runyyKF (self=...) at /src/Sources/CookCLI/Commands/Server.swift:70
#24 0x00000000004a5b8e in $s7CookCLI0A0V6ServerV14ArgumentParser15ParsableCommandAafGP3runyyKFTW ()
    at /src/Sources/CookCLI/Commands/Server.swift:42
#25 0x000000000043131e in $s14ArgumentParser15ParsableCommandPAAE4mainyySaySSGSgFZ (arguments=..., self=...)
    at /src/.build/checkouts/swift-argument-parser/Sources/ArgumentParser/Parsable Types/ParsableCommand.swift:95
#26 0x000000000049ed99 in main () at /src/Sources/CookCLI/main.swift:9

Hope this is helpful.

OS: Ubuntu 22.04.1 LTS x86_64 
Kernel: 5.15.0-47-generic 
Uptime: 4 days, 20 hours, 6 mins 
Packages: 1205 (dpkg), 6 (snap) 
Shell: bash 5.1.16 
Resolution: 1024x768 
Terminal: node 
CPU: AMD Ryzen 9 3950X (32) @ 3.500GHz 
GPU: 22:00.0 ASPEED Technology, Inc. ASPEED Graphics Family 
Memory: 2151MiB / 64234MiB 

[dubadub]

@mjsr @ruudschouten @dpgeekzero thanks for sharing information about the context of an error.

I believe this happens because of recent updates made in Linux. Similar issue reported for statically compiled binaries which use nss library after update to glibc version 2.32+. I tried to avoid using nss https://github.com/cooklang/CookCLI/pull/46, but it seems there're other places which use it internally.

As a workaround you can build cli manually. In that case project will use libraries from your machine and there will be no issues.

In longterm I'm migrating away from Swift because it causes unnecessary issues with cross-platform support. First step is to implement canonical parser in C. Then I'll migrate CLI to go which has great cross-platform support.

Also, you can contribute and add CookCLI to your Linux distribution. See an example for Archlinux.

[mjsr]

@dubadub I'm working on a patch to allow the makefile and scripts to identify the OS and pick the relevant sed args for the build to work properly.

Another interesting I found, specifically within the scripts/inject_seed.sh is that, in Linux, since the output of base64 returns a multi-line string, the sed command fails since it's unable to find the closing s sed command (which, in this case, is the character |). For this particular case, I guess it would be better to read the content from another file since I don't believe embedding data is a good practice. I'll file a separate issue for it (unfortunately, I'm not familiar with Swift to work on that fix but maybe someone is).

Anyway, if I'm able to work around the quirks and get to test this on a Mac after I made my changes, I'll share the results.

[dubadub]

Thanks @mjsr for looking at this. Yeah, embedding is kind of ugly, but allows us to make a portable binary file without any dependencies or installation required.

[mjsr]

@dubadub makes sense. I'll try to work around that although it might be hacky :)

[trentks]

I'm also getting a segfault on a fresh install of Manjaro.

I went to use the aur package cookcli-git and saw how many dependencies needed to be downloaded / built (swift and libs) and noped out of that after waiting like 10 minutes and it having downloaded GB's and GB's, and opted for the cookcli-bin package instead. But it segfaults:

cook seed cook server Started server on http://127.0.0.1:9080, serving cook files from \<path>. zsh: segmentation fault (core dumped) cook server

It'll only segfault after having browsed to the webpage though, and not beforehand.

Sounds like your C implementation will be the long-term solution. Thanks for the project so far, it's very highly correlated with my interests!

cook version v0.1.6 – in food we trust

[trentks]

Ok I spent 4 hours trying to build cooklang-git from the aur, only to have it fail. Ever the optimist, I tried it one more time (another 4 hours), to be met with the same fate.

So it would seem there's no way to get 0.1.6 working on manjaro linux at the present time.

[johnmckinzie]

I just installed the binary today on Pop!_OS 22.04 LTS and I'm also getting the segfault.

[Samuelfaure]

Still happening in Arch, May 2023

[RPGillespie6]

Happening to me in OpenSUSE Tumbleweed under WSL, July 2023

[trentks]

Happening to me in OpenSUSE Tumbleweed under WSL, July 2023

Yeah the project's kinda dead at this stage it seems, pretty sad I was super excited about it (still am). Anyway, I hope the dev and those he cares for are doing well. I think he's Ukrainian.

[dubadub]

Hey, it's not dead, but rather dormant 😅. You can try to compile manually and it should resolve the issue. Alternatively as we're migrating CLI to rust you can check out this PoC https://github.com/Zheoni/cooklang-chef.

[Samuelfaure]

Migrating to Rust is a great idea, I wanted to try and fix the issue myself but Swift isn't the most accessible language for non-Apple users.

[dubadub]

I migrated CLI to Rust and issue should be resolved. You can download binary from the releases. Please, reopen issue if needed.