doxygen-1.9.1 crashes when parsing config file

[ngothan]

Describe the bug
doxygen 1.9.1 crashes when using the following PREDEFINED:

PREDEFINED   = __cplusplus \
                         "LIBSBML_EXTERN:=\"\"" \
                         "LIBNUML_EXTERN:=\"\"" \
                         "LIBSBML_CPP_NAMESPACE_BEGIN:=\"\"" \
                         "LIBNUML_CPP_NAMESPACE_BEGIN:=\"\"" \
                         "LIBSBML_CPP_NAMESPACE_END:=\"\"" \
                         "LIBNUML_CPP_NAMESPACE_END:=\"\"" \
                         SWIG=1 \
                         doxygen_ignore \
                         __cplusplus \
                         "LIBSBML_CPP_NAMESPACE_QUALIFIER:=\"\"" \
                         "LIBSBML_CPP_NAMESPACE_QUALIFIER:=\"\""

To Reproduce
I uploaded the tarball doxygen-crash.tar.gz which includes the example demonstrates the problem. To reproduce this issue just extract the tarball and run "doxygen"

Version
Doxygen 1.9.1, Using the binary from fedora

Stack trace

gdb /usr/bin/doxygen 
GNU gdb (GDB) Fedora 10.1-2.fc34
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/doxygen...
Reading symbols from .gnu_debugdata for /usr/bin/doxygen...
(No debugging symbols found in .gnu_debugdata for /usr/bin/doxygen)
Missing separate debuginfos, use: dnf debuginfo-install doxygen-1.9.1-1.fc34.x86_64
(gdb) run 
Starting program: /usr/bin/doxygen 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
terminate called after throwing an instance of 'std::logic_error'
  what():  basic_string::_M_construct null not valid

Program received signal SIGABRT, Aborted.
0x00007fffedafd282 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x00007fffedafd282 in raise () from /lib64/libc.so.6
#1  0x00007fffedae68a4 in abort () from /lib64/libc.so.6
#2  0x00007fffede92a86 in __gnu_cxx::__verbose_terminate_handler() [clone .cold] () from /lib64/libstdc++.so.6
#3  0x00007fffede9e0ec in __cxxabiv1::__terminate(void (*)()) () from /lib64/libstdc++.so.6
#4  0x00007fffede9e157 in std::terminate() () from /lib64/libstdc++.so.6
#5  0x00007fffede9e3f9 in __cxa_throw () from /lib64/libstdc++.so.6
#6  0x00007fffede9535f in std::__throw_logic_error(char const*) () from /lib64/libstdc++.so.6
#7  0x0000555555be34de in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) [clone .constprop.0] ()
#8  0x0000555555be95ce in substEnvVarsInStrList(std::vector<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> > > >&) ()
#9  0x0000555555be3f0e in ConfigImpl::substituteEnvironmentVars() ()
#10 0x0000555555be50ba in Config::postProcess(bool, bool) ()
#11 0x000055555567a561 in checkConfiguration() ()
#12 0x0000555555662714 in main ()

Additional context
It works fine with 1.8.20

[albert-github]

Looks like that the escaped double quotes are the problem here.
The crashing line is line 1213 in configimpl.l (routine static void substEnvVarsInStrList(StringVector &sl)) i.e. the line:

 results.push_back(result.mid(p,i-p).data());

It looks like that the Doxyfile:

PREDEFINED            = "LIBSBML_EXTERN:=\"\""

already triggers the problem.
Note that the string used in the mentioned routine is LIBSBML_EXTERN:=""

When having:

PREDEFINED            = "LIBSBML_EXTERN:=\"A\""

doxygen doesn't crash, but the output of doxygen -x is incorrect:

PREDEFINED             = A

and the string used in the mentioned routine is LIBSBML_EXTERN:="A"

[albert-github]

@doxygen
I saw the fix 3b15963, but when running doxygen -x on the simple example with just the one liner I get nothing back (expected is PREDEFINED = "LIBSBML_EXTERN:=\"\"").
And for the example from this issue I get:

PREDEFINED             = __cplusplus \
                         \
                         \
                         \
                         \
                         \
                         \
                         SWIG=1 \
                         doxygen_ignore \
                         __cplusplus \
                         \

When starting the doxywizard with the doxygile of the issue no changed predefines are shown.

[doxygen]

@albert-github What I fixed is that an empty string crashes doxygen, i.e. std::string(QCString().data()) crashes whereas std::string(QCString().str()) just produces an empty string. Apparently the empty string was not good in the first place.

[albert-github]

Indeed doxygen does not crash anymore, but it looks like that the output is not what is expected, so I think that we have multiple related problems of which one resulted in a crash and another in the result. In the solution shouldn't also the double quotes be pushed back (and thinking about it probably also the other characters in front of the double quotes)?

[albert-github]

For the second part of the problem I've just pushed a proposed patch, pull request #8344
(Tested with doxywizard as well, doesn't look like to have problems.)

[albert-github]

The code for the second part of the problem has been integrated in master on github (please don't close the issue as this will be done at the moment of an official release).

[doxygen]

This issue was previously marked 'fixed but not released',
which means it should be fixed in doxygen version 1.9.2.
Please verify if this is indeed the case. Reopen the
issue if you think it is not fixed and please include any additional information
that you think can be relevant (preferably in the form of a self-contained example).