🚀 go-pugleaf

W dniu 2016-05-04 13:16, M.M. pisze:
>
> Zadeklarowałem w programie strukturę do zwracania rezultatu.
>
> struct Result {
>    Class object;
>    double a;
>    double b;
> };
>
> Class to jakiś typ klasowy, dość duży i złożony.
>
> We wszelkich operacjach kopiowania i zwracania składowa 'b' była
> tak jakby pomijana. Gdy np. kładłem na stosie zmienną automatyczną:
>
> Result res;
>
> to, rzecz jasna, w składowej 'b' należało spodziewać się śmieci i
> śmieci w niej były.
>
> Gdy potem robiłem:
>
> res = other_res;
>
> albo
>
> res = function();
>
> To w składowej te śmieci pozostały. Byłem pewny na 100% UB. Błędu
> szukałem, nawet jakiś znalazłem błąd, ale po poprawieniu znalezionego
> błędu składowa 'b' nadal była tak jakby pomijana przy kopiowaniu.
>
> Dopisałem na końcu składową diagnostyczną:
>
> struct Result {
>    Class object;
>    double a;
>    double b;
>    int tmp;
> };
>
> Wszystko działało poprawnie, składowe object, a i tmp były kopiowane
> prawidłowo, natomiast składowa b nadal nietknięta. Bity w niej
> pozostawały identyczne.
>
> Potem dodałem więcej składowych diagnostycznych
> struct Result {
>    int tmp1;
>    Class object;
>    int tmp2;
>    double a;
>    int tmp3;
>    double b;
>    int tmp4;
> };
>
> I znowu wszystko się kopiuje prawidłowo, tylko nie składowa 'b'!
>
> W końcu zmieniłem nazwę struktury z Result na ResultL, czyli dopisałem
> na końcu dużą literę 'L'.
>
> Program zaczął działać!
>
> Nie mam pojęcia co się dzieje. Jeszcze jedno: na wersjach debug i
> release to samo. Niemożliwe aby przez UB zawsze pomijał składową 'b'.
> Nazwa Result koliduje z czymś? Ale jeśli tak, to czemu kompilator
> to kompiluje?
>
>
> Używam:
> g++ --version
> g++ (Ubuntu 4.8.4-2ubuntu1~14.04.1) 4.8.4
>
> Używam tego kompilator od... nie pamiętam dokładnie, ale może od 2-3
> miesięcy, nigdy nie miałem z nim żadnych problemów.
>
> Macie jakieś pomysły?
>
> Pozdrawiam
>
>

Strzelam, że pewnie jakaś nazwa się przykrywa, bo wygląda to co najmniej 
dziwnie.


-- 
Kaczus
http://kaczus.ppa.pl

On Wednesday, May 4, 2016 at 1:16:11 PM UTC+2, M.M. wrote:

> 
> Macie jakieś pomysły?


Podaj MINIMALNY kompilowalny kod odtwarzający błąd.

pzdr
bartekltg

On Wednesday, May 4, 2016 at 2:10:32 PM UTC+2, Tomasz Kaczanowski wrote:
> W dniu 2016-05-04 13:16, M.M. pisze:
> >
> > Zadeklarowałem w programie strukturę do zwracania rezultatu.
> >
> > struct Result {
> >    Class object;
> >    double a;
> >    double b;
> > };
> >
> > Class to jakiś typ klasowy, dość duży i złożony.
> >
> > We wszelkich operacjach kopiowania i zwracania składowa 'b' była
> > tak jakby pomijana. Gdy np. kładłem na stosie zmienną automatyczną:
> >
> > Result res;
> >
> > to, rzecz jasna, w składowej 'b' należało spodziewać się śmieci i
> > śmieci w niej były.
> >
> > Gdy potem robiłem:
> >
> > res = other_res;
> >
> > albo
> >
> > res = function();
> >
> > To w składowej te śmieci pozostały. Byłem pewny na 100% UB. Błędu
> > szukałem, nawet jakiś znalazłem błąd, ale po poprawieniu znalezionego
> > błędu składowa 'b' nadal była tak jakby pomijana przy kopiowaniu.
> >
> > Dopisałem na końcu składową diagnostyczną:
> >
> > struct Result {
> >    Class object;
> >    double a;
> >    double b;
> >    int tmp;
> > };
> >
> > Wszystko działało poprawnie, składowe object, a i tmp były kopiowane
> > prawidłowo, natomiast składowa b nadal nietknięta. Bity w niej
> > pozostawały identyczne.
> >
> > Potem dodałem więcej składowych diagnostycznych
> > struct Result {
> >    int tmp1;
> >    Class object;
> >    int tmp2;
> >    double a;
> >    int tmp3;
> >    double b;
> >    int tmp4;
> > };
> >
> > I znowu wszystko się kopiuje prawidłowo, tylko nie składowa 'b'!
> >
> > W końcu zmieniłem nazwę struktury z Result na ResultL, czyli dopisałem
> > na końcu dużą literę 'L'.
> >
> > Program zaczął działać!
> >
> > Nie mam pojęcia co się dzieje. Jeszcze jedno: na wersjach debug i
> > release to samo. Niemożliwe aby przez UB zawsze pomijał składową 'b'.
> > Nazwa Result koliduje z czymś? Ale jeśli tak, to czemu kompilator
> > to kompiluje?
> >
> >
> > Używam:
> > g++ --version
> > g++ (Ubuntu 4.8.4-2ubuntu1~14.04.1) 4.8.4
> >
> > Używam tego kompilator od... nie pamiętam dokładnie, ale może od 2-3
> > miesięcy, nigdy nie miałem z nim żadnych problemów.
> >
> > Macie jakieś pomysły?
> >
> > Pozdrawiam
> >
> >
> 
> Strzelam, że pewnie jakaś nazwa się przykrywa, bo wygląda to co najmniej 
> dziwnie.

