czwartek, 26 sierpnia 2021 o 19:29:49 UTC+2 Robert Magdziarz napisał(a):
> czwartek, 26 sierpnia 2021 o 18:36:01 UTC+2 Maciek Godek napisał(a):
> > > > Wówczas jednym z pomysłów, oprócz ręcznego napisania przypadków testowych,
byłoby też napisanie generatora losowych danych wejściowych, które powinny spełniać
założenia algorytmu.
> > > tego się praktycznie nie da zrobić, bo danymi wejściowymi do mojego programu są
pliki z kodem źródłowym w PHP (program przetwarza programy w PHP)
> > Dlaczego miałoby się nie dać tego zrobić?
> Mój program dla tych samych danych wejściowych (tego samego kodu PHP) zachowuje się
poprawnie, a czasami (ów rzadki przypadek) niepoprawnie.

Jesteś w stanie odpalać swój program w trybie wsadowym, tzn. bez interfejsu
użytkownika?
Chodziłoby o to, żeby np. odpalić go milion razy, albo przez cały dzień, z tymi
samymi danymi wejściowymi, i zebrać statystyki zachowania programu - w ilu procentach
przypadków daje błędne wyniki.

Kolejny trop to pytanie, czy są w Twoim programie jakieś funkcje, których zachowanie
zależy od aktualnej daty/godziny, albo czy używasz jakichś funkcji randomizujących.

Poza tym niedeterminizm zachowania może się brać z dostępu do systemu plików albo do
jakichś zasobów sieciowych.

Ewentualnie może się też okazać, że problem jest natury sprzętowej, więc możesz
spróbować wykonać testy również na innych maszynach (miałem kiedyś taki problem, że
jedna z moich kości RAM była uszkodzona, i komputer zachowywał się bardzo dziwnie.
Pamięć RAM można akurat sprawdzić za pomocą różnych skanerów)

do góry

piątek, 27 sierpnia 2021 o 08:04:01 UTC+2 Robert Magdziarz napisał(a):
> czwartek, 26 sierpnia 2021 o 21:54:16 UTC+2 heby napisał(a):
> > On 26/08/2021 21:32, Robert Magdziarz wrote:
> > > ==4215== ERROR SUMMARY: 8864 errors from 8 contexts (suppressed: 0 from 0)
> > Nie ma nic wcześniej?
> >

> ==4215== Conditional jump or move depends on uninitialised value(s)
> ==4215== at 0x590A80D: __wmemchr_avx2 (memchr-avx2.S:233)

To ostrzeżenie sugeruje, że teoretycznie może to być problem z implementacją funkcji
wmemchr dla procesorów Intela z tymi ich czarodziejskimi rozszerzeniami. Możesz
spróbować skompilować z flagą -march=x86_64 i zobaczyć, czy valgrind będzie nadal
wypluwał to ostrzeżenie. Jeżeli nie, to spróbuj użyć tak skompilowanej wersji do
odtworzenia błędu (za pomocą takiego kombajnu, o którym pisałem w poprzednim poście).
Jeżeli błędu nie zdołasz odtworzyć, będzie to oznaczało, że to może być wina błędnej
implementacji funkcji systemowej, i możesz to ewentualnie zgłosić do GCC albo do
Intela.

do góry

piątek, 27 sierpnia 2021 o 10:17:48 UTC+2 Maciek Godek napisał(a):
> Jesteś w stanie odpalać swój program w trybie wsadowym, tzn. bez interfejsu
użytkownika?
> Chodziłoby o to, żeby np. odpalić go milion razy, albo przez cały dzień, z tymi
samymi danymi wejściowymi, i zebrać statystyki zachowania programu - w ilu procentach
przypadków daje błędne wyniki.

rozważę to; ale czy taka statystyka pomoże mi w znalezieniu przyczyny problemu?

> Kolejny trop to pytanie, czy są w Twoim programie jakieś funkcje, których
zachowanie zależy od aktualnej daty/godziny, albo czy używasz jakichś funkcji
randomizujących.

używam w programie generatora liczb losowych ale nie w tym algorytmie

do góry

piątek, 27 sierpnia 2021 o 11:18:55 UTC+2 Robert Magdziarz napisał(a):
> piątek, 27 sierpnia 2021 o 10:17:48 UTC+2 Maciek Godek napisał(a):
> > Jesteś w stanie odpalać swój program w trybie wsadowym, tzn. bez interfejsu
użytkownika?
> > Chodziłoby o to, żeby np. odpalić go milion razy, albo przez cały dzień, z tymi
samymi danymi wejściowymi, i zebrać statystyki zachowania programu - w ilu procentach
przypadków daje błędne wyniki.
> rozważę to; ale czy taka statystyka pomoże mi w znalezieniu przyczyny problemu?

Przede wszystkim, jeżeli zdołasz zautomatyzować odtwarzanie błędu, to to będzie
bardzo pomocne do jego rozwiązania.

Statystykę warto przy okazji poznać, żeby wiedzieć, czego można się spodziewać. Może
być tak, że zebranie statystyki nic nie da, bo warunki testowe będą zawierały błąd
systematyczny. Warto zapoznać się z tą prezentacją -- ona co prawda mówi o wydajności
programów, ale wylicza kilka czynników, które mogą mieć wpływ na zachowanie programu:

https://www.youtube.com/watch?v=r-TLSBdHe1A

W szczególności wyrównanie adresów lub jego brak, jest takim czynnikiem.
Autor prezentacji stworzył plug-in do clanga o nazwie "stabilizer", i gdyby normalnie
błąd nie chciał się odtworzyć, możesz spróbować go użyć (bo on właśnie randomizuje
adresy, do których sięga program)

