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

Groups > pl.comp.os.linux.programowanie > #2210 > unrolled thread

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

Back to article view | Back to pl.comp.os.linux.programowanie

Contents

  ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: Nie ma takiego pliku ani katalogu RM <robert_magdziarz@wp.pl> - 2020-08-14 17:13 +0200
    Re: ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: Nie ma takiego pliku ani katalogu Mateusz Viste <mateusz@xyz.invalid> - 2020-08-14 20:05 +0200
      Re: ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: Nie ma takiego pliku ani katalogu RM <robert_magdziarz@wp.pl> - 2020-08-19 12:13 +0200
        Re: ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: Nie ma takiego pliku ani katalogu RM <robert_magdziarz@wp.pl> - 2020-08-20 10:21 +0200
          Re: ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: Nie ma takiego pliku ani katalogu Mateusz Viste <mateusz@xyz.invalid> - 2020-08-20 10:39 +0200
            Re: ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: Nie ma takiego pliku ani katalogu Bogdan <bogdan@poczta.gazeta.pl> - 2020-08-20 12:11 +0200
              Re: ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: Nie ma takiego pliku ani katalogu RM <robert_magdziarz@wp.pl> - 2020-08-20 13:48 +0200
                Re: ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: Nie ma takiego pliku ani katalogu RM <robert_magdziarz@wp.pl> - 2020-08-20 14:32 +0200
                  Re: ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: Nie ma takiego pliku ani katalogu Mateusz Viste <mateusz@xyz.invalid> - 2020-08-20 14:36 +0200
                    Re: ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: Nie ma takiego pliku ani katalogu RM <robert_magdziarz@wp.pl> - 2020-08-20 14:39 +0200
                      Re: ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: Nie ma takiego pliku ani katalogu RM <robert_magdziarz@wp.pl> - 2020-08-20 19:33 +0200
                        Re: ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: Nie ma takiego pliku ani katalogu RM <robert_magdziarz@wp.pl> - 2020-08-21 20:04 +0200
                          Re: ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: Nie ma takiego pliku ani katalogu queequeg@trust.no1 (Queequeg) - 2020-08-23 00:18 +0000

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

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ć?

[toc] | [next] | [standalone]

#2211

2020-08-14 o 17:13 +0200, RM napisał:
> 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ć?

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

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

#2212

W dniu 14.08.2020 o 20:05, Mateusz Viste pisze:
> 2020-08-14 o 17:13 +0200, RM napisał:
>> 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ć?
> 
> 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
> 

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

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

#2213

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.

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

#2214

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

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

#2215

W dniu 20.08.2020 o 10:39, Mateusz Viste pisze:
> 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
> 


 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

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

#2216

W dniu 20.08.2020 o 12:11, Bogdan pisze:
> W dniu 20.08.2020 o 10:39, Mateusz Viste pisze:
>> 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
>>
> 
> 
>   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?
> 
> 
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).

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

#2217

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.

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

#2218

2020-08-20 o 14:32 +0200, RM napisał:
> 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.

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

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

#2219

W dniu 20.08.2020 o 14:36, Mateusz Viste pisze:
> 2020-08-20 o 14:32 +0200, RM napisał:
>> 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.
> 
> 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
> 

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

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

#2220

W dniu 20.08.2020 o 14:39, RM pisze:
> W dniu 20.08.2020 o 14:36, Mateusz Viste pisze:
>> 2020-08-20 o 14:32 +0200, RM napisał:
>>> 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.
>>
>> 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
>>
> 
> 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ę.

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();

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

#2221

W dniu 20.08.2020 o 19:33, RM pisze:
> W dniu 20.08.2020 o 14:39, RM pisze:
>> W dniu 20.08.2020 o 14:36, Mateusz Viste pisze:
>>> 2020-08-20 o 14:32 +0200, RM napisał:
>>>> 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.
>>>
>>> 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
>>>
>>
>> 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ę.
> 
> 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();

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.

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

#2222

RM <robert_magdziarz@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.

[toc] | [prev] | [standalone]

Back to top | Article view | pl.comp.os.linux.programowanie

csiph-web