Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #86671 > unrolled thread

attempt to dereference a singular iterator

Back to article view | Back to comp.lang.c++

Contents

  attempt to dereference a singular iterator Jivanmukta <jivanmukta@poczta.onet.pl> - 2022-09-28 13:53 +0200
    Re: attempt to dereference a singular iterator Jivanmukta <jivanmukta@poczta.onet.pl> - 2022-09-28 14:18 +0200
      Re: attempt to dereference a singular iterator JiiPee <kerrttuPoistaTama11@gmail.com> - 2022-09-28 18:53 +0300
    Re: attempt to dereference a singular iterator Juha Nieminen <nospam@thanks.invalid> - 2022-09-28 12:19 +0000
      Re: attempt to dereference a singular iterator Jivanmukta <jivanmukta@poczta.onet.pl> - 2022-09-28 17:08 +0200
        Re: attempt to dereference a singular iterator JiiPee <kerrttuPoistaTama11@gmail.com> - 2022-09-28 18:52 +0300
          Re: attempt to dereference a singular iterator Jivanmukta <jivanmukta@poczta.onet.pl> - 2022-09-29 09:42 +0200
          Re: attempt to dereference a singular iterator Jivanmukta <jivanmukta@poczta.onet.pl> - 2022-09-29 11:58 +0200
            Re: attempt to dereference a singular iterator Juha Nieminen <nospam@thanks.invalid> - 2022-09-29 11:04 +0000
        Re: attempt to dereference a singular iterator Louis Krupp <lkrupp@invalid.pssw.com.invalid> - 2022-09-29 13:23 -0600
        Re: attempt to dereference a singular iterator Sam <sam@email-scan.com> - 2022-09-29 15:39 -0400
    Re: attempt to dereference a singular iterator Paavo Helde <eesnimi@osa.pri.ee> - 2022-09-28 19:21 +0300
      Re: attempt to dereference a singular iterator Jivanmukta <jivanmukta@poczta.onet.pl> - 2022-09-29 09:58 +0200
        Re: attempt to dereference a singular iterator Paavo Helde <eesnimi@osa.pri.ee> - 2022-09-29 15:00 +0300
          Re: attempt to dereference a singular iterator Jivanmukta <jivanmukta@poczta.onet.pl> - 2022-09-29 15:59 +0200
            Re: attempt to dereference a singular iterator Paavo Helde <eesnimi@osa.pri.ee> - 2022-09-29 17:07 +0300
              Re: attempt to dereference a singular iterator Jivanmukta <jivanmukta@poczta.onet.pl> - 2022-09-29 19:15 +0200
                Re: attempt to dereference a singular iterator Paavo Helde <eesnimi@osa.pri.ee> - 2022-09-29 22:19 +0300
                  Re: attempt to dereference a singular iterator Muttley@dastardlyhq.com - 2022-09-30 13:50 +0000
                    Re: attempt to dereference a singular iterator Paavo Helde <eesnimi@osa.pri.ee> - 2022-09-30 17:04 +0300
                      Re: attempt to dereference a singular iterator Muttley@dastardlyhq.com - 2022-09-30 15:03 +0000
                        Re: attempt to dereference a singular iterator Louis Krupp <lkrupp@invalid.pssw.com.invalid> - 2022-09-30 11:01 -0600
                          Re: attempt to dereference a singular iterator Muttley@dastardlyhq.com - 2022-10-01 09:01 +0000
                      Re: attempt to dereference a singular iterator scott@slp53.sl.home (Scott Lurndal) - 2022-09-30 15:19 +0000
              Re: attempt to dereference a singular iterator Juha Nieminen <nospam@thanks.invalid> - 2022-09-30 07:13 +0000
                Re: attempt to dereference a singular iterator Paavo Helde <eesnimi@osa.pri.ee> - 2022-09-30 15:56 +0300
                  Re: attempt to dereference a singular iterator Jivanmukta <jivanmukta@poczta.onet.pl> - 2022-09-30 16:21 +0200
                    Re: attempt to dereference a singular iterator Juha Nieminen <nospam@thanks.invalid> - 2022-09-30 16:09 +0000
            Re: attempt to dereference a singular iterator Juha Nieminen <nospam@thanks.invalid> - 2022-09-30 07:12 +0000
              Re: attempt to dereference a singular iterator Jivanmukta <jivanmukta@poczta.onet.pl> - 2022-09-30 21:05 +0200
    Re: attempt to dereference a singular iterator "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-09-30 10:36 +0200
    Re: attempt to dereference a singular iterator Jivanmukta <jivanmukta@poczta.onet.pl> - 2022-10-03 16:53 +0200
      Re: attempt to dereference a singular iterator Juha Nieminen <nospam@thanks.invalid> - 2022-10-04 06:02 +0000
        Re: attempt to dereference a singular iterator Jivanmukta <jivanmukta@poczta.onet.pl> - 2022-10-05 09:42 +0200
          Re: attempt to dereference a singular iterator Juha Nieminen <nospam@thanks.invalid> - 2022-10-06 06:55 +0000
            Re: attempt to dereference a singular iterator Jivanmukta <jivanmukta@poczta.onet.pl> - 2022-10-07 07:34 +0200
              Re: attempt to dereference a singular iterator Jivanmukta <jivanmukta@poczta.onet.pl> - 2022-10-07 15:20 +0200
                Re: attempt to dereference a singular iterator Juha Nieminen <nospam@thanks.invalid> - 2022-10-10 06:21 +0000
                Re: attempt to dereference a singular iterator Öö Tiib <ootiib@hot.ee> - 2022-10-10 01:03 -0700

