attempt to dereference a singular iterator

[Jivanmukta]

I don't understand what's wrong in my code:

std::vector<std::wstring> vendor_frameworks_dirs;
...
for (auto dir = vendor_frameworks_dirs.begin(); dir !=
vendor_frameworks_dirs.end(); ++dir)

Error:

/usr/include/c++/9/debug/safe_iterator.h:294:
In function:
__gnu_debug::_Safe_iterator<_Iterator, _Sequence,
_Category>::reference
__gnu_debug::_Safe_iterator<_Iterator, _Sequence,
_Category>::operator*() const [with _Iterator =
__gnu_cxx::__normal_iterator<std::__cxx11::basic_string<wchar_t>*,
std::__cxx1998::vector<std::__cxx11::basic_string<wchar_t>,
std::allocator<std::__cxx11::basic_string<wchar_t> > > >; _Sequence =
std::__debug::vector<std::__cxx11::basic_string<wchar_t> >;
_Category =
std::forward_iterator_tag; __gnu_debug::_Safe_iterator<_Iterator,
_Sequence, _Category>::reference =
std::__cxx11::basic_string<wchar_t>&]

Error: attempt to dereference a singular iterator.

Objects involved in the operation:
iterator "this" @ 0x0x7fffffffadc0 {
type =
__gnu_cxx::__normal_iterator<std::__cxx11::basic_string<wchar_t,
std::char_traits<wchar_t>, std::allocator<wchar_t> >*,
std::__cxx1998::vector<std::__cxx11::basic_string<wchar_t,
std::char_traits<wchar_t>, std::allocator<wchar_t> >,
std::allocator<std::__cxx11::basic_string<wchar_t,
std::char_traits<wchar_t>, std::allocator<wchar_t> > > > > (mutable
iterator);
state = singular;
references sequence with type
'std::__debug::vector<std::__cxx11::basic_string<wchar_t,
std::char_traits<wchar_t>, std::allocator<wchar_t> >,
std::allocator<std::__cxx11::basic_string<wchar_t,
std::char_traits<wchar_t>, std::allocator<wchar_t> > > >' @ 0x0x61a0000bd680
}
/usr/include/c++/9/debug/safe_iterator.h:294:
In function:
__gnu_debug::_Safe_iterator<_Iterator, _Sequence,
_Category>::reference
__gnu_debug::_Safe_iterator<_Iterator, _Sequence,
_Category>::operator*() const [with _Iterator =
__gnu_cxx::__normal_iterator<std::__cxx11::basic_string<wchar_t>*,
std::__cxx1998::vector<std::__cxx11::basic_string<wchar_t>,
std::allocator<std::__cxx11::basic_string<wchar_t> > > >; _Sequence =
std::__debug::vector<std::__cxx11::basic_string<wchar_t> >;
_Category =
std::forward_iterator_tag; __gnu_debug::_Safe_iterator<_Iterator,
_Sequence, _Category>::reference =
std::__cxx11::basic_string<wchar_t>&]

Error: attempt to dereference a singular iterator.

Objects involved in the operation:
iterator "this" @ 0x0x7fffffffadc0 {
type =
__gnu_cxx::__normal_iterator<std::__cxx11::basic_string<wchar_t,
std::char_traits<wchar_t>, std::allocator<wchar_t> >*,
std::__cxx1998::vector<std::__cxx11::basic_string<wchar_t,
std::char_traits<wchar_t>, std::allocator<wchar_t> >,
std::allocator<std::__cxx11::basic_string<wchar_t,
std::char_traits<wchar_t>, std::allocator<wchar_t> > > > > (mutable
iterator);
state = singular;
references sequence with type
'std::__debug::vector<std::__cxx11::basic_string<wchar_t,
std::char_traits<wchar_t>, std::allocator<wchar_t> >,
std::allocator<std::__cxx11::basic_string<wchar_t,
std::char_traits<wchar_t>, std::allocator<wchar_t> > > >' @ 0x0x61a0000bd680
}
iterator "this" @ 0x0x7fffffffadc0 {
type =
__gnu_cxx::__normal_iterator<std::__cxx11::basic_string<wchar_t,
std::char_traits<wchar_t>, std::allocator<wchar_t> >*,
std::__cxx1998::vector<std::__cxx11::basic_string<wchar_t,
std::char_traits<wchar_t>, std::allocator<wchar_t> >,
std::allocator<std::__cxx11::basic_string<wchar_t,
std::char_traits<wchar_t>, std::allocator<wchar_t> > > > > (mutable
iterator);
state = singular;
references sequence with type
'std::__debug::vector<std::__cxx11::basic_string<wchar_t,
std::char_traits<wchar_t>, std::allocator<wchar_t> >,
std::allocator<std::__cxx11::basic_string<wchar_t,
std::char_traits<wchar_t>, std::allocator<wchar_t> > > >' @ 0x0x61a0000bd680
}

[Jivanmukta]

W dniu 28.09.2022 o 13:53, Jivanmukta pisze:

> I don't understand what's wrong in my code:
>
> std::vector<std::wstring> vendor_frameworks_dirs;
> ...
> for (auto dir = vendor_frameworks_dirs.begin(); dir !=
> vendor_frameworks_dirs.end(); ++dir)