[Tyle że ja sam tego nigdy nie używałem, więc w razie czego nie pomogę]

> > Kolejny trop to pytanie, czy są w Twoim programie jakieś funkcje, których
zachowanie zależy od aktualnej daty/godziny, albo czy używasz jakichś funkcji
randomizujących.
> używam w programie generatora liczb losowych ale nie w tym algorytmie

Losowych, czy pseudo-losowych?

do góry

> > > Kolejny trop to pytanie, czy są w Twoim programie jakieś funkcje, których
zachowanie zależy od aktualnej daty/godziny, albo czy używasz jakichś funkcji
randomizujących.
> > używam w programie generatora liczb losowych ale nie w tym algorytmie
> Losowych, czy pseudo-losowych?

pseudo, komputery są kiepskie w generowaniu liczb losowych

do góry

On 27/08/2021 08:04, Robert Magdziarz wrote:
> ==4215== by 0x43783B: backslash_special(std::__cxx11::basic_string<wchar_t
, std::char_traits<wchar_t>, std::allocator<wchar_t> >) (common.hpp:404)
> ==4215== by 0x4389FC: exec_php_script(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >) (common.hpp:409)

Gdzieś w tej okolicy możesz działać na niezainicjowanej pamięci. Albo
wyskoczyłeś poza zakres tablicy albo wręcz przekazałałeś zdeallokowany
pointer wskazujacy w kosmos.

> ==4215== Conditional jump or move depends on uninitialised value(s)
> ==4215== by 0x424ABA: is_subdir_of_any(std::__cxx11::basic_string<wchar_t,
std::char_traits<wchar_t>, std::allocator<wchar_t> >,
std::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> > > > const&) (common.cpp:476)
> ==4215== by 0x452EC6: obfuscator::remember_identifiers(std::__cxx11::basic
_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >,
identifiers_vector*, bool, bool) (obfuscator.cpp:1440)

Tu podobnie.

Sprawdź co robisz w tych linijkach, które podpowiedział valgrind.

Przy okazji: kompilowałeś program z -O0? Takie błedy często się
ujawniają po wyłączeniu optymalizacji.

do góry

piątek, 27 sierpnia 2021 o 14:42:06 UTC+2 heby napisał(a):
> On 27/08/2021 08:04, Robert Magdziarz wrote:
> > ==4215== by 0x43783B: backslash_special(std::__cxx11::basic_string<wchar_t
, std::char_traits<wchar_t>, std::allocator<wchar_t> >) (common.hpp:404)
> > ==4215== by 0x4389FC: exec_php_script(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >) (common.hpp:409)
> Gdzieś w tej okolicy możesz działać na niezainicjowanej pamięci. Albo
> wyskoczyłeś poza zakres tablicy albo wręcz przekazałałeś zdeallokowany
> pointer wskazujacy w kosmos.
> > ==4215== Conditional jump or move depends on uninitialised value(s)
> > ==4215== by 0x424ABA: is_subdir_of_any(std::__cxx11::basic_string<wchar_t,
std::char_traits<wchar_t>, std::allocator<wchar_t> >,
std::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> > > > const&) (common.cpp:476)
> > ==4215== by 0x452EC6: obfuscator::remember_identifiers(std::__cxx11::basic
_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >,
identifiers_vector*, bool, bool) (obfuscator.cpp:1440)
> Tu podobnie.
>
> Sprawdź co robisz w tych linijkach, które podpowiedział valgrind.

kod wygląda ok

> Przy okazji: kompilowałeś program z -O0? Takie błedy często się
> ujawniają po wyłączeniu optymalizacji.

co to znaczy "ujawniają się"? core dumped?

do góry

On 27/08/2021 16:58, Robert Magdziarz wrote:
>> Przy okazji: kompilowałeś program z -O0? Takie błedy często się
>> ujawniają po wyłączeniu optymalizacji.
> co to znaczy "ujawniają się"? core dumped?

Nie tylko. Możesz mieć wiecej sytuacji błednych, które wcześniej
przechodziły. Przykładowo: urwana referencja do obiektu na stosie (który
został zniszczony) w przypadku -O0 wylatuje błedem znacznie częsciej niż
przy -O2. Z uwagi na to że -O0 robi ogólnie wiecej operacji (np. nie
robi inline i zamazuje stos) i ma większe szanse wdepnąć w śmieci.

do góry

On 27/08/2021 16:58, Robert Magdziarz wrote:
>> Sprawdź co robisz w tych linijkach, które podpowiedział valgrind.
> kod wygląda ok

Zaryzykuje, że urwalo Ci gdzieś referencje. Valgrid raportuje podobne
rzeczy w przypadku std::string const& getTempValue(); czyli to co
zostanie zwrócone jest czasami jeszcze troche działające i wylatuje
później, przy dalszych operacjach.

do góry

piątek, 27 sierpnia 2021 o 17:13:08 UTC+2 heby napisał(a):
> On 27/08/2021 16:58, Robert Magdziarz wrote:
> >> Sprawdź co robisz w tych linijkach, które podpowiedział valgrind.
> > kod wygląda ok
> Zaryzykuje, że urwalo Ci gdzieś referencje. Valgrid raportuje podobne
> rzeczy w przypadku std::string const& getTempValue(); czyli to co
> zostanie zwrócone jest czasami jeszcze troche działające i wylatuje
> później, przy dalszych operacjach.

wydaje mi się że wszystko jest dobrze
poza tym wymienione wiersze kodu nie należą do wspomnianego "wadliwego" algorytmu,
który mam poprawić

do góry