Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: Nie ma takiego pliku ani katalogu

7 views
Skip to first unread message

RM

unread,
Aug 14, 2020, 11:13:54 AM8/14/20
to
Program w C++ (g++) mi się wywala z core dumped. gdb pokazuje:

Program terminated with signal SIGSEGV, Segmentation fault.
#0 __memmove_avx_unaligned_erms ()
at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:371
371 ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: Nie ma
takiego pliku ani katalogu.

co mam z tym zrobić?

Mateusz Viste

unread,
Aug 14, 2020, 2:05:06 PM8/14/20
to
Zainteresować się nie samą implementacją memmove(), bo ta
najprawdopodobniej jest poprawna, tylko swoim własnym kodem który to
memmove() wywołuje (ew. opakowane w jakieś memcpy, strcpy itp).

W core dump powinieneś znaleźć nazwę swojej funkcji, która to felerne
wywołanie wykonała - wraz z numerem linijki kodu. Zapewne kopiujesz
dane do zbyt małego bufora, lub próbujesz czytać z miejsca które do
ciebie nie należy albo po prostu dotknął cię dangling pointer... gdb
wyświetli ci argumenty które podałeś w memmove(), być może wystarczy je
obejrzeć aby dojść do przyczyny problemu.

Mateusz

RM

unread,
Aug 19, 2020, 6:13:20 AM8/19/20
to
W dniu 14.08.2020 o 20:05, Mateusz Viste pisze:
#1 0x00007f1ffb789848 in std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >::_M_replace(unsigned
long, unsigned long, char const*, unsigned long) () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#2 0x0000000000410972 in obfuscator::get_cmdline_options (this=0x122ee70,
argc=6, argv=0x7ffdd5998e48) at src/obfuscator.cpp:80
#3 0x0000000000407ae7 in main (argc=6, argv=0x7ffdd5998e48)
at src/dirtyphp.cpp:42