In a line below I use value of *dir

[Juha Nieminen]

Jivanmukta <jivan...@poczta.onet.pl> wrote:
> I don't understand what's wrong in my code:
>
> std::vector<std::wstring> vendor_frameworks_dirs;
> ...
> for (auto dir = vendor_frameworks_dirs.begin(); dir !=
> vendor_frameworks_dirs.end(); ++dir)
>
> Error:

Please write and post a minimal full program that demonstrates the
problem.

[Jivanmukta]

W dniu 28.09.2022 o 14:19, Juha Nieminen pisze:

I failed to reproduce problem in isolated code - works fin
e.
I cannot post my application's source code - it's big.

[JiiPee]

On 28/09/2022 18:08, Jivanmukta wrote:
> I cannot post my application's source code - it's big.

he is not asking to to post all of it. He is asking to post a short,
maybe 10 lines code, where the error exists

[JiiPee]

*dir = L"jk";


I am using *dir there, compiles ok

[Paavo Helde]

28.09.2022 14:53 Jivanmukta kirjutas:
> I don't understand what's wrong in my code:
>
> std::vector<std::wstring> vendor_frameworks_dirs;
> ...
> for (auto dir = vendor_frameworks_dirs.begin(); dir !=
> vendor_frameworks_dirs.end(); ++dir)
>

> Error: attempt to dereference a singular iterator.

Most likely, the size of vendor_frameworks_dirs changes while in the
loop, causing reallocation and invalidation of all iterators. Use
indexes instead of iterators if this modification happens in your loop,
or use proper mutex locks if the modification comes from another thread.

[Jivanmukta]

W dniu 28.09.2022 o 17:52, JiiPee pisze:

> On 28/09/2022 18:08, Jivanmukta wrote:
>> I cannot post my application's source code - it's big.
>
> he is not asking to to post all of it. He is asking to post a short

> maybe 10 lines code, where the error exists

I noticed that the problem occurs in many places in code, even if I
don't use iterator. For example when I debug:

