🚀 go-pugleaf

On 21/09/2021 11:59, Robert Magdziarz wrote:
> Udało mi się znowu wygenerować kilka razy przypadek strs=="" z wiersza poleceń. Niestety program uruchomiony pod VSCode z debugowaniem (ten sam exec i te same argumenty i te same dane wejściowe) daje strs!="".
> Jak to wytłumaczyć?

Innymi śmieciami na stosie lub heapie.

Sprawdź, czy zmiana optymalizacji na różne kombinacje, nie ma na to wpływu.

Masz duża szansę na urwaną referencję wskazujacą w kosmos.

On 22/09/2021 11:59, Robert Magdziarz wrote:
>>> teraz mam strs=="" i z wiersza poleceń i pod debugerem
>> I co jest na callstacku?
> Jak pisałem, pomyliłem się w poście: powinno być: teraz mam strs!="" i z wiersza poleceń i pod debugerem

Ok, ale to źle czy dobrze? A jak źle, to co jest na callstacku?

środa, 22 września 2021 o 12:53:07 UTC+2 heby napisał(a):
> On 22/09/2021 11:59, Robert Magdziarz wrote: 
> >>> teraz mam strs=="" i z wiersza poleceń i pod debugerem 
> >> I co jest na callstacku? 
> > Jak pisałem, pomyliłem się w poście: powinno być: teraz mam strs!="" i z wiersza poleceń i pod debugerem
> Ok, ale to źle czy dobrze? A jak źle, to co jest na callstacku?
To jest dobrze, tzn. nie jest to przypadek błędnego działania, znowu nie mogę go wygenerować

środa, 22 września 2021 o 13:13:54 UTC+2 Robert Magdziarz napisał(a):
> środa, 22 września 2021 o 12:53:07 UTC+2 heby napisał(a): 
> > On 22/09/2021 11:59, Robert Magdziarz wrote: 
> > >>> teraz mam strs=="" i z wiersza poleceń i pod debugerem 
> > >> I co jest na callstacku? 
> > > Jak pisałem, pomyliłem się w poście: powinno być: teraz mam strs!="" i z wiersza poleceń i pod debugerem 
> > Ok, ale to źle czy dobrze? A jak źle, to co jest na callstacku?
> To jest dobrze, tzn. nie jest to przypadek błędnego działania, znowu nie mogę go wygenerować

Mnie się zdaje, że debugger będzie tutaj o tyle mało pomocny, że o ile w niektórych sytuacjach można np. założyć pułapkę na zapis pod konkretny adres, o tyle tutaj pewnie wszystko się odbywa w pamięci dynamicznej.

Nie wiem, czy są jakieś wizualizatory zawartości pamięci, ale nawet jeśli tak, to nie spodziewałbym się, żeby dało się z nich coś łatwo wywnioskować.

Raczej bym się opierał na logach: sprawdzałbym (szeroko pojętą) spójność danych przed i po wywołaniach funkcji bibliotecznych, i jeżeli udałoby mi się zalogować w którymś miejscu coś podejrzanego, to dopiero wtedy spróbowałbym pracy krokowej.

(Najbardziej komfortowe warunki pracy w takich okolicznościach to oczywiście taka sytuacja, kiedy błąd zawsze daje się odtwarzać. Dla prostych programów można by było po prostu zrzucać ramkę stosu, ale nie wiem, na ile dobrze współczesne debuggery radzą sobie z zawartością sterty)

środa, 22 września 2021 o 16:03:23 UTC+2 Maciek Godek napisał(a):
> Mnie się zdaje, że debugger będzie tutaj o tyle mało pomocny, że o ile w niektórych sytuacjach można np. założyć pułapkę na zapis pod konkretny adres, o tyle tutaj pewnie wszystko się odbywa w pamięci dynamicznej. 

próbuje debugować, żeby sprawdzić co się dzieje w moim algorytmie nie tak, że na koniec strs=="" a nie strs!=""
moim zdaniem to droga do znalezienia błędu

Mam pytanie: czy zaobserwowany przeze mnie niedeterminizm błędu (tzn. raz występuje raz nie - przy tych samych argumentach i danych wejściowych) może wynikać z błędu logicznego w algorytmie? (przypomnę że w moim algorytmie nie używam generatora liczb pseudolosowych, dostępu do sieci ani systemu plików - poza danymi wejściowymi).

On 22/09/2021 19:24, Robert Magdziarz wrote:
> Mam pytanie: czy zaobserwowany przeze mnie niedeterminizm błędu (tzn. raz występuje raz nie - przy tych samych argumentach i danych wejściowych) może wynikać z błędu logicznego w algorytmie?

Z błędu logicznego mógłby wynikać, gdyby algortym zawierał rand().

W innym przypadku *raczej* z błedu implementacji.