Też tak pomyślałem, ale by się skompilowało?
Pozdrawiam

On Wednesday, May 4, 2016 at 2:10:47 PM UTC+2, bartekltg wrote:
> On Wednesday, May 4, 2016 at 1:16:11 PM UTC+2, M.M. wrote:
> 
> > 
> > Macie jakieś pomysły?
> 
> 
> Podaj MINIMALNY kompilowalny kod odtwarzający błąd.

Obawiam się, że minimalny będzie działał poprawnie, w przeciwnym
razie żaden program by nie działał. To jest efekt jakiś dziwnych
interakcji pomiędzy elementami dużego programu.

Mniej/więcej takie coś miałem:

struct Result {
  int a;
  int b;
  int c;
};

Result r1;
r1.a = 1;
r1.b = 2;
r1.c = 3;

Result r2 = r1;

if( r2.b != 2 ) {
 printf("WTF\n");
}

Potem zmieniłem nazwę Result na ResultL i program
już nie wyświetlał WTF.

Pozdrawiam

M.M. <mmarszik@gmail.com> wrote:

> Obawiam się, że minimalny będzie działał poprawnie, w przeciwnym
> razie żaden program by nie działał. To jest efekt jakiś dziwnych
> interakcji pomiędzy elementami dużego programu.

A jakie masz include'y?

> Mniej/więcej takie coś miałem:

To działa prawidłowo (gcc 4.9.2, x86_64-linux-gnu).

-- 
http://www.chmurka.net/

M.M. <mmarszik@gmail.com> wrote:

> Obawiam się, że minimalny będzie działał poprawnie, w przeciwnym
> razie żaden program by nie działał. To jest efekt jakiś dziwnych
> interakcji pomiędzy elementami dużego programu.

Spróbuj dodać do kompilacji opcję -E i obejrzyj plik wynikowy, będzie to 
wynik preprocesora. Może rzeczywiście coś przykrywa Result...

-- 
http://www.chmurka.net/

On 2016-05-04 19:17, M.M. wrote:
> Kurcze, ale to jest mało prawdopodobne, aby coś przykrywało i kod się
> kompilował, nazwy pól i metod byłyby inne. Tak dziwnego błędu w życiu
> nie widziałem.

A ta klasa trzymana przez wartość:
a) ma coś działajacego do konstrukcji?
b) ma coś działajacego do kopiowania?

Oglądanie zawartości takich rzeczy na stacku czasem pokazuje błedy 
debugera. Przodował w tym kiedyś u mnie VS2008 który nie był w stanie 
pokazać struktury dwóch struktur na stosie bez smieci w conajmniej 
jednej. Przypadek tez specyficzny, redukcja kodu usuwała bład, ale kod 
wynikowy był poprawny i działał.

On Wednesday, May 4, 2016 at 4:44:48 PM UTC+2, Adam Wysocki wrote:
> M.M. <mmarszik@gmail.com> wrote:
> 
> > Obawiam się, że minimalny będzie działał poprawnie, w przeciwnym
> > razie żaden program by nie działał. To jest efekt jakiś dziwnych
> > interakcji pomiędzy elementami dużego programu.
> 
> Spróbuj dodać do kompilacji opcję -E i obejrzyj plik wynikowy, będzie to 
> wynik preprocesora. Może rzeczywiście coś przykrywa Result...
> 
> -- 
> http://www.chmurka.net/