if (vendor_dir != L"")
{
TRACE("vendor directory: " << shortwstr2str(vendor_dir));

when I step through if (vendor_dir != L"") problem occurs:

Exception occured
Aborted

in /usr/include/c++/9/debug/safe_iterator.h:

/**
* @brief Iterator dereference.
* @pre iterator is dereferenceable
*/
reference
operator*() const _GLIBCXX_NOEXCEPT
{
_GLIBCXX_DEBUG_VERIFY(this->_M_dereferenceable(), // Aborted
_M_message(__msg_bad_deref)
._M_iterator(*this, "this"));
return *base();
}

Although there's no iterator dereference in line if (vendor_dir != L"").
Reinstalling codium and gdb does not help.

[Jivanmukta]

W dniu 28.09.2022 o 18:21, Paavo Helde pisze:

vendor_frameworks_dirs is not modified in my loop.

[Jivanmukta]

W dniu 28.09.2022 o 17:52, JiiPee pisze:

I have two versions of function obfuscate_application(). The problem
occurs in /* commented out */ version (in random places of the code),
the version not commented out (older, below) works fine.

/*
bool obfuscator::obfuscate_application(bool remember_and_replace_strings)
{ // main algorithm
runtime_error err("save_cache() failed");
TRACE("ready to remember 3rd party identifiers");
if (!third_party_dirs.empty() && !php_cache.is_third_party_cached())
{
OUTPUT("Remembering 3rd party identifiers - this will take some
time but it is performed only once" << endl);
for (auto third_party_dir = third_party_dirs.begin();
third_party_dir != third_party_dirs.end(); ++third_party_dir)
{
if (!perform_remember_third_party_identifiers(L"",
*third_party_dir))
{
return false;
}
if (!php_cache.save_third_party_cache(*third_party_dir,
magic_str, third_party_identifiers[L""]))
{
error_messages.push_back("Data not written to file
dirtyphp_cache_3rd_parties.xml.");
throw err;
} else {
TRACE("saved cache: " << *third_party_dir);
}
}
}
TRACE("ready to remember framework identifiers");
if (framework_dir != L"" && !php_cache.is_framework_cached())
{
TRACE("framework directory: " << shortwstr2str(framework_dir));
OUTPUT("Remembering framework identifiers - this will take some
time but it is performed only once" << endl);
if (!perform_remember_framework_identifiers(L"", framework_dir))
{
return false;
}
if (!php_cache.save_framework_cache(framework_dir, magic_str,
framework_identifiers[L""]))
{
error_messages.push_back("Data not written to file
dirtyphp_cache_frameworks.xml.");
throw err;
} else {
TRACE("saved cache: " << framework_dir);
}
}
TRACE("ready to remember vendors identifiers");

if (vendor_dir != L"")
{
TRACE("vendor directory: " << shortwstr2str(vendor_dir));

if (!php_cache.is_vendor_cached())
{
if (!php_cache.save_vendor_cache(vendor_dir, implode(",",
vendor_frameworks), implode(L",", vendor_frameworks_dirs), implode(L",",
vendor_third_parties_dirs)))
{
error_messages.push_back("Data not written to file
dirtyphp_cache_vendors.xml.");
throw err;
} else {
TRACE("saved cache: " << vendor_dir);
}
}
string text = "Remembering vendor's identifiers - this will
take some time but it is performed only once...";
bool outputted = false; // output text only before first dir
auto dir = vendor_frameworks_dirs.begin();
for (; dir != vendor_frameworks_dirs.end(); )
{
TRACE("1");
*dir;
TRACE("2");
// TRACE("vendor framework dir: " << *dir);
if (!php_cache.is_vendor_subdir_cached(vendor_dir +
dir_separator + *dir)) {
if (!outputted) {
OUTPUT(text << endl);
outputted = true;
}
if (!perform_remember_framework_identifiers(*dir,
vendor_dir + dir_separator + *dir))
{
return false;
}
if (!php_cache.save_framework_cache(vendor_dir +
dir_separator + *dir, magic_str, framework_identifiers[*dir]))
{
error_messages.push_back("Data not written to file
dirtyphp_cache_frameworks.xml.");
throw err;
} else {
TRACE("saved cache: " << *dir);
}
}
++dir;
}
for (auto dir = vendor_third_parties_dirs.begin(); dir !=
vendor_third_parties_dirs.end(); ++dir)
{
if (!php_cache.is_vendor_subdir_cached(vendor_dir +
dir_separator + *dir))
{
TRACE("vendor third party dir: " << *dir);
if (!outputted) {
OUTPUT(text << endl);
outputted = true;
}
if (!perform_remember_third_party_identifiers(*dir,
vendor_dir + dir_separator + *dir))
{
return false;
}
if (!php_cache.save_third_party_cache(vendor_dir +
dir_separator + *dir, magic_str, third_party_identifiers[*dir]))
{
error_messages.push_back("Data not written to file
dirtyphp_cache_3rd_parties.xml.");
throw err;
} else {
TRACE("saved cache: " << *dir);
}
}
}
if (outputted) {
text = "...End of remembering vendor's identifiers";
OUTPUT(text << endl);
}
}
TRACE("1:" << (vendor_frameworks_dirs.size() == 0));
TRACE("2:" << (framework_identifiers.find(L"") ==
framework_identifiers.end()));
assert(vendor_frameworks_dirs.size() == 0 ||
framework_identifiers.find(L"") == framework_identifiers.end());
TRACE("ready to remember identifiers");
if (obfuscate_variables_in_views)
{
TRACE("obfuscating variables in views");
}
else
{
TRACE("not obfuscating variables in views");
}
if (!php_cache.is_application_cached())
{
if (subdirs.empty())
{
if (!perform_remember_identifiers(php_result_dir))
{
return false;
}
}
else
{
for (auto subdir = subdirs.begin(); subdir !=
subdirs.end(); ++subdir)
{
if (!perform_remember_identifiers(*subdir))
{
return false;
}
}
}
// !!! KONIECZNIE NAPRAWIĆ BŁĄD: bez strs: <strings
filepath="src/Kernel.php" />
if (!php_cache.save_application_cache(php_application_dir,
php_result_dir, cache_options.c_str(), magic_str, identifiers))
{
error_messages.push_back("Data not written to file
dirtyphp_cache_applications.xml.");
throw err;
} else {
TRACE("saved cache: " << php_application_dir);
}
}
TRACE("ready to generate random identifiers");
perform_generate_random_identifiers();
TRACE("ready to replace identifiers");
if (subdirs.empty())
{
if (!perform_replace_identifiers(php_result_dir))
{
return false;
}
}
else
{
for (auto subdir = subdirs.begin(); subdir != subdirs.end();
++subdir)
{
if (!perform_replace_identifiers(*subdir))
{
return true;
}
}
}
TRACE("before checking remember_and_replace_strings");
if (remember_and_replace_strings)
{
TRACE("ready to remember and replace strings");
if (php_cache.is_application_cached())
{
// skopiuj apostrophed_strings z cache:
//
assert(php_cache.application_apostrophed_strings.size() > 0);
for (auto &p : php_cache.application_apostrophed_strings)
{
apostrophed_strings_map *ptr = new
apostrophed_strings_map();
for (auto q = (p.second)->begin(); q !=
(p.second)->end(); ++q)
{
assert(!ends_with(q->first,
apostrophed_strings_map::random_identifiers_suffix));
ptr->insert(*q);
}
apostrophed_strings.insert(make_pair(p.first, ptr));
// ptr deallocated in obfuscator::~obfuscator()
}
TRACE("apostrophed_strings filled from cache, " <<
apostrophed_strings.size() << " maps");
}
else
{
TRACE("apostrophed_strings not filled from cache, maps will
be allocated in perform_remember_and_replace_strings()");
}
if (subdirs.empty())
{
TRACE("calling perform_remember_and_replace_strings() for
php_result_dir");
if (!perform_remember_and_replace_strings(php_result_dir))
{
return false;
}
}
else
{
for (auto subdir = subdirs.begin(); subdir !=
subdirs.end(); ++subdir)
{
TRACE("calling perform_remember_and_replace_strings()
for subdir: " << *subdir);
if (!perform_remember_and_replace_strings(*subdir))
{
return false;
}
}
}
}
*/
/* if (!php_cache.save_framework_cache(framework_dir, magic_str,
framework_identifiers)) {
error_messages.push_back("Error writing to file
dirtyphp_cache_frameworks.xml.");
throw runtime_error("save_cache() failed");
}
if (!php_cache.save_third_party_cache(third_party_dir, magic_str,
third_party_identifiers)) {
error_messages.push_back("Error writing to file
dirtyphp_cache_3rd_parties.xml.");
throw runtime_error("save_cache() failed");
}
if (!php_cache.save_application_cache(php_application_dir,
cache_options.c_str(), magic_str, identifiers)) {
error_messages.push_back("Error writing to file
dirtyphp_cache_applications.xml.");
throw runtime_error("save_cache() failed");
}
*/
/*
TRACE("done");
return true;
}
*/



bool obfuscator::obfuscate_application(bool
remember_and_replace_strings) { // main algorithm
TRACE("ready to remember 3rd party identifiers");
if (!third_party_dirs.empty() && !php_cache.is_third_party_cached()) {
OUTPUT("Remembering 3rd party identifiers - this will take some
time but it is performed only once" << endl);
// for (wstring third_party_dir : third_party_dirs) {
for (auto third_party_dir = third_party_dirs.begin();
third_party_dir != third_party_dirs.end(); ++third_party_dir) {
if (!perform_remember_third_party_identifiers(L"",
*third_party_dir)) {
return false;
}
}
}
TRACE("ready to remember framework identifiers");
if (framework_dir != L"" && !php_cache.is_framework_cached()) {
TRACE("framework directory: " << shortwstr2str(framework_dir));
OUTPUT("Remembering framework identifiers - this will take some
time but it is performed only once" << endl);
if (!perform_remember_framework_identifiers(L"", framework_dir)) {
return false;
}
}
TRACE("ready to remember vendors identifiers");

if (vendor_dir != L"") {
TRACE("vendor directory: " << shortwstr2str(vendor_dir));

// for (wstring dir : vendor_frameworks_dirs) {

for (auto dir = vendor_frameworks_dirs.begin(); dir !=

vendor_frameworks_dirs.end(); ++dir) {
if (!php_cache.is_vendor_subdir_cached(*dir)) {
if (!perform_remember_framework_identifiers(*dir,
vendor_dir + dir_separator + *dir)) {
return false;
}
}
}
// for (wstring dir : vendor_third_parties_dirs) {
for (auto dir = vendor_third_parties_dirs.begin(); dir !=
vendor_third_parties_dirs.end(); ++dir) {
if (!php_cache.is_vendor_subdir_cached(*dir)) {
if (!perform_remember_third_party_identifiers(*dir,
vendor_dir + dir_separator + *dir)) {
return false;
}
}
}
}
assert(vendor_frameworks_dirs.size() == 0 ||
framework_identifiers.find(L"") == framework_identifiers.end());
TRACE("ready to remember identifiers");
if (obfuscate_variables_in_views) {
TRACE("obfuscating variables in views");
} else {
TRACE("not obfuscating variables in views");
}
if (!php_cache.is_application_cached()) {
if (subdirs.empty()) {
if (!perform_remember_identifiers(php_result_dir)) {
return false;
}
} else {
// for (wstring subdir : subdirs) {
for (auto subdir = subdirs.begin(); subdir !=
subdirs.end(); ++subdir) {
if (!perform_remember_identifiers(*subdir)) {
return false;
}
}
}
}
TRACE("ready to generate random identifiers");
perform_generate_random_identifiers();
TRACE("ready to replace identifiers");
if (subdirs.empty()) {
if (!perform_replace_identifiers(php_result_dir)) {
return false;
}
} else {
// for (wstring subdir : subdirs) {
for (auto subdir = subdirs.begin(); subdir != subdirs.end();
++subdir) {
if (!perform_replace_identifiers(*subdir)) {
return true;
}
}
}
if (remember_and_replace_strings) {
TRACE("ready to remember and replace strings");
if (php_cache.is_application_cached()) {
// skopiuj apostrophed_strings z cache:
// assert(php_cache.application_apostrophed_strings.size() > 0);
for (auto &p : php_cache.application_apostrophed_strings) {
apostrophed_strings_map *ptr = new
apostrophed_strings_map();
for (auto q = (p.second)->begin(); q !=
(p.second)->end(); ++q) {
ptr->insert(*q);
}
apostrophed_strings.insert(make_pair(p.first, ptr));
// ptr deallocated in obfuscator::~obfuscator()
}
TRACE("apostrophed_strings filled from cache, " <<
apostrophed_strings.size() << " maps");
} else {
TRACE("apostrophed_strings not filled from cache, maps will
be allocated in perform_remember_and_replace_strings()");
}
if (subdirs.empty()) {
if (!perform_remember_and_replace_strings(php_result_dir)) {
return false;
}
} else {
// for (wstring subdir : subdirs) {
for (auto subdir = subdirs.begin(); subdir !=
subdirs.end(); ++subdir) {
if (!perform_remember_and_replace_strings(*subdir)) {
return false;
}
}
}
}
runtime_error err("save_cache() failed");
if (framework_dir != L"") {
if (!php_cache.save_framework_cache(framework_dir, magic_str,
framework_identifiers[L""])) {
error_messages.push_back("Error writing to file
dirtyphp_cache_frameworks.xml.");
throw err;
}
}
// for (wstring subdir : vendor_frameworks_dirs) {
for (auto subdir = vendor_frameworks_dirs.begin(); subdir !=
vendor_frameworks_dirs.end(); ++subdir) {
if (!php_cache.save_framework_cache(vendor_dir + dir_separator
+ *subdir, magic_str, framework_identifiers[*subdir])) {
error_messages.push_back("Error writing to file
dirtyphp_cache_frameworks.xml.");
throw err;
}
}
if (!third_party_dirs.empty()) {
// for (wstring third_party_dir : third_party_dirs) {
for (auto third_party_dir = third_party_dirs.begin();
third_party_dir != third_party_dirs.end(); ++third_party_dir) {
if (!php_cache.save_third_party_cache(*third_party_dir,
magic_str, third_party_identifiers[L""])) {
error_messages.push_back("Error writing to file
dirtyphp_cache_3rd_parties.xml.");
throw err;
}
}
}
// for (wstring subdir : vendor_third_parties_dirs) { // mimo że
vendor_third_parties_dirs == [ L"composer", L"psr" ] subdir przyjmuje
wartość L"" a nie powinno - BŁĄD!!!
for (auto subdir = vendor_third_parties_dirs.begin(); subdir !=
vendor_third_parties_dirs.end(); ++subdir) { // mimo że
vendor_third_parties_dirs == [ L"composer", L"psr" ] subdir przyjmuje
wartość L"" a nie powinno - BŁĄD!!!
if (!php_cache.save_third_party_cache(vendor_dir +
dir_separator + *subdir, magic_str, third_party_identifiers[*subdir])) {
error_messages.push_back("Error writing to file
dirtyphp_cache_3rd_parties.xml.");
throw err;

}
}
if (vendor_dir != L"") {

if (!php_cache.save_vendor_cache(vendor_dir, implode(",",
vendor_frameworks), implode(L",", vendor_frameworks_dirs), implode(L",",
vendor_third_parties_dirs))) {
error_messages.push_back("Error writing to file
dirtyphp_cache_vendors.xml.");
throw err;
}
}
// !!! KONIECZNIE NAPRAWIĆ BŁĄD: bez strs: <strings
filepath="src/Kernel.php" />
if (!php_cache.save_application_cache(php_application_dir,
php_result_dir, cache_options.c_str(), magic_str, identifiers)) {
error_messages.push_back("Error writing to file
dirtyphp_cache_applications.xml.");
throw err;
}
TRACE("done");
return true;
}

[Juha Nieminen]

Jivanmukta <jivan...@poczta.onet.pl> wrote:
> W dniu 28.09.2022 o 17:52, JiiPee pisze:
>> On 28/09/2022 18:08, Jivanmukta wrote:
>>> I cannot post my application's source code - it's big.
>>
>> he is not asking to to post all of it. He is asking to post a short,
>> maybe 10 lines code, where the error exists
>
> I have two versions of function obfuscate_application(). The problem
> occurs in /* commented out */ version (in random places of the code),
> the version not commented out (older, below) works fine.

That's neither minimal nor complete.

The person you'll help the most understanding what's happening here by
creating a minimal complete program that demonstrates the problem is
you yourself. (There's a high probability you'll find the problem
yourself, and even if you don't, you'll most probably understand
better the explanation given here.)

[Paavo Helde]

Then it might be some unrelated code corrupting the memory. Data
breakpoints might help. Or run your code under valgrind or some other
memchecker.

If the bug is well reproducible, you might also be able to figure it out
by incrementally commenting out more and more of your loop content.

[Jivanmukta]

W dniu 29.09.2022 o 14:00, Paavo Helde pisze:

It is interesting that problem occurs only when debugging. Program run
from prompt works fine, without the problem.

[Paavo Helde]

Ah, you mean there is no bug, just the debugger is displaying some
misleading messages? In that case, welcome to the club!

[Jivanmukta]

W dniu 29.09.2022 o 16:07, Paavo Helde pisze:

>> It is interesting that problem occurs only when debugging. Program run
>> from prompt works fine, without the problem.
>
> Ah, you mean there is no bug, just the debugger is displaying some
> misleading messages? In that case, welcome to the club!
>
>

But I need to debug my program to fix other errors.
The error described by me makes debugging problematic.

[Paavo Helde]

Well, use a better debugger then. My debugger (Visual Studio) does not
display such error messages.

Or figure out why your debugger has problems. Maybe you haven't
specified -g at all, or maybe you have some optimization turned on, or
maybe you haven't recompiled all files.

[Louis Krupp]

Could you upload the source code to Google Drive and post the link?

Louis

[Sam]

We're sorry, but all our psychics are out to lunch right now, and there's
nobody left in the office who can operate the magical mind ray-beam machine
that's needed to extract all the relevant details out of your head, or your
computer, and figure out the problem.

We apologize for the inconvenience.

[Juha Nieminen]

Jivanmukta <jivan...@poczta.onet.pl> wrote:
> It is interesting that problem occurs only when debugging. Program run
> from prompt works fine, without the problem.

That's completely normal. Just because it seems to "work fine" that
doesn't mean there isn't a problem (it just so happens that it isn't
crashing in that particular situation).

You should still create the minimal complete program that demonstrates
the problem.

[Juha Nieminen]

Paavo Helde <ees...@osa.pri.ee> wrote:
>> It is interesting that problem occurs only when debugging. Program run
>> from prompt works fine, without the problem.
>
> Ah, you mean there is no bug, just the debugger is displaying some
> misleading messages? In that case, welcome to the club!

Are you being sarcastic?

Rather obviously just because a release build of the program doesn't
happen to crash in a particular situation doesn't mean there is no bug.

[Alf P. Steinbach]

On 28 Sept 2022 13:53, Jivanmukta wrote:
> I don't understand what's wrong in my code:
>
> std::vector<std::wstring> vendor_frameworks_dirs;
> ...
> for (auto dir = vendor_frameworks_dirs.begin(); dir !=
> vendor_frameworks_dirs.end(); ++dir)

Post a complete but minimal example that demonstrates the problem.

Alan Turing professed to believe in ESP, but we don't.

- Alf

[Paavo Helde]

30.09.2022 10:13 Juha Nieminen kirjutas:
> Paavo Helde <ees...@osa.pri.ee> wrote:
>>> It is interesting that problem occurs only when debugging. Program run
>>> from prompt works fine, without the problem.
>>
>> Ah, you mean there is no bug, just the debugger is displaying some
>> misleading messages? In that case, welcome to the club!
>
> Are you being sarcastic?

No, I had got an impression he is complaining about something which he
sees in his debugger only. The debuggers are known to sometimes display
invalid or misleading information. I might be wrong, it is hard to say
what OP meant by the phrase "while debugging".

>
> Rather obviously just because a release build of the program doesn't
> happen to crash in a particular situation doesn't mean there is no bug.

The reported "crash" is basically an assert failure in a debug feature,
so a proper Release build would obviously not have it. However, the OP
did not talk anything about running a Release build, he just said
"Program run from prompt works fine". I assumed that was the same Debug
build, but I might be mistaken.

[Mut...@dastardlyhq.com]

On Thu, 29 Sep 2022 22:19:05 +0300
Paavo Helde <ees...@osa.pri.ee> wrote:
>29.09.2022 20:15 Jivanmukta kirjutas:
>> W dniu 29.09.2022 o 16:07, Paavo Helde pisze:
>>>> It is interesting that problem occurs only when debugging. Program
>>>> run from prompt works fine, without the problem.
>>>
>>> Ah, you mean there is no bug, just the debugger is displaying some
>>> misleading messages? In that case, welcome to the club!
>>>
>>>
>> But I need to debug my program to fix other errors.
>> The error described by me makes debugging problematic.
>
>Well, use a better debugger then. My debugger (Visual Studio) does not
>display such error messages.

It just randomly skips lines during stepping depending on the optimisation
level. Very helpful.

[Paavo Helde]

If the line has been optimized away or moved to another place, it cannot
be really stepped into.

Debugging optimized code is a dark art anyway. Hopefully the compiler
vendors will not listen to the advocates for applying some optimizations
always, regardless of the optimization level.

With gdb I have the opposite problem, it dutifully steps into std code
like string contstructors. It's basically impossible to step into my own
function if there are any non-trivial arguments in the function call.

[Jivanmukta]

W dniu 30.09.2022 o 14:56, Paavo Helde pisze:

> 30.09.2022 10:13 Juha Nieminen kirjutas:
>> Paavo Helde <ees...@osa.pri.ee> wrote:
>>>> It is interesting that problem occurs only when debugging. Program run
>>>> from prompt works fine, without the problem.
>>>
>>> Ah, you mean there is no bug, just the debugger is displaying some
>>> misleading messages? In that case, welcome to the club!
>>
>> Are you being sarcastic?
>
> No, I had got an impression he is complaining about something which he
> sees in his debugger only. The debuggers are known to sometimes display
> invalid or misleading information. I might be wrong, it is hard to say
> what OP meant by the phrase "while debugging".
>

When I debug my program in Codium the programs stops and I receive
mentioned error.

>
>> Rather obviously just because a release build of the program doesn't
>> happen to crash in a particular situation doesn't mean there is no bug.
>
> The reported "crash" is basically an assert failure in a debug feature,
> so a proper Release build would obviously not have it. However, the OP
> did not talk anything about running a Release build, he just said
> "Program run from prompt works fine". I assumed that was the same Debug
> build, but I might be mistaken.

I run debug build from prompt. I don't compile to release.

[Mut...@dastardlyhq.com]

On Fri, 30 Sep 2022 17:04:07 +0300

Paavo Helde <ees...@osa.pri.ee> wrote:
>30.09.2022 16:50 Mut...@dastardlyhq.com kirjutas:
>> On Thu, 29 Sep 2022 22:19:05 +0300
>> Paavo Helde <ees...@osa.pri.ee> wrote:
>>> 29.09.2022 20:15 Jivanmukta kirjutas:
>>>> W dniu 29.09.2022 o 16:07, Paavo Helde pisze:
>>>>>> It is interesting that problem occurs only when debugging. Program
>>>>>> run from prompt works fine, without the problem.
>>>>>
>>>>> Ah, you mean there is no bug, just the debugger is displaying some
>>>>> misleading messages? In that case, welcome to the club!
>>>>>
>>>>>
>>>> But I need to debug my program to fix other errors.
>>>> The error described by me makes debugging problematic.
>>>
>>> Well, use a better debugger then. My debugger (Visual Studio) does not
>>> display such error messages.
>>
>> It just randomly skips lines during stepping depending on the optimisation
>> level. Very helpful.
>
>If the line has been optimized away or moved to another place, it cannot
>be really stepped into.

Thats fair enough, but since it knows the code isn't there it should flag up
in the code window that its been optimised away rather than just jumping
ahead.

>Debugging optimized code is a dark art anyway. Hopefully the compiler
>vendors will not listen to the advocates for applying some optimizations
>always, regardless of the optimization level.
>
>With gdb I have the opposite problem, it dutifully steps into std code
>like string contstructors. It's basically impossible to step into my own
>function if there are any non-trivial arguments in the function call.

There is a way to avoid that but I can't remember how off the top of my head.
You'll have to google.

[Scott Lurndal]

Paavo Helde <ees...@osa.pri.ee> writes:
>30.09.2022 16:50 Mut...@dastardlyhq.com kirjutas:
>> On Thu, 29 Sep 2022 22:19:05 +0300
>> Paavo Helde <ees...@osa.pri.ee> wrote:
>>> 29.09.2022 20:15 Jivanmukta kirjutas:
>>>> W dniu 29.09.2022 o 16:07, Paavo Helde pisze:
>>>>>> It is interesting that problem occurs only when debugging. Program
>>>>>> run from prompt works fine, without the problem.
>>>>>
>>>>> Ah, you mean there is no bug, just the debugger is displaying some
>>>>> misleading messages? In that case, welcome to the club!
>>>>>
>>>>>
>>>> But I need to debug my program to fix other errors.
>>>> The error described by me makes debugging problematic.
>>>
>>> Well, use a better debugger then. My debugger (Visual Studio) does not
>>> display such error messages.
>>
>> It just randomly skips lines during stepping depending on the optimisation
>> level. Very helpful.
>
>If the line has been optimized away or moved to another place, it cannot
>be really stepped into.
>
>Debugging optimized code is a dark art anyway. Hopefully the compiler
>vendors will not listen to the advocates for applying some optimizations
>always, regardless of the optimization level.

I suspect that most compilers always do simple optimizations
such as constant folding or peephole optimizations such as
replacing multiply/divide with shifts regardless of the optimization level.

[Juha Nieminen]

Jivanmukta <jivan...@poczta.onet.pl> wrote:
> When I debug my program in Codium the programs stops and I receive
> mentioned error.

Just create the minimal complete program that exhibits the problem, so
we can put this to rest.

[Louis Krupp]

On 9/30/2022 9:03 AM, Mut...@dastardlyhq.com wrote:
> On Fri, 30 Sep 2022 17:04:07 +0300
> Paavo Helde <ees...@osa.pri.ee> wrote:
>> 30.09.2022 16:50 Mut...@dastardlyhq.com kirjutas:
>>> On Thu, 29 Sep 2022 22:19:05 +0300
>>> Paavo Helde <ees...@osa.pri.ee> wrote:
>>>> 29.09.2022 20:15 Jivanmukta kirjutas:
>>>>> W dniu 29.09.2022 o 16:07, Paavo Helde pisze:
>>>>>>> It is interesting that problem occurs only when debugging. Program
>>>>>>> run from prompt works fine, without the problem.
>>>>>> Ah, you mean there is no bug, just the debugger is displaying some
>>>>>> misleading messages? In that case, welcome to the club!
>>>>>>
>>>>>>
>>>>> But I need to debug my program to fix other errors.
>>>>> The error described by me makes debugging problematic.
>>>> Well, use a better debugger then. My debugger (Visual Studio) does not
>>>> display such error messages.
>>> It just randomly skips lines during stepping depending on the optimisation
>>> level. Very helpful.
>> If the line has been optimized away or moved to another place, it cannot
>> be really stepped into.
> Thats fair enough, but since it knows the code isn't there it should flag up
> in the code window that its been optimised away rather than just jumping
> ahead.
>

The debugger might not know that the code was optimized away. If it's
not there, it's not there.

Louis

[Jivanmukta]

W dniu 30.09.2022 o 09:12, Juha Nieminen pisze:

> Jivanmukta <jivan...@poczta.onet.pl> wrote:
>> It is interesting that problem occurs only when debugging. Program run
>> from prompt works fine, without the problem.
>
> That's completely normal. Just because it seems to "work fine" that
> doesn't mean there isn't a problem (it just so happens that it isn't
> crashing in that particular situation).

I run my program from prompt and with debugger using the same arguments
and input data.

[Mut...@dastardlyhq.com]

It has the source code as a reference. If it can skip lines then it can
highlight those lines as optimised out.

[Jivanmukta]

W dniu 28.09.2022 o 13:53, Jivanmukta pisze:

> I don't understand what's wrong in my code:
>
> std::vector<std::wstring> vendor_frameworks_dirs;
> ...
> for (auto dir = vendor_frameworks_dirs.begin(); dir !=
> vendor_frameworks_dirs.end(); ++dir)

Changing for-loop to:

for (auto dir : vendor_frameworks_dirs)

solved the problem. I have no error.
Problem closed.

[Juha Nieminen]

"It doesn't complain anymore" does not necessarily mean that the problem
has been solved. It's possible that you are simply masking the problem.

You never submitted a minimal complete program so we could analyze
whether there is an actual problem or whether the debugger you are
using is just flawed. Thus, we will never know (unless someone goes
through the trouble of combing through the code you did post).

And by the way, you should use 'auto&' in that kind of loop, not 'auto'.
This especially if the elements are large (because you would be
needlessly deep-copying them). You should only use 'auto' if you
explicitly *need* to deep-copy each element into the variable for
whatever reason. (You can also use it if the elements are of an
elementary type like 'int', but even then, theres probably no
benefit.)

[Jivanmukta]

W dniu 4.10.2022 o 08:02, Juha Nieminen pisze:

> You never submitted a minimal complete program so we could analyze
> whether there is an actual problem or whether the debugger you are
> using is just flawed. Thus, we will never know (unless someone goes
> through the trouble of combing through the code you did post).

I have a problem with preparing minimal complete program: I extracted
problematic code to new test project and I simplified Makefile, but test
project works fine.

test/src/test.cpp:

#include <iostream>
#include <vector>
#include <string>
#include <cstring>
#include <stdlib.h>

int main() {
std::vector<std::wstring> vendor_frameworks_dirs = { L"this is a
test" };

for (auto dir = vendor_frameworks_dirs.begin(); dir !=
vendor_frameworks_dirs.end(); ++dir)

{
std::string s = std::string((*dir).begin(), (*dir).end());
std::cout << s;
}
return 0;
}

test/Makefile:

ObjSuf = o
SrcSuf = cpp
DllSuf = so
BUILD := ./build
OBJ_DIR := $(BUILD)/objects
APP_DIR := $(BUILD)/apps
INCLUDE := -Iinclude # -I src/boost_1_65_0
CXXFLAGS := -Wall -Wextra -Werror -no-pie -D_X86_=1 # -std=c++17
-fpermissive -pedantic-errors; add "-no-pie" to the CMAKE_CXX_FLAGS
LDFLAGS := -lstdc++ -lm -lstdc++fs -L/usr/lib # -Lsrc/boost_1_65_0/lib/
-lboost_regex-gcc34-mt-d-1_3
TARGET := test

all: build $(APP_DIR)/$(TARGET)
$(CXX) $(CXXFLAGS) $(INCLUDE) -c $< -o $@ $(LDFLAGS)
SRC := $(wildcard src/*.$(SrcSuf))
OBJECTS := $(SRC:%.$(SrcSuf)=$(OBJ_DIR)/%.$(ObjSuf))

$(OBJ_DIR)/%.$(ObjSuf): %.$(SrcSuf)
@mkdir -p $(@D)
$(CXX) $(CXXFLAGS) $(INCLUDE) -c $< -o $@ $(LDFLAGS)

$(APP_DIR)/$(TARGET): $(OBJECTS)
@mkdir -p $(@D)
$(CXX) $(CXXFLAGS) -o $(APP_DIR)/$(TARGET) $^ $(LDFLAGS)

PHONY: all build clean debug release

debug: CXXFLAGS += -DDEBUG -g -O0 -fsanitize=address -D_GLIBCXX_DEBUG #
-static-libasan
debug: all

test: CXXFLAGS += -pg # dynamic execution profiler
test: all

release: CXXFLAGS += -O2
release: all # production

clean:
-@rm -rvf $(OBJ_DIR)/*
-@rm -rvf $(APP_DIR)/*

[Juha Nieminen]

Jivanmukta <jivan...@poczta.onet.pl> wrote:
> I have a problem with preparing minimal complete program: I extracted
> problematic code to new test project and I simplified Makefile, but test
> project works fine.

In that case what you should do is to take the code where the problem
happens and start removing small parts of it, checking every time if
the problem still happens. If at some point the problem disappears
you may have found the problematic code. If that still doesn't help
understanding what's going on, continue removing other parts of the
code until you can't remove anything without making the problem
disappear. Anything that doesn't affect the problem, remove, until
you have the minimal amount of code that still exhibits the problem.

We don't need any makefile. Just C++ code ought to be enough.
(At most you could tell which compiler and compiler options you are
using.)

[Jivanmukta]

W dniu 6.10.2022 o 08:55, Juha Nieminen pisze:

> In that case what you should do is to take the code where the problem
> happens and start removing small parts of it, checking every time if
> the problem still happens. If at some point the problem disappears
> you may have found the problematic code. If that still doesn't help
> understanding what's going on, continue removing other parts of the
> code until you can't remove anything without making the problem
> disappear. Anything that doesn't affect the problem, remove, until
> you have the minimal amount of code that still exhibits the problem.

I will try do this but it won't be easy task - my program has nearly 10
KLOC.

[Jivanmukta]

W dniu 7.10.2022 o 07:34, Jivanmukta pisze:

> I will try do this but it won't be easy task - my program has nearly 10
> KLOC.

Moreover, my program consists of many highly-coupled files.

[Juha Nieminen]

Often that's indicative that the program could benefit from a good
refactoring.

[Öö Tiib]

An attempt to remove parts that are unrelated to your problem
will also help to see ways how to reduce interdependence
between parts of your program (IOW to make it well-structured).