Masz gdzieś odczyt niezainicjowanych lub zwolninych wartości. Oczywiście 
nie mam pewności, ale przeczucie.

A kompilator nie marudzi, że użyte konstrukcje są niebezpieczne?

Zainteresuj się:

https://elinux.org/Electric_Fence
https://duma.sourceforge.io/
https://en.wikipedia.org/wiki/AddressSanitizer

Użyj clanga i zobacz czy on się inaczej zachowuje.

Przetestuj wszystkie poziomy -O, wliczając w to -Os.

środa, 22 września 2021 o 19:24:23 UTC+2 Robert Magdziarz napisał(a):
> Mam pytanie: czy zaobserwowany przeze mnie niedeterminizm błędu (tzn. raz występuje raz nie - przy tych samych argumentach i danych wejściowych) może wynikać z błędu logicznego w algorytmie? (przypomnę że w moim algorytmie nie używam generatora liczb pseudolosowych, dostępu do sieci ani systemu plików - poza danymi wejściowymi).

Ciężko powiedzieć, jeżeli nie widziało się kodu, ale jeżeli wypróbowałeś wszystkie dotychczasowe sugestie, i to nie pomogło, to bym się spodziewał, że problem leży w jakiejś zewnętrznej bibliotece, która może się różnie zachowywać w różnych okolicznościach.

Wydaje mi się, że rozsądnie byłoby naszpikować wszystkie odwołania do zewnętrznych bibliotek asercjami, wyrażającymi różne oczekiwane własności danych wejściowych i wyjściowych (tylko bym zrobił tak, żeby asercja nie wywalała programu, tylko na przykład logowała, że coś jest nie tak, albo ustawiała breakpoint w debuggerze)

środa, 22 września 2021 o 23:22:27 UTC+2 Maciek Godek napisał(a):
> Ciężko powiedzieć, jeżeli nie widziało się kodu
Moim zdaniem algorytm który nie zawiera niedeterministycznych konstrukcji (takich jak random()) zachowuje się jak funkcja matematyczna, która dla argumentu (danych wejściowych) zwraca zawsze tą samą wartość (dane wyjściowe). Więc mój program powinien zwracać zawsze tą samą wartość. Skoro tak nie jest to musi być błąd dostępu do losowej (niezainicjowanej) pamięci, błąd logiczny algorytmu nie owocowałby różnymi wartościami wynikowymi. Takie jest moje rozumowanie.
BTW: po polsku jest "trudno powiedzieć", "ciężko powiedzieć" to rusycyzm ("tiażeło skazat' "), rozpowszechniony niestety.

piątek, 1 października 2021 o 06:24:36 UTC+2 Robert Magdziarz napisał(a):

> BTW: po polsku jest "trudno powiedzieć"

"ciężko powiedzieć" też jest po polsku

> "ciężko powiedzieć" to rusycyzm ("tiażeło skazat' "), rozpowszechniony niestety.

o proszę, a tutaj ktoś twierdzi, że germanizm:
https://sjp.pwn.pl/poradnia/haslo/ciezko-powiedziec;5723.html

a może po prostu jest tak, że wiele języków odnosi się do tej samej - zakotwiczonej w podobnym doświadczeniu kulturowym - metafory pojęciowej [por. Lakoff i Johnson, "Metafory w naszym życiu"], według której "trud = ciężar"?

Robert Magdziarz <robert.magdziarz.1972@gmail.com> Wrote in message:
> Napisałem program w C++. Zawiera błąd którego szczegółów nie znam. Błąd (niepoprawne wartości zapisywane do pliku) występuje rzadko, nie wiem w jakich okolicznościach. Wstawiłem asercje i testuję, niestety nie udało mi się odtworzyć problemu.Jak podejść do problemu, jakiej strategii użyć? Co mogę zrobić poza asercjami? Debugowanie nie ma sensu bo błąd występuje zbyt rzadko.


Są trzy możliwości:

1. twój błąd, tj. coś gdzieś źle masz w kodzie źródłowym (99%)
2. błąd kompilatora, rzadkie ale możliwe (0.01%);
3. problem z hardware (0.99%).

Sprawdź na innym komputerze. Użyj innego kompulatora. Zostaje 99%.

Drastyczne rozwiązanie - przepisz na Javę lub C#. Może nie pomoże,
 ale pozbędziesz się problemów z tańcem po wskaźnikach, nadpisania
 mi pamięci itp.

Sprawdź czy stos nie jest za mały. 

Spróbuj zrzucić do logów jakie funkcje były wywoływane od chwili
 uruchomienia do detekcji błędu: błąd jest w tym co było
 używane.

Usuń (tymczasowo) połowę programu - dowiesz się która połowa ma
 błąd (jeżeli jest tylko jeden).

Valgrind itp. mogą pomóc.


----Android NewsGroup Reader----
http://usenet.sinaapp.com/