Kurcze, ale to jest mało prawdopodobne, aby coś przykrywało i kod się
kompilował, nazwy pól i metod byłyby inne. Tak dziwnego błędu w życiu
nie widziałem.

Pozdrawiam

On Wednesday, May 4, 2016 at 7:21:16 PM UTC+2, Sebastian Biały wrote:
> On 2016-05-04 19:17, M.M. wrote:
> > Kurcze, ale to jest mało prawdopodobne, aby coś przykrywało i kod się
> > kompilował, nazwy pól i metod byłyby inne. Tak dziwnego błędu w życiu
> > nie widziałem.
> 
> A ta klasa trzymana przez wartość:
> a) ma coś działajacego do konstrukcji?
> b) ma coś działajacego do kopiowania?
> 
> Oglądanie zawartości takich rzeczy na stacku czasem pokazuje błedy 
> debugera. Przodował w tym kiedyś u mnie VS2008 który nie był w stanie 
> pokazać struktury dwóch struktur na stosie bez smieci w conajmniej 
> jednej. Przypadek tez specyficzny, redukcja kodu usuwała bład, ale kod 
> wynikowy był poprawny i działał.

Zgadza się, debugery mają błędy. O ile pamiętam, kiedyś raz miałem podobny
jak opisałeś problem w builderze, ciut inny problem miałem z debugerem w
qtcreatorze. Ten bład z qtcreatora chyba nawet tutaj na grupę wrzuciłem
ze screenami.

Jednak teraz, jeśli nawet uaktywnił się błąd debugera, to musiało coś
jeszcze innego nie działać. Wypisywane zmienne printfem na konsole też
miały dziwne wartości, a czy takie same jak w debugerze, to nie zwrociłem
uwagi. Ponadto nie przechodził program asercji i wartości nan pojawiały się w
GUI.

Głupio zrobiłem, że nie zachowałem dokładnie tej wersji z błędem. Gdy
po zmianie nazwy z Result na ResultL zaczęło działać, to normalnie
pracowałem nad kodem i naniosłem wiele zmian. Teraz gdy zamieniam z 
powrotem z ResultL na Result, to wszystko działa jak w zegarku. Nie
mogę odtworzyć sytuacji z błędem. 

Może środowisko ma jakiś problem i przy rebuild nie rekompilowało 
wszystkiego od nowa, może dostawał się jakiś stary plik *.o ?

Pozdrawiam

W dniu 2016-05-04 19:17, M.M. pisze:
> On Wednesday, May 4, 2016 at 4:44:48 PM UTC+2, Adam Wysocki wrote:
>> M.M.<mmarszik@gmail.com>  wrote:
>>
>>> Obawiam się, że minimalny będzie działał poprawnie, w przeciwnym
>>> razie żaden program by nie działał. To jest efekt jakiś dziwnych
>>> interakcji pomiędzy elementami dużego programu.
>>
>> Spróbuj dodać do kompilacji opcję -E i obejrzyj plik wynikowy, będzie to
>> wynik preprocesora. Może rzeczywiście coś przykrywa Result...
>>
>> --
>> http://www.chmurka.net/
>
> Kurcze, ale to jest mało prawdopodobne, aby coś przykrywało i kod się
> kompilował, nazwy pól i metod byłyby inne. Tak dziwnego błędu w życiu
> nie widziałem.

w jednym kompilatorze jak kompilowałem większy projekt była zmienna 
statyczna i jak się potem okazało zmienna globalna o tej samej nazwie - 
przy kompilacji "0" ostrzeżeń, a po kompilacji losowe przykrywanie się 
tych zmiennych. Dlatego teraz ścigam osoby współpracujące, aby jeśli nie 
ma takiej potrzeby zmiennych globalnych nie używali, a jak już to przy 
okazji dawali dokladny opis, co to za zmienna do czego i dokladnie jak 
sie nazywa oraz dlaczego musieli jej użyć - na razie w nowych projektach 
użycie zmiennych globalnych spadło do 0 :) Nikt nie lubi pisać 
dokumentacji :)


-- 
Kaczus
http://kaczus.ppa.pl

