Crashes when --env-file=file does not have a newline at the end

[vignedev]

Version

v22.10.0

Platform

Linux vigbox 6.11.3-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 10 Oct 2024 20:11:06 +0000 x86_64 GNU/Linux

Subsystem

No response

What steps will reproduce the bug?

1. Create a file with a quoted value and no new line at the end (eg. printf 'API_KEY="inaaa"' > .env)
2. Run node --env-file=.env

How often does it reproduce? Is there a required condition?

Always, if the --env-file file has no newline at the end, and if the value before it is surrounded with quotes.

What is the expected behavior? Why is that the expected behavior?

For node to not crash, and for it to parse the value into process.env.

What do you see instead?

$ node --version
v22.10.0

$ printf 'API_KEY="inaaa"' > .env

$ xxd .env # just to make sure there is no newline at the end
00000000: 4150 495f 4b45 593d 2269 6e61 6161 22    API_KEY="inaaa"

$ node --env-file=.env
/usr/include/c++/14.2.1/string_view:297: constexpr void std::basic_string_view<_CharT, _Traits>::remove_prefix(size_type) [with _CharT = char; _Traits = std::char_traits<char>; size_type = long unsigned int]: Assertion 'this->_M_len >= __n' failed.
Aborted (core dumped)

Additional information

No response

[juanarbol]

Thanks for the bug report. Sadly I can't repro using your repro case

Nor in my macos machine, nor in my linux vm

[vignedev]

Huh, interesting. I tested it with a fresh Fedora 41 Workstation VM and the crash happens here as well.

Installed using sudo dnf install nodejs.

[RedYetiDev]

a few questions:
A) is this reproducible in v22.11.0?
B) is the file's encoding properly set?
C) what does running a backtrace on the crash tell you?

[vignedev]

Interestingly enough, it indeed did not happen on Ubuntu x86_64 VM:

It also did not happen on Termux:

...nor did it happen on my old Raspberry Pi 3:

vignette@raspberrypi:/tmp $ printf 'API_KEY="inaaa"' > .env
vignette@raspberrypi:/tmp $ xxd .env
00000000: 4150 495f 4b45 593d 2269 6e61 6161 22    API_KEY="inaaa"
vignette@raspberrypi:/tmp $ node -v
v22.11.0
vignette@raspberrypi:/tmp $ node --env-file=.env
Welcome to Node.js v22.11.0.
Type ".help" for more information.
> 
vignette@raspberrypi:/tmp $ uname -a
Linux raspberrypi 6.6.51+rpt-rpi-v7 #1 SMP Raspbian 1:6.6.51-1+rpt3 (2024-10-08) armv7l GNU/Linux

[vignedev]

@RedYetiDev
a few questions:
A) is this reproducible in v22.11.0?
B) is the file's encoding properly set?
C) what does running a backtrace on the crash tell you?

A) Can't currently get my hands on v22.11.0 on my Arch machine, however it does still occur on v23.1.0

$ node -v
v23.1.0

$ printf 'API_KEY="inaaa"' > .env

$ xxd .env
00000000: 4150 495f 4b45 593d 2269 6e61 6161 22    API_KEY="inaaa"

$ node --env-file=.env
/usr/include/c++/14.2.1/string_view:297: constexpr void std::basic_string_view<_CharT, _Traits>::remove_prefix(size_type) [with _CharT = char; _Traits = std::char_traits<char>; size_type = long unsigned int]: Assertion 'this->_M_len >= __n' failed.
[1]    83922 IOT instruction (core dumped)  node --env-file=.env

B) From the looks of it, is should be a valid ASCII file, even to the xxd hexdump, if I am not mistaken.

C) Appending a gdb with bt after the crash:

(gdb) bt
#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1  0x00007ffff6ca5463 in __pthread_kill_internal (threadid=<optimized out>, signo=6) at pthread_kill.c:78
#2  0x00007ffff6c4c120 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3  0x00007ffff6c334c3 in __GI_abort () at abort.c:79
#4  0x00007ffff6ed3af0 in std::__glibcxx_assert_fail (file=file@entry=0x555557c1dc58 "/usr/include/c++/14.2.1/string_view", line=line@entry=297, 
    function=function@entry=0x555557c1dbb0 "constexpr void std::basic_string_view<_CharT, _Traits>::remove_prefix(size_type) [with _CharT = char; _Traits = std::char_traits<char>; size_type = long unsigned int]", 
    condition=condition@entry=0x5555584ff864 "this->_M_len >= __n") at /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/assert_fail.cc:41
