VeraCrypt crashes upon entering a password, when using the new volume wizard, with the error displayed on `veracrypt-output.txt`. Upon compiling VeraCrypt without `GLIBCXX_ASSERTIONS`, the program because usable again; however still displaying the error shown in `veracrypt-output-gtk.txt`. Only when compiling `gui-libs/gtk` without `GLIBCXX_ASSERTIONS`, and also having compiled VeraCrypt without `GLIBCXX_ASSERTIONS`, was I able to run VeraCrypt without any errors. Attached is also the backtrace of the original problem. Reproducible: Always Steps to Reproduce: 1. Open VeraCrypt 2. Select "Create Volume" 3. Progress through "Create Volume" Wizard Actual Results: Crashes with `veracrypt-output.txt` dispalyed on console. Expected Results: No crashes
Created attachment 765215 [details] veracrypt-output.txt Original VeraCrypt crash
Created attachment 765216 [details] veracrypt-output-gtk.txt VeraCrypt output (built w/o GLIBCXX_ASSERTIONS)
Created attachment 765217 [details] backtrace.log Backtrace of original VeraCrypt crash
I told Peter to file this bug so we can keep an eye on the upstream one & add a filter-flags for now given it causes a runtime crash.
Turns out when compiling `gui-libs/gtk` without `GLIBCXX_ASSERTIONS`, doesn't solve the output displayed on `veracrypt-output-gtk.txt`. The problem is still present, however it happens to appear less often it may seem.
Would you be able to confirm that this is isolated to 1.25.7 by temporarily downgrading to a previous version? It fails on its way to executing mkfs.ext4. A quick glance at the tag diff doesn't point to anything obvious. The problem is triggered at frame 5: #5 VeraCrypt::Process::Execute(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::list<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, int, VeraCrypt::ProcessExecFunctor*, VeraCrypt::Buffer const*) (processName="mkfs.ext4", arguments=<optimized out>, timeOut=-1, execFunctor=<optimized out>, inputData=0x7fffffffd100) at ../Platform/Unix/Process.cpp:144 Process.cpp line 144 is (https://github.com/veracrypt/VeraCrypt/blob/VeraCrypt_1.25.7/src/Platform/Unix/Process.cpp#L144): bytesRead = read (fd, &buffer[0], buffer.capacity()); where buffer is declared as: vector <char> buffer (4096) Looking at frame 4 in the backtrace, `buffer[0]` triggers ::operator[](unsigned long), which is: reference operator[](size_type __n) _GLIBCXX_NOEXCEPT { __glibcxx_requires_subscript(__n); return *(this->_M_impl._M_start + __n); } So it must be hitting __glibcxx_requires_subscript, which is: define __glibcxx_requires_subscript(_N) \ __glibcxx_assert(_N < this->size()) The parameter `_N` should be 0 in this case. I think I know what the problem is: 121 vector <char> buffer (4096) ... // Sets size to 4096 122 buffer.clear () // Sets size to 0 ... 144 ... &buffer[0] ... // ::operator[0] triggers (_N < this->size()) which fails due to (0 < 0) Most likely the standard library copes with this just fine in general. Apparently clear() is not guaranteed to deallocate the space. In the cases that it does though, this sounds like a possible dangling pointer issue. I think the author meant to accomplish something akin to memset(0) with clear(), not actually ask to deallocate the space.
Created attachment 765219 [details, diff] Possible fix Can you give this patch a try and see if it triggers the assertion?
Yes, this happens on 1.24_p8. Patch testing results, in tow.
Patch didn't apply
Created attachment 765222 [details] Patch Attempt #1 Output
Created attachment 765224 [details, diff] Possible fix v2 Sigh, I forgot that I override ${S} in the ebuild. The patch was against the git repo. This should apply fine now, does so on my machine.
Yep, it applied now. No error, we're good.
Thank you, Göktürk for your promptness and effort.
Upstream have adopted a different patch: https://github.com/veracrypt/VeraCrypt/commit/b52ce86040e25dc5906adab872558547355b5637.