On Thursday, May 5, 2016 at 7:50:02 AM UTC+2, Tomasz Kaczanowski wrote:
> W dniu 2016-05-04 19:17, M.M. pisze:
> > On Wednesday, May 4, 2016 at 4:44:48 PM UTC+2, Adam Wysocki wrote:
> >> M.M.<mmarszik@gmail.com>  wrote:
> >>
> >>> Obawiam się, że minimalny będzie działał poprawnie, w przeciwnym
> >>> razie żaden program by nie działał. To jest efekt jakiś dziwnych
> >>> interakcji pomiędzy elementami dużego programu.
> >>
> >> Spróbuj dodać do kompilacji opcję -E i obejrzyj plik wynikowy, będzie to
> >> wynik preprocesora. Może rzeczywiście coś przykrywa Result...
> >>
> >> --
> >> http://www.chmurka.net/
> >
> > Kurcze, ale to jest mało prawdopodobne, aby coś przykrywało i kod się
> > kompilował, nazwy pól i metod byłyby inne. Tak dziwnego błędu w życiu
> > nie widziałem.
> 
> w jednym kompilatorze jak kompilowałem większy projekt była zmienna 
> statyczna i jak się potem okazało zmienna globalna o tej samej nazwie - 
> przy kompilacji "0" ostrzeżeń, a po kompilacji losowe przykrywanie się 
> tych zmiennych. Dlatego teraz ścigam osoby współpracujące, aby jeśli nie 
> ma takiej potrzeby zmiennych globalnych nie używali, a jak już to przy 
> okazji dawali dokladny opis, co to za zmienna do czego i dokladnie jak 
> sie nazywa oraz dlaczego musieli jej użyć - na razie w nowych projektach 
> użycie zmiennych globalnych spadło do 0 :) Nikt nie lubi pisać 
> dokumentacji :)

Dobre :)

Kiedyś w debugerze też miałem problem z przykrywaniem się zmiennych
lokalnych statycznych z globalnymi. Nigdy nie wiedziałem, czy debuger
pokazuje wartość zmiennej lokalnej czy globalnej. Potem też tak
restrykcyjnie podszedłem do tematu, po co te zmienne globalne? W
końcu po latach trochę zluzowałem, dopuszczam pewną ilość zmiennych
globalnych, ale muszą się odpowiednio nazywać, albo być obudowane
klasą i dostęp jest tylko za pośrednictwem statycznych metod, czyli
defacto są składowymi statycznymi a nie globalnymi. 

Pozdrawiam

> Dlatego teraz ścigam osoby współpracujące, aby
> jeśli nie ma takiej potrzeby zmiennych globalnych nie używali, a jak
> już to przy okazji dawali dokladny opis, co to za zmienna do czego i
> dokladnie jak sie nazywa oraz dlaczego musieli jej użyć - na razie w
> nowych projektach użycie zmiennych globalnych spadło do 0 :) Nikt nie
> lubi pisać dokumentacji :)

Globalne powinny być jakoś szczególnie oznaczone, np. prefiksem g_ czy nawet 
global_


-- 
Wiktor S.

Użytkownik "M.M." <mmarszik@gmail.com> napisał:

> Result res;

Zmien na:

struct Result res;

a Twoje problemy powinny sie skonczyc.

On Monday, May 9, 2016 at 5:33:44 PM UTC+2, AK wrote:
> Użytkownik "M.M." <mmarszik@gmail.com> napisał:
> 
> > Result res;
> 
> Zmien na:
> 
> struct Result res;
> 
> a Twoje problemy powinny sie skonczyc.

Hmmm myślałem że to jedno i to samo. Dlaczego uważasz że
to powinno pomóc?
Pozdrawiam

M.M. <mmarszik@gmail.com> wrote:

> Może środowisko ma jakiś problem i przy rebuild nie rekompilowało 
> wszystkiego od nowa, może dostawał się jakiś stary plik *.o ?

To się zdarza i w sumie może powodować tego typu błędy. Szczególnie gdy 
zmieniasz headery, a zależności nie są dobrze śledzone.

-- 
http://www.chmurka.net/

AK <nobody@nowhere.com> wrote:

>> Result res;
> 
> Zmien na:
> 
> struct Result res;
> 
> a Twoje problemy powinny sie skonczyc.

Dlaczego, co to zmienia? Myślisz że jest gdzieś symbol Result, który nie 
jest strukturą?

-- 
http://www.chmurka.net/

AK <nobody@nowhere.com> wrote:

>> Result res;
> 
> Zmien na:
> 
> struct Result res;
> 
> a Twoje problemy powinny sie skonczyc.

Dlaczego, co to zmienia? Myślisz że jest gdzieś typ Result, który nie jest 
strukturą?

-- 
http://www.chmurka.net/