bool obfuscator::get_cmdline_options(int argc, const char *argv[]) {
if (argc < 3) {
error_messages += "Invalid usage. Too few arguments.\n";
return false;
}
php_application_dir = argv[1];
php_result_dir = argv[2]; // TU BŁĄD (wiersz 80)

php_result_dir jest właściwością w klasie obfuscator, typu string.
Nie rozumiem dlaczego błąd przy przypisaniu.

RM

unread,
Aug 20, 2020, 4:21:15 AM8/20/20
to
W dniu 19.08.2020 o 12:13, RM pisze:
> #1  0x00007f1ffb789848 in std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> >::_M_replace(unsigned
> long, unsigned long, char const*, unsigned long) () from
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> #2  0x0000000000410972 in obfuscator::get_cmdline_options (this=0x122ee70,
>     argc=6, argv=0x7ffdd5998e48) at src/obfuscator.cpp:80
> #3  0x0000000000407ae7 in main (argc=6, argv=0x7ffdd5998e48)
>     at src/dirtyphp.cpp:42
>
>
> bool obfuscator::get_cmdline_options(int argc, const char *argv[]) {
>     if (argc < 3) {
>         error_messages += "Invalid usage. Too few arguments.\n";
>         return false;
>     }
>     php_application_dir = argv[1];
>     php_result_dir = argv[2]; // TU BŁĄD (wiersz 80)
>
> php_result_dir jest właściwością w klasie obfuscator, typu string.
> Nie rozumiem dlaczego błąd przy przypisaniu.

Jak dam tak:
php_result_dir = ""; // w konstruktorze
...
TRACE("php_result_dir before:" << php_result_dir);
assert(php_result_dir.empty());
php_result_dir = argv[2]; // TU BŁĄD!!!
to mam assert failed, a TRACE wypisuje pusty string to dwukropku.
Nie wiem o co chodzi.

Mateusz Viste

unread,
Aug 20, 2020, 4:39:57 AM8/20/20
to
2020-08-20 o 10:21 +0200, RM napisał:
> Jak dam tak:
> php_result_dir = ""; // w konstruktorze
> ...
> TRACE("php_result_dir before:" << php_result_dir);
> assert(php_result_dir.empty());
> php_result_dir = argv[2]; // TU BŁĄD!!!
> to mam assert failed, a TRACE wypisuje pusty string to dwukropku.
> Nie wiem o co chodzi.

Sory, też nie wiem. To C++ jest, a ja ogarniam tylko C (bez plusów),
zupełnie nie wiem jak te plusowe stringi powinny działać. Ew. zapytaj na
pl.comp.lang.c, bo problem raczej nie jest specyficznie linuksowy.
Jeśli zapytasz tam, podaj również swoją deklarację php_result_dir oraz
sposób w jaki to allokujesz (jeśli w ogóle).

Mateusz

Bogdan

unread,
Aug 20, 2020, 6:12:00 AM8/20/20
to
W dniu 20.08.2020 o 10:39, Mateusz Viste pisze:
Podłączam się pod to, zwłaszcza ostatnie zdanie.
Nie będę udawał, że jestem jakiś C++ master (też wolę C), ale w C++
można przeciążyć operator, taki jak "=", i ma to miejsce też w
przypadku klasy string. Linia "php_result_dir = argv[2]" wywołuje kod
z klasy string, który potem różnymi ścieżkami trafia do metody
_M_replace(), którą widać na stack trace.
Jako że nie ma tu przypisania "string = string", tylko "string =
char*", to tak tylko zgaduję, że php_result_dir musi być już
zainicjalizowana na cokolwiek (aby wewnętrzna struktura do trzymania
zawartości była już zaallokowana), bo pewniee kopiowanie string-string
jest zaimplementowane prościej. Niby to już masz, ale nie mogę
odtworzyć tego problemu u siebie (g++ 9.2.1).
Mój szybki test pokazuje, że nie musi chodzić akurat o alokację (tj.
mój przypadek testowy się nie wywala), więc może rolę gra tu coś
jeszcze. Może php_result_dir miał już przypisaną wartość, ale w
międzyczasie wewnętrzny wskaźnik (czy cokolwiek) został
zresetowany/popsuty/zmieniony na NULL i na tym właśnie pada memmove().
Operator << też jest przeciążony, a pusty wynik może oznaczać wiele
rzeczy: niezaallokowana zmienna, pusta tablica, NULL i może jeszcze
coś. To już zależy od implementacji klasy string, co ona w takich
przypadkach wyświetla.
A co jest w argv[2]? Może NULL lub pusty string i to coś psuje?


--
Pozdrawiam/Regards - Bogdan (GNU/Linux & FreeDOS)
Kurs asemblera x86 (DOS, GNU/Linux): http://bogdro.evai.pl
Grupy dyskusyjne o asm: pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
www.Xiph.org www.TorProject.org Soft(EN): http://bogdro.evai.pl/soft

RM

unread,
Aug 20, 2020, 7:48:47 AM8/20/20
to
W dniu 20.08.2020 o 12:11, Bogdan pisze:
kod:
TRACE("php_result_dir before:" << php_result_dir.length() << ",argv[2]
before:" << strlen(argv[2]));
produkuje:
php_result_dir before:9574696,argv[2] before:72
Nie wiem o co chodzi bo jedyną modyfikację jaką robię na php_result_dir
wcześniej jest:
php_result_dir = "";
w konstruktorze (zrobiłem Find in Files w VSCode).

RM

unread,
Aug 20, 2020, 8:32:44 AM8/20/20
to
W dniu 20.08.2020 o 13:48, RM pisze:

> kod:
>     TRACE("php_result_dir before:" << php_result_dir.length() <<
> ",argv[2] before:" << strlen(argv[2]));
> produkuje:
>     php_result_dir before:9574696,argv[2] before:72
> Nie wiem o co chodzi bo jedyną modyfikację jaką robię na php_result_dir
> wcześniej jest:
>         php_result_dir = "";
> w konstruktorze (zrobiłem Find in Files w VSCode).

Jak przedtem zrobię php_result_dir.clear() to mam na tej instrukcji
SIGSEGV Segmentation fault.

Mateusz Viste

unread,
Aug 20, 2020, 8:36:51 AM8/20/20
to
To potwierdza raczej, że źle inicjalizujesz/alokujesz (czy co tam
innego trzeba zrobić w C++) obiekt php_result_dir, i wywołując jego
metody trafiasz w dziurę czasoprzestrzenną. W jaki sposób stworzyłeś
ten obiekt?

Mateusz

RM

unread,
Aug 20, 2020, 8:39:38 AM8/20/20
to
W dniu 20.08.2020 o 14:36, Mateusz Viste pisze:
class obfuscator {
private:
...
std::string php_application_dir, php_result_dir;
...
public:
obfuscator() {
status = s_not_ready;
php_application_dir = "";
php_result_dir = "";
...
}
...
}

Nic innego nie robię.

RM

unread,
Aug 20, 2020, 1:33:02 PM8/20/20
to
W dniu 20.08.2020 o 14:39, RM pisze:
Nie wiem czy to ma jakiś związek, ale jak zrobię:

class obfuscator {
...
public:
obfuscator() { // TUTAJ PROBLEM
status = s_not_ready;
php_application_dir = "";
php_result_dir = "";
keywords = " " + reserved_keywords + " " +
strtoupper(reserved_keywords) + " ";
random_identifiers_length = default_random_identifiers_length;
extension = default_extension;
identifiers = new strvector[index_what_num];
random_identifiers = new strvector[index_what_num];
framework_identifiers = new strvector[index_what_num];
error_messages = "";
}
...
}

int main(int argc, const char *argv[]) {
using namespace std;
TRACE("main called" << endl);
obfuscator dirty;

to dostaję błąd:

#9 0x0000000000409f4f in std::operator+<char, std::char_traits<char>,
std::allocator<char> > (__lhs=...,
__rhs=<error reading variable: Cannot create a lazy string with
address 0x0, and a non-zero length.>) at
/usr/include/c++/7/bits/basic_string.h:5955
#10 0x0000000000408406 in obfuscator::obfuscator (this=0x7ffd5adb6070)
at src/obfuscator.hpp:79
#11 0x000000000040786b in main (argc=6, argv=0x7ffd5adb65b8)

Problem nie występuje jeśli mam w main():
obfuscator *dirty = new obfuscator();

RM

unread,
Aug 21, 2020, 2:04:15 PM8/21/20
to
W dniu 20.08.2020 o 19:33, RM pisze:
Zamieniłem:
> identifiers = new strvector[index_what_num];
> random_identifiers = new strvector[index_what_num];
> framework_identifiers = new strvector[index_what_num];
na alokację na stosie i wszystko działa.

Queequeg

unread,
Aug 22, 2020, 8:18:05 PM8/22/20
to
RM <robert_m...@wp.pl> wrote:

> Zamieniłem:
>> identifiers = new strvector[index_what_num];
>> random_identifiers = new strvector[index_what_num];
>> framework_identifiers = new strvector[index_what_num];
> na alokację na stosie i wszystko działa.

Ale doszedłeś do tego, co było problemem, czy zmieniłeś na ślepo i
zadziałało? Jeśli to drugie, to może się to później zemścić. Może
problem po prostu lepiej się zamaskował i chwilowo tylko nie występuje.

Nie programuj przez koincydencję.

--
Nastolatka wraca nad ranem do domu. Mama jej otwiera, a ona kręcąc
majtkami na palcu mówi:
- Mamo, nie wiem co to za sport, ale to będzie moje hobby.
0 new messages