#5  0x0000555556016020 in std::basic_string_view<char, std::char_traits<char> >::remove_prefix (this=<synthetic pointer>, __n=<optimized out>) at /usr/include/c++/14.2.1/string_view:295
#6  std::basic_string_view<char, std::char_traits<char> >::remove_prefix (this=<optimized out>, __n=<optimized out>) at /usr/include/c++/14.2.1/string_view:295
#7  node::Dotenv::ParseContent (this=this@entry=0x5555590793e0 <node::per_process::dotenv_file>, input=...) at ../src/node_dotenv.cc:136
#8  0x0000555556017841 in node::Dotenv::ParsePath (this=this@entry=0x5555590793e0 <node::per_process::dotenv_file>, path=...) at ../src/node_dotenv.cc:276
#9  0x0000555555fc1485 in node::InitializeNodeWithArgsInternal (argv=<optimized out>, exec_argv=<optimized out>, errors=<optimized out>, flags=flags@entry=node::ProcessInitializationFlags::kNoFlags) at ../src/node.cc:860
#10 0x0000555555fc2e85 in node::InitializeOncePerProcessInternal (args=std::vector of length 2, capacity 2 = {...}, flags=flags@entry=node::ProcessInitializationFlags::kNoFlags) at ../src/node.cc:1003
#11 0x0000555555fc6284 in node::StartInternal (argc=<optimized out>, argv=<optimized out>) at ../src/node.cc:1432
#12 node::Start (argc=<optimized out>, argv=<optimized out>) at ../src/node.cc:1491
#13 0x00007ffff6c34e08 in __libc_start_call_main (main=main@entry=0x555555ef8210 <main(int, char**)>, argc=argc@entry=2, argv=argv@entry=0x7fffffffd1c8) at ../sysdeps/nptl/libc_start_call_main.h:58
#14 0x00007ffff6c34ecc in __libc_start_main_impl (main=0x555555ef8210 <main(int, char**)>, argc=2, argv=0x7fffffffd1c8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffd1b8) at ../csu/libc-start.c:360
#15 0x0000555555eff615 in _start ()
(gdb) 

[RedYetiDev]

Maybe it's Fedora specific?

[vignedev]

Maybe it's Fedora specific?

It also happened on Arch Linux, on NodeJs 22.10.0 and 23.1.0.

[islandryu]

The presence of __glibcxx_assert_fail suggests that the build was likely compiled with _GLIBCXX_ASSERTIONS enabled.
I tested the same conditions with _GLIBCXX_ASSERTIONS explicitly enabled and encountered the error.

However, it's puzzling that the stack trace lines differ from mine.

(gdb) bt
#0  0x0000ffffa799e020 in __pthread_kill_implementation () from /lib64/libc.so.6
#1  0x0000ffffa794b140 [PAC] in raise () from /lib64/libc.so.6
#2  0x0000ffffa79359c8 [PAC] in abort () from /lib64/libc.so.6
#3  0x0000ffffa7cc20c8 [PAC] in std::__glibcxx_assert_fail(char const*, int, char const*, char const*) () from /lib64/libstdc++.so.6
#4  0x000000000195c634 [PAC] in std::basic_string_view<char, std::char_traits<char> >::remove_prefix (this=0xffffd0a72938, __n=18446744073709551615) at /usr/include/c++/14/string_view:297
#5  0x000000000195b98c [PAC] in node::Dotenv::ParseContent (this=0x8c3adf8 <node::per_process::dotenv_file>, input="API_KEY=\"inaaa\"") at ../../src/node_dotenv.cc:185
#6  0x000000000195be60 [PAC] in node::Dotenv::ParsePath (this=0x8c3adf8 <node::per_process::dotenv_file>, path=".env") at ../../src/node_dotenv.cc:276
#7  0x00000000018dceb4 [PAC] in node::InitializeNodeWithArgsInternal (argv=0xe11eda0, exec_argv=0xe11edb8, errors=0xe11edd0, flags=node::ProcessInitializationFlags::kNoFlags) at ../../src/node.cc:860
#8  0x00000000018dd650 [PAC] in node::InitializeOncePerProcessInternal (args=std::vector of length 2, capacity 2 = {...}, flags=node::ProcessInitializationFlags::kNoFlags) at ../../src/node.cc:1003
#9  0x00000000018de97c [PAC] in node::StartInternal (argc=2, argv=0xe11ece0) at ../../src/node.cc:1432
#10 0x00000000018ded04 [PAC] in node::Start (argc=2, argv=0xffffd0a753f8) at ../../src/node.cc:1491
#11 0x0000000003935f54 [PAC] in main (argc=2, argv=0xffffd0a753f8) at ../../src/[node_main.cc:97](http://node_main.cc:97/)

[LiviaMedeiros]

@vignedev Can you confirm if the issue is fixed after 3bb1d28?