integration tests_ok/cookie_jar fails

[apparentorder]

What is the current bug behavior?

[... lots of tests passing ...]
tests_ok/charset.sh
tests_ok/color.sh
tests_ok/compressed.sh
tests_ok/compressed_option.sh
tests_ok/connect_to.sh
tests_ok/cookie_file.sh
tests_ok/cookie_jar.sh
>>> error in stdout
actual: <b'# Netscape HTTP Cookie File\n# This file was generated by Hurl\n\n#HttpOnly_localhost\tFALSE\t/accounts\tFALSE\t2147483647\tLSID\tDQAAAKEaem_vYg\n#HttpOnly_.localhost\tTRUE\t/\tFALSE\t2147483647\tHSID\tAYQEVnDKrdst\n#HttpOnly_.localhost\tTRUE\t/\tFALSE\t2147483647\tSSID\tAp4PGTEq\n'>
expected: <b'# Netscape HTTP Cookie File\n# This file was generated by Hurl\n\n#HttpOnly_localhost\tFALSE\t/accounts\tFALSE\t3409338181\tLSID\tDQAAAKEaem_vYg\n#HttpOnly_.localhost\tTRUE\t/\tFALSE\t3409338181\tHSID\tAYQEVnDKrdst\n#HttpOnly_.localhost\tTRUE\t/\tFALSE\t3409338181\tSSID\tAp4PGTEq\n'>

Steps to reproduce

• git clone
• git checkout 4.0.0 # but it fails on master/4.1.0-SNAPSHOT too
• follow CONTRIBUTING.md (cargo build, setup venv, python3 integration.py)

What is the expected correct behavior?

test passes

Execution context

The only difference between expected and actual is one column, which should be 3409338181 but is actually 2147483647 – which is i32::MAX.

The environment is an Arm CPU (Graviton / aarch64) machine running Amazon Linux 2023, with rustc 1.71.1 (eb26296b5 2023-08-03).

[fabricereix]

Can you try with curl?

curl http://localhost:8000/cookie-jar --cookie-jar build/cookies.txt
cat build/cookies.txt

[apparentorder]

curl looks ok:

(.venv) [ec2-user@ip-172-31-1-33 integration]$ curl http://localhost:8000/cookie-jar --cookie-jar build/cookies.txt
(.venv) [ec2-user@ip-172-31-1-33 integration]$ cat build/cookies.txt
# Netscape HTTP Cookie File
# https://curl.se/docs/http-cookies.html
# This file was generated by libcurl! Edit at your own risk.

#HttpOnly_.localhost	TRUE	/	FALSE	3409338181	SSID	Ap4PGTEq
#HttpOnly_.localhost	TRUE	/	FALSE	3409338181	HSID	AYQEVnDKrdst
#HttpOnly_localhost	FALSE	/accounts	FALSE	3409338181	LSID	DQAAAKEaem_vYg

[fabricereix]

Have you build Hurl in debug or release mode?
you may try in debug mode (cargo build), it might show a panic.

I'm not sure how to set up the same environment as yours to reproduce the bug.
Should I use an EC2 instance?

[apparentorder]

Yes, it was built with cargo build.

Yes, it's an EC2 instance with Arm (t4g.medium) with Amazon Linux 2023.

I can provide SSH access to an instance for a few days, if you're not familiar with AWS; you could e-send me an SSH Pubkey to [email protected]. And/or if you have a hunch about where this is happening, I could take a look at the source code myself. Just wanted to finish up the aws-sigv4 PR first.

[fabricereix]

ok we can finalize your aws-sigv4 PR first.
You can simply delete the file tests_ok/cookie_jar.sh for the time-being on your machine so that you can run all integ tests.
Once merged, we will investigate the bug.

[apparentorder]

I have some news here:

The issue is clearly triggered in libcurl somehow, as curl's debug output already shows the wrong unixtime:

* Added cookie LSID="DQAAAKEaem_vYg" for domain localhost, path /accounts, expire 2147483647

This bug is neither arch- nor OS-dependent. I have reproduced it on x86-64 and on Ubuntu.

It turns out that I had not installed libcurl-devel, and rust-curl silently falls back to some bundled libcurl.

The bug appears when rust-curl is using that bundled libcurl (alexcrichton/curl-rust#523). When libcurl-devel is present during build, the resulting binary is properly linked against the system-wide libcurl, and the bug does not appear:

* Added cookie LSID="DQAAAKEaem_vYg" for domain localhost, path /accounts, expire 3409338181

A very simple test program using rust-curl can reproduce this, so it's definitely not an issue in Hurl.

Might be a good idea though to add a check to Hurl's tests though, to make sure the produced hurl binaries do actually use the system-provided libcurl. Other than that, we could close this issue, I guess.

[fabricereix]

Yes, a check is a very good idea. we have already had issues related to this implicit static build.