Page 2 of 2 — ← Prev page 1 [2]

#86728

On Fri, 30 Sep 2022 17:04:07 +0300
Paavo Helde <eesnimi@osa.pri.ee> wrote:
>30.09.2022 16:50 Muttley@dastardlyhq.com kirjutas:
>> On Thu, 29 Sep 2022 22:19:05 +0300
>> Paavo Helde <eesnimi@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.

[toc] | [prev] | [next] | [standalone]

#86734

On 9/30/2022 9:03 AM, Muttley@dastardlyhq.com wrote:
> On Fri, 30 Sep 2022 17:04:07 +0300
> Paavo Helde <eesnimi@osa.pri.ee> wrote:
>> 30.09.2022 16:50 Muttley@dastardlyhq.com kirjutas:
>>> On Thu, 29 Sep 2022 22:19:05 +0300
>>> Paavo Helde <eesnimi@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

[toc] | [prev] | [next] | [standalone]

#86749

On Fri, 30 Sep 2022 11:01:32 -0600
Louis Krupp <lkrupp@invalid.pssw.com.invalid> wrote:
>On 9/30/2022 9:03 AM, Muttley@dastardlyhq.com wrote:
>> On Fri, 30 Sep 2022 17:04:07 +0300
>> Paavo Helde <eesnimi@osa.pri.ee> wrote:
>>> 30.09.2022 16:50 Muttley@dastardlyhq.com kirjutas:
>>>> On Thu, 29 Sep 2022 22:19:05 +0300
>>>> Paavo Helde <eesnimi@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.

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

[toc] | [prev] | [next] | [standalone]

#86730

Paavo Helde <eesnimi@osa.pri.ee> writes:
>30.09.2022 16:50 Muttley@dastardlyhq.com kirjutas:
>> On Thu, 29 Sep 2022 22:19:05 +0300
>> Paavo Helde <eesnimi@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.

[toc] | [prev] | [next] | [standalone]

#86720

Paavo Helde <eesnimi@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.

[toc] | [prev] | [next] | [standalone]

#86724

30.09.2022 10:13 Juha Nieminen kirjutas:
> Paavo Helde <eesnimi@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.

[toc] | [prev] | [next] | [standalone]

#86727

W dniu 30.09.2022 o 14:56, Paavo Helde pisze:
> 30.09.2022 10:13 Juha Nieminen kirjutas:
>> Paavo Helde <eesnimi@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.

[toc] | [prev] | [next] | [standalone]

#86731

Jivanmukta <jivanmukta@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.

[toc] | [prev] | [next] | [standalone]

#86719

Jivanmukta <jivanmukta@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.

[toc] | [prev] | [next] | [standalone]

#86740

W dniu 30.09.2022 o 09:12, Juha Nieminen pisze:
> Jivanmukta <jivanmukta@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.

[toc] | [prev] | [next] | [standalone]

#86722

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

[toc] | [prev] | [next] | [standalone]

#86784

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.

[toc] | [prev] | [next] | [standalone]

#86791

Jivanmukta <jivanmukta@poczta.onet.pl> wrote:
> 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.

"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.)

[toc] | [prev] | [next] | [standalone]

#86803

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)/*

[toc] | [prev] | [next] | [standalone]

#86817

Jivanmukta <jivanmukta@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.)

[toc] | [prev] | [next] | [standalone]

#86823

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.

[toc] | [prev] | [next] | [standalone]

#86830

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.

[toc] | [prev] | [next] | [standalone]

#86850

Jivanmukta <jivanmukta@poczta.onet.pl> wrote:
> 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.

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

[toc] | [prev] | [next] | [standalone]

#86851

On Friday, 7 October 2022 at 16:20:41 UTC+3, Jivanmukta wrote:
> 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.

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). 

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c++

csiph-web