Ошибка free invalid next size

If you are trying to allocate space for an array of pointers, such as

char** my_array_of_strings;  // or some array of pointers such as int** or even void**

then you will need to consider word size (8 bytes in a 64-bit system, 4 bytes in a 32-bit system) when allocating space for n pointers. The size of a pointer is the same of your word size.

So while you may wish to allocate space for n pointers, you are actually going to need n times 8 or 4 (for 64-bit or 32-bit systems, respectively)

To avoid overflowing your allocated memory for n elements of 8 bytes:

my_array_of_strings = (char**) malloc( n * 8 );  // for 64-bit systems
my_array_of_strings = (char**) malloc( n * 4 );  // for 32-bit systems

This will return a block of n pointers, each consisting of 8 bytes (or 4 bytes if you’re using a 32-bit system)

I have noticed that Linux will allow you to use all n pointers when you haven’t compensated for word size, but when you try to free that memory it realizes its mistake and it gives out that rather nasty error. And it is a bad one, when you overflow allocated memory, many security issues lie in wait.

Источник

Olej

Что-то вот такое:

char *sval = (char*)calloc( zn, sizeof( char ) );
for( ... ) {
   // здесь что-то заполняется  эту строку
}
free( (void*)sval );

Ошибка:

*** Error in `./period1': free(): invalid next size (fast): 0x09413040 ***
Аварийный останов

Только не надо мне писать школярские глупости про «освобождение не размещённой памяти» и т.п.
Про подобные вещи пишут довольно много (поиском): free(): invalid next size (fast) и мн. др. … и все после середины 2012г. и далее, и C и C++.
Компилятор GCC 4.8.4
Что может значить такое сообщение об ошибке?

P.S. И что удивляет: если в free есть преобразование void*, то иногда это проканывает (не всегда), без преобразования — всегда ошибка.


  • Вопрос задан

    более трёх лет назад

  • 1223 просмотра

Нашлась ошибка: в цикле залез (записью 0) в строке на 1 байт дальше длины zn, при этом затирается дескриптор длины следующей области памяти, и при освобождении невозможно восстановить (объединить) свободные регионы.

И вот именно поэтому, при разных уровнях оптимизации (-O0, … -O3) сообщения об ошибке носят совершенно разный характер … что может свести с ума.

Пригласить эксперта

// здесь что-то заполняется эту строку
Здесь поподробнее. Вы могли внутри цикла изменить указатель sval

Лучше всего делать так:

char * const sval = (char*)calloc( zn, sizeof( char ) );

И тогда вы в цикле не ошибётесь (обнаружится на этапе компиляции).


  • Показать ещё
    Загружается…

Сбер
•
Нижний Новгород

от 220 000 ₽

Сбер
•
Нижний Новгород

от 200 000 ₽

24 июн. 2023, в 12:53

25000 руб./за проект

24 июн. 2023, в 12:49

1000 руб./за проект

24 июн. 2023, в 12:33

45000 руб./за проект

Минуточку внимания

Источник

SSxMe

14 / 14 / 2

Регистрация: 09.05.2010

Сообщений: 79

1

21.05.2010, 11:32. Показов 6793. Ответов 9

Метки нет (Все метки)

Студворк — интернет-сервис помощи студентам

Не могу понять в чем ошибка..
Debian lenny

Bash 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84

*** glibc detected *** /home/user/eits/trunk/eits: free(): invalid next size (fast): 0x0806c118 ***
======= Backtrace: =========
/lib/i686/cmov/libc.so.6[0xb7b5f624]
/lib/i686/cmov/libc.so.6(cfree+0x96)[0xb7b61826]
/usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0xb7d372e1]
/home/user/eits/trunk/eits[0x804ffe9]
/home/user/eits/trunk/eits[0x805f210]
/home/user/eits/trunk/eits[0x804aba5]
/lib/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb7b07455]
/home/user/eits/trunk/eits(_ZNSt8ios_base4InitD1Ev+0x4d)[0x804a641]
======= Memory map: ========
08048000-0806b000 r-xp 00000000 08:06 1663706    /home/user/eits/trunk/eits
0806b000-0806c000 rw-p 00023000 08:06 1663706    /home/user/eits/trunk/eits
0806c000-080eb000 rw-p 0806c000 00:00 0          [heap]
b7700000-b7721000 rw-p b7700000 00:00 0
b7721000-b7800000 ---p b7721000 00:00 0
b787a000-b7884000 r-xp 00000000 08:01 250017     /lib/i686/cmov/libnss_files-2.7.so
b7884000-b7886000 rw-p 00009000 08:01 250017     /lib/i686/cmov/libnss_files-2.7.so
b7886000-b7888000 rw-p b7886000 00:00 0
b7888000-b789d000 r-xp 00000000 08:01 250003     /lib/i686/cmov/libnsl-2.7.so
b789d000-b789f000 rw-p 00014000 08:01 250003     /lib/i686/cmov/libnsl-2.7.so
b789f000-b78a1000 rw-p b789f000 00:00 0
b78a1000-b78aa000 r-xp 00000000 08:01 249994     /lib/i686/cmov/libcrypt-2.7.so
b78aa000-b78ac000 rw-p 00008000 08:01 249994     /lib/i686/cmov/libcrypt-2.7.so
b78ac000-b78d3000 rw-p b78ac000 00:00 0
b78d3000-b78e8000 r-xp 00000000 08:01 250000     /lib/i686/cmov/libpthread-2.7.so
b78e8000-b78ea000 rw-p 00014000 08:01 250000     /lib/i686/cmov/libpthread-2.7.so
b78ea000-b78ec000 rw-p b78ea000 00:00 0
b78ec000-b7a92000 r-xp 00000000 08:01 418178     /usr/lib/libmysqlclient_r.so.15.0.0
b7a92000-b7ad6000 rw-p 001a5000 08:01 418178     /usr/lib/libmysqlclient_r.so.15.0.0
b7ad6000-b7ad8000 rw-p b7ad6000 00:00 0
b7ad8000-b7aec000 r-xp 00000000 08:01 413532     /usr/lib/libz.so.1.2.3.3
b7aec000-b7aed000 rw-p 00013000 08:01 413532     /usr/lib/libz.so.1.2.3.3
b7aed000-b7aef000 r-xp 00000000 08:01 250005     /lib/i686/cmov/libdl-2.7.so
b7aef000-b7af1000 rw-p 00001000 08:01 250005     /lib/i686/cmov/libdl-2.7.so
b7af1000-b7c46000 r-xp 00000000 08:01 250009     /lib/i686/cmov/libc-2.7.so
b7c46000-b7c47000 r--p 00155000 08:01 250009     /lib/i686/cmov/libc-2.7.so
b7c47000-b7c49000 rw-p 00156000 08:01 250009     /lib/i686/cmov/libc-2.7.so
b7c49000-b7c4c000 rw-p b7c49000 00:00 0
b7c4c000-b7c58000 r-xp 00000000 08:01 241923     /lib/libgcc_s.so.1
b7c58000-b7c59000 rw-p 0000b000 08:01 241923     /lib/libgcc_s.so.1
b7c59000-b7c7d000 r-xp 00000000 08:01 249989     /lib/i686/cmov/libm-2.7.so
b7c7d000-b7c7f000 rw-p 00023000 08:01 249989     /lib/i686/cmov/libm-2.7.so
b7c7f000-b7d62000 r-xp 00000000 08:01 411594     /usr/lib/libstdc++.so.6.0.10
b7d62000-b7d65000 r--p 000e2000 08:01 411594     /usr/lib/libstdc++.so.6.0.10
b7d65000-b7d67000 rw-p 000e5000 08:01 411594     /usr/lib/libstdc++.so.6.0.10
b7d67000-b7d6e000 rw-p b7d67000 00:00 0
b7d6e000-b7e4f000 r-xp 00000000 08:01 2108       /usr/local/lib/libmysqlcppconn.so.4.1.1.0
b7e4f000-b7e59000 rw-p 000e0000 08:01 2108       /usr/local/lib/libmysqlcppconn.so.4.1.1.0
b7e59000-b7f93000 r-xp 00000000 08:01 11682      /usr/lib/i686/cmov/libcrypto.so.0.9.8
b7f93000-b7fa9000 rw-p 0013a000 08:01 11682      /usr/lib/i686/cmov/libcrypto.so.0.9.8
b7fa9000-b7fac000 rw-p b7fa9000 00:00 0
b7fb7000-b7fba000 rw-p b7fb7000 00:00 0
b7fba000-b7fbb000 r-xp b7fba000 00:00 0          [vdso]
b7fbb000-b7fd5000 r-xp 00000000 08:01 242252     /lib/ld-2.7.so
b7fd5000-b7fd7000 rw-p 0001a000 08:01 242252     /lib/ld-2.7.so
bffea000-bffff000 rw-p bffeb000 00:00 0          [stack]
 
Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb78866c0 (LWP 2801)]
0xb7fba424 in __kernel_vsyscall ()
(gdb) bt
#0  0xb7fba424 in __kernel_vsyscall ()
#1  0xb7b1c640 in raise () from /lib/i686/cmov/libc.so.6
#2  0xb7b1e018 in abort () from /lib/i686/cmov/libc.so.6
#3  0xb7b5934d in ?? () from /lib/i686/cmov/libc.so.6
#4  0x0000000a in ?? ()
#5  0xbfffbdf4 in ?? ()
#6  0x00000400 in ?? ()
#7  0xb7c2f648 in ?? () from /lib/i686/cmov/libc.so.6
#8  0x00000017 in ?? ()
#9  0xbfffee79 in ?? ()
#10 0x0000001a in ?? ()
#11 0xb7c2f661 in ?? () from /lib/i686/cmov/libc.so.6
#12 0x00000002 in ?? ()
#13 0xb7c2f694 in ?? () from /lib/i686/cmov/libc.so.6
#14 0x00000020 in ?? ()
#15 0xb7c2f665 in ?? () from /lib/i686/cmov/libc.so.6
#16 0x00000004 in ?? ()
#17 0xbfffc323 in ?? ()
#18 0x00000008 in ?? ()
#19 0xb7c2f66b in ?? () from /lib/i686/cmov/libc.so.6
#20 0x00000005 in ?? ()
#21 0x00000000 in ?? ()



0

Почетный модератор

7390 / 2636 / 281

Регистрация: 29.07.2006

Сообщений: 13,696

21.05.2010, 12:02

2

SSxMe, да, сообщения об ошибке говорят о многом Лучше бы код показал, если это твоя софтина.

Цитата
Сообщение от SSxMe
Посмотреть сообщение

Не могу понять в чем ошибка.

Ошибка в освобождении памяти. Может, пойнтер неправильный, а может, куча закорраптилась.



1

3364 / 2620 / 322

Регистрация: 11.03.2009

Сообщений: 5,966

21.05.2010, 12:04

3

Еще бы исходник выложил, было бы совсем замечательно.



1

SSxMe

14 / 14 / 2

Регистрация: 09.05.2010

Сообщений: 79

21.05.2010, 12:26

 [ТС]

4

Я бы выложил, но не знаю в каком месте ориентироваться, так как проект уже разросся..
И отладчик не указывает в каком файле надо смотреть..
Может быть можно как то это узнать?

Добавлено через 7 минут
Ошибка происходит предположительно вот тут

C++ 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

            if(cmd.commands.size() == 3){
                // cmd.commands[0] - ID теста
                // cmd.commands[1] - Количество вопросов под выдачу
                // cmd.commands[2] - Время на выполнение теста
                int test_id = boost::lexical_cast<int>(cmd.commands[0]);
                int questions_count = boost::lexical_cast<int>(cmd.commands[1]);
                set<Question*> questions = Eits.questions.GetListByTest(test_id);
                if(questions_count <= (int)questions.size()){
                    Question** toSort = new Question*[questions_count];
                    int i=0;
                    for(set<Question*>::iterator it = questions.begin(); it != questions.end(); it++,i++){
                        toSort[i] = (*it);
                    }
                    Test* test = Eits.tests[test_id];
                    Users* users = &Eits.users;
                    string message_start = prefToBytes(SU_START_TEST) + cmd.commands[0] +
                            'n' + test->Name() +
                            'n' + cmd.commands[1] +
                            'n' + cmd.commands[2]+'n';
                    for(Users::iterator it = users->begin(); it != users->end(); it++){
                        if(!((*it).second)->isAdmin()){
                            for(i=0;i<questions_count;i++){
                                    int random_index = rand()%questions_count;
                                    Question* question = toSort[random_index];
                                    toSort[random_index] = toSort[i];
                                    toSort[i] = question;
                            }
                            string message = "";
                            for(i=0;i<questions_count;i++){
                                    vector<string> answers = toSort[i]->Answers();
                                message += 'n' + boost::lexical_cast<string>(toSort[i]->Id()) +
                                    'n' + toSort[i]->Name() +
                                    'n' + boost::lexical_cast<string>(answers.size());
                                for(vector<string>::iterator it_a = answers.begin(); it_a != answers.end(); it_a++){
                                    message += 'n' + (*it_a);
                                }
                            }
                            message.erase(0,1);
                            SocketServer.SendBytes((*it).first,message_start+message);
                        }
                    }
                    delete toSort;
                }
            }

Может быть я вот это неправильно делаю?

C++ 
1

Question** toSort = new Question*[questions_count];



0

kazak

3364 / 2620 / 322

Регистрация: 11.03.2009

Сообщений: 5,966

21.05.2010, 12:30

5

Если

C++ 
1

Question** toSort = new Question*[questions_count];

то вроде как должен быть

C++ 
1

delete [] toSort;

а не как у тебя в строке 42

C++ 
1

delete toSort;



1

SSxMe

14 / 14 / 2

Регистрация: 09.05.2010

Сообщений: 79

21.05.2010, 12:44

 [ТС]

6

Не помогло..
Но теперь отладчик указывает файлы:

Bash 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129

*** glibc detected *** /home/user/eits/repos/trunk/eits: malloc(): memory corruption: 0x08088030 ***
======= Backtrace: =========
/lib/i686/cmov/libc.so.6[0xb7a9b256]
/lib/i686/cmov/libc.so.6(__libc_malloc+0x95)[0xb7a9c655]
/usr/lib/libstdc++.so.6(_Znwj+0x27)[0xb7c71fd7]
/usr/lib/libstdc++.so.6(_ZNSs4_Rep9_S_createEjjRKSaIcE+0x64)[0xb7c4cc04]
/usr/lib/libstdc++.so.6(_ZNSs4_Rep8_M_cloneERKSaIcEj+0x38)[0xb7c4d678]
/usr/lib/libstdc++.so.6(_ZNSs7reserveEj+0x50)[0xb7c4e6e0]
/usr/lib/libstdc++.so.6(_ZNSs6appendERKSs+0x53)[0xb7c4eb93]
/home/user/eits/repos/trunk/eits(_ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_ERKS6_S8_+0x2c)[0x8052b12]
/home/user/eits/repos/trunk/eits[0x804f50d]
/home/user/eits/repos/trunk/eits[0x805f298]
/home/user/eits/repos/trunk/eits[0x804abd5]
/lib/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb7a40455]
/home/user/eits/repos/trunk/eits(_ZNSt8ios_base4InitD1Ev+0x49)[0x804a671]
======= Memory map: ========
08048000-0806b000 r-xp 00000000 03:01 153996     /home/user/eits/repos/trunk/eits
0806b000-0806c000 rw-p 00023000 03:01 153996     /home/user/eits/repos/trunk/eits
0806c000-0813f000 rw-p 0806c000 00:00 0          [heap]
b7600000-b7621000 rw-p b7600000 00:00 0
b7621000-b7700000 ---p b7621000 00:00 0
b77b3000-b77bd000 r-xp 00000000 03:01 47505      /lib/i686/cmov/libnss_files-2.7.so
b77bd000-b77bf000 rw-p 00009000 03:01 47505      /lib/i686/cmov/libnss_files-2.7.so
b77bf000-b77c1000 rw-p b77bf000 00:00 0
b77c1000-b77d6000 r-xp 00000000 03:01 47495      /lib/i686/cmov/libnsl-2.7.so
b77d6000-b77d8000 rw-p 00014000 03:01 47495      /lib/i686/cmov/libnsl-2.7.so
b77d8000-b77da000 rw-p b77d8000 00:00 0
b77da000-b77e3000 r-xp 00000000 03:01 47489      /lib/i686/cmov/libcrypt-2.7.so
b77e3000-b77e5000 rw-p 00008000 03:01 47489      /lib/i686/cmov/libcrypt-2.7.so
b77e5000-b780c000 rw-p b77e5000 00:00 0
b780c000-b7821000 r-xp 00000000 03:01 47493      /lib/i686/cmov/libpthread-2.7.so
b7821000-b7823000 rw-p 00014000 03:01 47493      /lib/i686/cmov/libpthread-2.7.so
b7823000-b7825000 rw-p b7823000 00:00 0
b7825000-b79cb000 r-xp 00000000 03:01 60606      /usr/lib/libmysqlclient_r.so.15.0.0
b79cb000-b7a0f000 rw-p 001a5000 03:01 60606      /usr/lib/libmysqlclient_r.so.15.0.0
b7a0f000-b7a11000 rw-p b7a0f000 00:00 0
b7a11000-b7a25000 r-xp 00000000 03:01 57372      /usr/lib/libz.so.1.2.3.3
b7a25000-b7a26000 rw-p 00013000 03:01 57372      /usr/lib/libz.so.1.2.3.3
b7a26000-b7a28000 r-xp 00000000 03:01 47497      /lib/i686/cmov/libdl-2.7.so
b7a28000-b7a2a000 rw-p 00001000 03:01 47497      /lib/i686/cmov/libdl-2.7.so
b7a2a000-b7b7f000 r-xp 00000000 03:01 47500      /lib/i686/cmov/libc-2.7.so
b7b7f000-b7b80000 r--p 00155000 03:01 47500      /lib/i686/cmov/libc-2.7.so
b7b80000-b7b82000 rw-p 00156000 03:01 47500      /lib/i686/cmov/libc-2.7.so
b7b82000-b7b85000 rw-p b7b82000 00:00 0
b7b85000-b7b91000 r-xp 00000000 03:01 39363      /lib/libgcc_s.so.1
b7b91000-b7b92000 rw-p 0000b000 03:01 39363      /lib/libgcc_s.so.1
b7b92000-b7bb6000 r-xp 00000000 03:01 47485      /lib/i686/cmov/libm-2.7.so
b7bb6000-b7bb8000 rw-p 00023000 03:01 47485      /lib/i686/cmov/libm-2.7.so
b7bb8000-b7c9b000 r-xp 00000000 03:01 55434      /usr/lib/libstdc++.so.6.0.10
b7c9b000-b7c9e000 r--p 000e2000 03:01 55434      /usr/lib/libstdc++.so.6.0.10
b7c9e000-b7ca0000 rw-p 000e5000 03:01 55434      /usr/lib/libstdc++.so.6.0.10
b7ca0000-b7ca7000 rw-p b7ca0000 00:00 0
b7ca7000-b7d88000 r-xp 00000000 03:01 104385     /usr/local/lib/libmysqlcppconn.so.4.1.1.0
b7d88000-b7d92000 rw-p 000e0000 03:01 104385     /usr/local/lib/libmysqlcppconn.so.4.1.1.0
b7d92000-b7ecc000 r-xp 00000000 03:01 75152      /usr/lib/i686/cmov/libcrypto.so.0.9.8
b7ecc000-b7ee2000 rw-p 0013a000 03:01 75152      /usr/lib/i686/cmov/libcrypto.so.0.9.8
b7ee2000-b7ee5000 rw-p b7ee2000 00:00 0
b7ef0000-b7ef3000 rw-p b7ef0000 00:00 0
b7ef3000-b7ef4000 r-xp b7ef3000 00:00 0          [vdso]
b7ef4000-b7f0e000 r-xp 00000000 03:01 39692      /lib/ld-2.7.so
b7f0e000-b7f10000 rw-p 0001a000 03:01 39692      /lib/ld-2.7.so
bffeb000-c0000000 rw-p bffeb000 00:00 0          [stack]
 
Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb77bf6c0 (LWP 2364)]
0xb7ef3424 in __kernel_vsyscall ()
(gdb) bt
#0  0xb7ef3424 in __kernel_vsyscall ()
#1  0xb7a55640 in raise () from /lib/i686/cmov/libc.so.6
#2  0xb7a57018 in abort () from /lib/i686/cmov/libc.so.6
#3  0xb7a9234d in ?? () from /lib/i686/cmov/libc.so.6
#4  0x00000009 in ?? ()
#5  0xbfffdc30 in ?? ()
#6  0x00000400 in ?? ()
#7  0x000001e8 in ?? ()
#8  0xb7b68648 in ?? () from /lib/i686/cmov/libc.so.6
#9  0x00000017 in ?? ()
#10 0xbffffe65 in ?? ()
#11 0x00000020 in ?? ()
#12 0xb7b68661 in ?? () from /lib/i686/cmov/libc.so.6
#13 0x00000002 in ?? ()
#14 0xb7b655d1 in ?? () from /lib/i686/cmov/libc.so.6
#15 0x0000001b in ?? ()
#16 0xb7b68665 in ?? () from /lib/i686/cmov/libc.so.6
#17 0x00000004 in ?? ()
#18 0xbfffe1df in ?? ()
#19 0x00000008 in ?? ()
#20 0xb7b6866b in ?? () from /lib/i686/cmov/libc.so.6
#21 0x00000005 in ?? ()
#22 0x000094f4 in ?? ()
---Type <return> to continue, or q <return> to quit---
#23 0xb7b86595 in ?? () from /lib/libgcc_s.so.1
#24 0x0806b6de in sha256(char const*)::oBuffer ()
#25 0x00000005 in ?? ()
#26 0xbfffe248 in ?? ()
#27 0xb7b6866b in ?? () from /lib/i686/cmov/libc.so.6
#28 0xb7b6866b in ?? () from /lib/i686/cmov/libc.so.6
#29 0x00000005 in ?? ()
#30 0xbfffdb60 in ?? ()
#31 0x00000003 in ?? ()
#32 0xbfffe1df in ?? ()
#33 0x00000008 in ?? ()
#34 0xbfffdb80 in ?? ()
#35 0xb7a92250 in ?? () from /lib/i686/cmov/libc.so.6
#36 0xbfffe1df in ?? ()
#37 0xb7a69cb7 in vfprintf () from /lib/i686/cmov/libc.so.6
#38 0xb7a9b256 in ?? () from /lib/i686/cmov/libc.so.6
#39 0x00000002 in ?? ()
#40 0xb7b68648 in ?? () from /lib/i686/cmov/libc.so.6
#41 0xbffffe65 in ?? ()
#42 0xb7b655d1 in ?? () from /lib/i686/cmov/libc.so.6
#43 0xbfffe1df in ?? ()
#44 0xb7b814e0 in ?? () from /lib/i686/cmov/libc.so.6
#45 0xb7a946b4 in _IO_file_sync () from /lib/i686/cmov/libc.so.6
---Type <return> to continue, or q <return> to quit---
#46 0xb7a9c655 in malloc () from /lib/i686/cmov/libc.so.6
#47 0xb7c71fd7 in operator new () from /usr/lib/libstdc++.so.6
#48 0xb7c4cc04 in std::string::_Rep::_S_create () from /usr/lib/libstdc++.so.6
#49 0xb7c4d678 in std::string::_Rep::_M_clone () from /usr/lib/libstdc++.so.6
#50 0xb7c4e6e0 in std::string::reserve () from /usr/lib/libstdc++.so.6
#51 0xb7c4eb93 in std::string::append () from /usr/lib/libstdc++.so.6
#52 0x08052b12 in std::operator+<char, std::char_traits<char>, std::allocator<char> > (__lhs=@0xbfffe6f8, __rhs=@0xbfffe6f4)
    at /usr/include/c++/4.3/bits/basic_string.h:2087
#53 0x0804f50d in answer (sock=7, r=
        {static npos = 4294967295, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0xbfffec08 "4у06b230&bbЮКЪ©a"}}) at main.cpp:287
#54 0x0805f298 in Socket::ReadBytes (this=0x806b5e0,
    answer=0x804b49f <answer(int, std::string)>)
    at include/trsys/nb_socket.cpp:152
#55 0x0804abd5 in main () at main.cpp:367
Bash 
1

*** glibc detected *** /home/user/eits/repos/trunk/eits: malloc(): memory corruption: 0x08088030 ***
Bash 
1
2

#53 0x0804f50d in answer (sock=7, r=
        {static npos = 4294967295, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0xbfffec08 "4у06b230&bbЮКЪ©a"}}) at main.cpp:287

287 строка в файле в моём предыдущем сообщении — это строка 19:

C++ 
1
2
3
4

string message_start = prefToBytes(SU_START_TEST) + cmd.commands[0] +
    'n' + test->Name() +
    'n' + cmd.commands[1] +
    'n' + cmd.commands[2]+'n'; // 287 строка



0

kazak

3364 / 2620 / 322

Регистрация: 11.03.2009

Сообщений: 5,966

21.05.2010, 13:18

7

Цитата
Сообщение от SSxMe
Посмотреть сообщение

287 строка в файле в моём предыдущем сообщении — это строка 19:

C++ 
1
2
3
4

string message_start = prefToBytes(SU_START_TEST) + cmd.commands[0] +
 'n' + test->Name() +
 'n' + cmd.commands[1] +
 'n' + cmd.commands[2]+'n'; // 287 строка

Могу предположить, что одна из функций возвращает значение, которое не может быть обработано string’ом. Попоробуй последовательно исключить слагаемые, и посмотри пропадет ошибка или нет.



1

SSxMe

14 / 14 / 2

Регистрация: 09.05.2010

Сообщений: 79

21.05.2010, 13:42

 [ТС]

8

Я часть кода убрал… и для Questions* выделил память статически:

C++ 
1
2
3
4
5
6
7
8
9
10
11
12
13

                // cmd.commands[0] - ID теста
                // cmd.commands[1] - Количество вопросов под выдачу
                // cmd.commands[2] - Время на выполнение теста
                int test_id = boost::lexical_cast<int>(cmd.commands[0]);
                int questions_count = boost::lexical_cast<int>(cmd.commands[1]);
                set<Question*> questions = Eits.questions.GetListByTest(test_id);
                if(questions_count <= (int)questions.size()){
                    Question* toSort[questions_count];// = new Question*[questions_count];
                    int i=0;
                    for(set<Question*>::iterator it = questions.begin(); it != questions.end(); it++,i++){
                        toSort[i] = (*it);
                    }
                    Test* test = Eits.tests[test_id];

Отладчик:

Bash 
1
2
3
4
5
6
7
8
9
10
11
12
13

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb78a06c0 (LWP 2482)]
0xb7cf69a2 in std::_Rb_tree_increment () from /usr/lib/libstdc++.so.6
(gdb) bt
#0  0xb7cf69a2 in std::_Rb_tree_increment () from /usr/lib/libstdc++.so.6
#1  0xb7cf69fd in std::_Rb_tree_increment () from /usr/lib/libstdc++.so.6
#2  0x080520f4 in std::_Rb_tree_const_iterator<EITSystem::Question*>::operator++ (this=0xbfffc678) at /usr/include/c++/4.3/bits/stl_tree.h:265
#3  0x0804f46a in answer (sock=9, r=
        {static npos = 4294967295, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0xbfffcde8 "4у06b230&bbюмЪ©t"}}) at main.cpp:10
#4  0x0805e74c in Socket::ReadBytes (this=0x806b8c0,
    answer=0x804b40f <answer(int, std::string)>)
    at include/trsys/nb_socket.cpp:152
#5  0x0804ab45 in main () at main.cpp:371

В 10 строке что-то..



0

3364 / 2620 / 322

Регистрация: 11.03.2009

Сообщений: 5,966

21.05.2010, 14:00

9

1)Что показал эксперимент с message_start?
2)Segmentation fault часто появляется при выходе за пределы массива. А при такой конструкции

Цитата
Сообщение от SSxMe
Посмотреть сообщение

if(questions_count <= (int)questions.size()){
Question* toSort[questions_count];// = new Question*[questions_count];
int i=0;
for(set<Question*>::iterator it = questions.begin(); it != questions.end(); it++,i++){
toSort[i] = (*it);
}

это вполне ожидаемо.



1

SSxMe

14 / 14 / 2

Регистрация: 09.05.2010

Сообщений: 79

21.05.2010, 14:22

 [ТС]

10

1)Что показал эксперимент с message_start?

с этим всё нормально

2)Segmentation fault часто появляется при выходе за пределы массива. А при такой конструкции

Это я оказался дураком)))
Просто questions_count Может быть меньше, чем questions.size(), поэтому массив toSort надо заполнять до элемента(questions_count-1).. то есть в цикл мне надо было вставить проверку:

C++ 
1
2
3
4
5
6

int i=0;
for(set<Question*>::iterator it = questions.begin(); it != questions.end();it++,i++){
    if(i<=questions_count){
        toSort[i] = (*it);
    }
}

Но лучше я наверно вместо set буду использовать vector, чтобы не проводить лишних проверок и циклов, тогда будет так:

C++ 
1
2
3

for(int i=0; i < questions_count;i++){
     toSort[i] = questions[i];
}

Извините, что потратил ваше время на свою глупость)



0
Источник

If you are trying to allocate space for an array of pointers, such as

char** my_array_of_strings;  // or some array of pointers such as int** or even void**

then you will need to consider word size (8 bytes in a 64-bit system, 4 bytes in a 32-bit system) when allocating space for n pointers. The size of a pointer is the same of your word size.

So while you may wish to allocate space for n pointers, you are actually going to need n times 8 or 4 (for 64-bit or 32-bit systems, respectively)

To avoid overflowing your allocated memory for n elements of 8 bytes:

my_array_of_strings = (char**) malloc( n * 8 );  // for 64-bit systems
my_array_of_strings = (char**) malloc( n * 4 );  // for 32-bit systems

This will return a block of n pointers, each consisting of 8 bytes (or 4 bytes if you’re using a 32-bit system)

I have noticed that Linux will allow you to use all n pointers when you haven’t compensated for word size, but when you try to free that memory it realizes its mistake and it gives out that rather nasty error. And it is a bad one, when you overflow allocated memory, many security issues lie in wait.

SSxMe

14 / 14 / 2

Регистрация: 09.05.2010

Сообщений: 79

1

21.05.2010, 11:32. Показов 6481. Ответов 9

Метки нет (Все метки)

Не могу понять в чем ошибка..
Debian lenny

Bash 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84

*** glibc detected *** /home/user/eits/trunk/eits: free(): invalid next size (fast): 0x0806c118 *** ======= Backtrace: ========= /lib/i686/cmov/libc.so.6[0xb7b5f624] /lib/i686/cmov/libc.so.6(cfree+0x96)[0xb7b61826] /usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0xb7d372e1] /home/user/eits/trunk/eits[0x804ffe9] /home/user/eits/trunk/eits[0x805f210] /home/user/eits/trunk/eits[0x804aba5] /lib/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb7b07455] /home/user/eits/trunk/eits(_ZNSt8ios_base4InitD1Ev+0x4d)[0x804a641] ======= Memory map: ======== 08048000-0806b000 r-xp 00000000 08:06 1663706    /home/user/eits/trunk/eits 0806b000-0806c000 rw-p 00023000 08:06 1663706    /home/user/eits/trunk/eits 0806c000-080eb000 rw-p 0806c000 00:00 0          [heap] b7700000-b7721000 rw-p b7700000 00:00 0 b7721000-b7800000 ---p b7721000 00:00 0 b787a000-b7884000 r-xp 00000000 08:01 250017     /lib/i686/cmov/libnss_files-2.7.so b7884000-b7886000 rw-p 00009000 08:01 250017     /lib/i686/cmov/libnss_files-2.7.so b7886000-b7888000 rw-p b7886000 00:00 0 b7888000-b789d000 r-xp 00000000 08:01 250003     /lib/i686/cmov/libnsl-2.7.so b789d000-b789f000 rw-p 00014000 08:01 250003     /lib/i686/cmov/libnsl-2.7.so b789f000-b78a1000 rw-p b789f000 00:00 0 b78a1000-b78aa000 r-xp 00000000 08:01 249994     /lib/i686/cmov/libcrypt-2.7.so b78aa000-b78ac000 rw-p 00008000 08:01 249994     /lib/i686/cmov/libcrypt-2.7.so b78ac000-b78d3000 rw-p b78ac000 00:00 0 b78d3000-b78e8000 r-xp 00000000 08:01 250000     /lib/i686/cmov/libpthread-2.7.so b78e8000-b78ea000 rw-p 00014000 08:01 250000     /lib/i686/cmov/libpthread-2.7.so b78ea000-b78ec000 rw-p b78ea000 00:00 0 b78ec000-b7a92000 r-xp 00000000 08:01 418178     /usr/lib/libmysqlclient_r.so.15.0.0 b7a92000-b7ad6000 rw-p 001a5000 08:01 418178     /usr/lib/libmysqlclient_r.so.15.0.0 b7ad6000-b7ad8000 rw-p b7ad6000 00:00 0 b7ad8000-b7aec000 r-xp 00000000 08:01 413532     /usr/lib/libz.so.1.2.3.3 b7aec000-b7aed000 rw-p 00013000 08:01 413532     /usr/lib/libz.so.1.2.3.3 b7aed000-b7aef000 r-xp 00000000 08:01 250005     /lib/i686/cmov/libdl-2.7.so b7aef000-b7af1000 rw-p 00001000 08:01 250005     /lib/i686/cmov/libdl-2.7.so b7af1000-b7c46000 r-xp 00000000 08:01 250009     /lib/i686/cmov/libc-2.7.so b7c46000-b7c47000 r--p 00155000 08:01 250009     /lib/i686/cmov/libc-2.7.so b7c47000-b7c49000 rw-p 00156000 08:01 250009     /lib/i686/cmov/libc-2.7.so b7c49000-b7c4c000 rw-p b7c49000 00:00 0 b7c4c000-b7c58000 r-xp 00000000 08:01 241923     /lib/libgcc_s.so.1 b7c58000-b7c59000 rw-p 0000b000 08:01 241923     /lib/libgcc_s.so.1 b7c59000-b7c7d000 r-xp 00000000 08:01 249989     /lib/i686/cmov/libm-2.7.so b7c7d000-b7c7f000 rw-p 00023000 08:01 249989     /lib/i686/cmov/libm-2.7.so b7c7f000-b7d62000 r-xp 00000000 08:01 411594     /usr/lib/libstdc++.so.6.0.10 b7d62000-b7d65000 r--p 000e2000 08:01 411594     /usr/lib/libstdc++.so.6.0.10 b7d65000-b7d67000 rw-p 000e5000 08:01 411594     /usr/lib/libstdc++.so.6.0.10 b7d67000-b7d6e000 rw-p b7d67000 00:00 0 b7d6e000-b7e4f000 r-xp 00000000 08:01 2108       /usr/local/lib/libmysqlcppconn.so.4.1.1.0 b7e4f000-b7e59000 rw-p 000e0000 08:01 2108       /usr/local/lib/libmysqlcppconn.so.4.1.1.0 b7e59000-b7f93000 r-xp 00000000 08:01 11682      /usr/lib/i686/cmov/libcrypto.so.0.9.8 b7f93000-b7fa9000 rw-p 0013a000 08:01 11682      /usr/lib/i686/cmov/libcrypto.so.0.9.8 b7fa9000-b7fac000 rw-p b7fa9000 00:00 0 b7fb7000-b7fba000 rw-p b7fb7000 00:00 0 b7fba000-b7fbb000 r-xp b7fba000 00:00 0          [vdso] b7fbb000-b7fd5000 r-xp 00000000 08:01 242252     /lib/ld-2.7.so b7fd5000-b7fd7000 rw-p 0001a000 08:01 242252     /lib/ld-2.7.so bffea000-bffff000 rw-p bffeb000 00:00 0          [stack]   Program received signal SIGABRT, Aborted. [Switching to Thread 0xb78866c0 (LWP 2801)] 0xb7fba424 in __kernel_vsyscall () (gdb) bt #0  0xb7fba424 in __kernel_vsyscall () #1  0xb7b1c640 in raise () from /lib/i686/cmov/libc.so.6 #2  0xb7b1e018 in abort () from /lib/i686/cmov/libc.so.6 #3  0xb7b5934d in ?? () from /lib/i686/cmov/libc.so.6 #4  0x0000000a in ?? () #5  0xbfffbdf4 in ?? () #6  0x00000400 in ?? () #7  0xb7c2f648 in ?? () from /lib/i686/cmov/libc.so.6 #8  0x00000017 in ?? () #9  0xbfffee79 in ?? () #10 0x0000001a in ?? () #11 0xb7c2f661 in ?? () from /lib/i686/cmov/libc.so.6 #12 0x00000002 in ?? () #13 0xb7c2f694 in ?? () from /lib/i686/cmov/libc.so.6 #14 0x00000020 in ?? () #15 0xb7c2f665 in ?? () from /lib/i686/cmov/libc.so.6 #16 0x00000004 in ?? () #17 0xbfffc323 in ?? () #18 0x00000008 in ?? () #19 0xb7c2f66b in ?? () from /lib/i686/cmov/libc.so.6 #20 0x00000005 in ?? () #21 0x00000000 in ?? ()

__________________
Помощь в написании контрольных, курсовых и дипломных работ, диссертаций здесь

0

Почетный модератор

7388 / 2634 / 281

Регистрация: 29.07.2006

Сообщений: 13,696

21.05.2010, 12:02

2

SSxMe, да, сообщения об ошибке говорят о многом Лучше бы код показал, если это твоя софтина.

Цитата
Сообщение от SSxMe
Посмотреть сообщение

Не могу понять в чем ошибка.

Ошибка в освобождении памяти. Может, пойнтер неправильный, а может, куча закорраптилась.

1

3096 / 2415 / 257

Регистрация: 11.03.2009

Сообщений: 5,455

21.05.2010, 12:04

3

Еще бы исходник выложил, было бы совсем замечательно.

1

SSxMe

14 / 14 / 2

Регистрация: 09.05.2010

Сообщений: 79

21.05.2010, 12:26

 [ТС]

4

Я бы выложил, но не знаю в каком месте ориентироваться, так как проект уже разросся..
И отладчик не указывает в каком файле надо смотреть..
Может быть можно как то это узнать?

Добавлено через 7 минут
Ошибка происходит предположительно вот тут

C++ 
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 
            if(cmd.commands.size() == 3){                 // cmd.commands[0] - ID теста                 // cmd.commands[1] - Количество вопросов под выдачу                 // cmd.commands[2] - Время на выполнение теста                 int test_id = boost::lexical_cast<int>(cmd.commands[0]);                 int questions_count = boost::lexical_cast<int>(cmd.commands[1]);                 set<Question*> questions = Eits.questions.GetListByTest(test_id);                 if(questions_count <= (int)questions.size()){                     Question** toSort = new Question*[questions_count];                     int i=0;                     for(set<Question*>::iterator it = questions.begin(); it != questions.end(); it++,i++){                         toSort[i] = (*it);                     }                     Test* test = Eits.tests[test_id];                     Users* users = &Eits.users;                     string message_start = prefToBytes(SU_START_TEST) + cmd.commands[0] +                             'n' + test->Name() +                             'n' + cmd.commands[1] +                             'n' + cmd.commands[2]+'n';                     for(Users::iterator it = users->begin(); it != users->end(); it++){                         if(!((*it).second)->isAdmin()){                             for(i=0;i<questions_count;i++){                                     int random_index = rand()%questions_count;                                     Question* question = toSort[random_index];                                     toSort[random_index] = toSort[i];                                     toSort[i] = question;                             }                             string message = "";                             for(i=0;i<questions_count;i++){                                     vector<string> answers = toSort[i]->Answers();                                 message += 'n' + boost::lexical_cast<string>(toSort[i]->Id()) +                                     'n' + toSort[i]->Name() +                                     'n' + boost::lexical_cast<string>(answers.size());                                 for(vector<string>::iterator it_a = answers.begin(); it_a != answers.end(); it_a++){                                     message += 'n' + (*it_a);                                 }                             }                             message.erase(0,1);                             SocketServer.SendBytes((*it).first,message_start+message);                         }                     }                     delete toSort;                 }             }

Может быть я вот это неправильно делаю?

C++ 
1 
Question** toSort = new Question*[questions_count];

0

kazak

3096 / 2415 / 257

Регистрация: 11.03.2009

Сообщений: 5,455

21.05.2010, 12:30

5

Если

C++ 
1 
Question** toSort = new Question*[questions_count];

то вроде как должен быть

C++ 
1 
delete [] toSort;

а не как у тебя в строке 42

C++ 
1 
delete toSort;

1

SSxMe

14 / 14 / 2

Регистрация: 09.05.2010

Сообщений: 79

21.05.2010, 12:44

 [ТС]

6

Не помогло..
Но теперь отладчик указывает файлы:

Bash 
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 
*** glibc detected *** /home/user/eits/repos/trunk/eits: malloc(): memory corruption: 0x08088030 *** ======= Backtrace: ========= /lib/i686/cmov/libc.so.6[0xb7a9b256] /lib/i686/cmov/libc.so.6(__libc_malloc+0x95)[0xb7a9c655] /usr/lib/libstdc++.so.6(_Znwj+0x27)[0xb7c71fd7] /usr/lib/libstdc++.so.6(_ZNSs4_Rep9_S_createEjjRKSaIcE+0x64)[0xb7c4cc04] /usr/lib/libstdc++.so.6(_ZNSs4_Rep8_M_cloneERKSaIcEj+0x38)[0xb7c4d678] /usr/lib/libstdc++.so.6(_ZNSs7reserveEj+0x50)[0xb7c4e6e0] /usr/lib/libstdc++.so.6(_ZNSs6appendERKSs+0x53)[0xb7c4eb93] /home/user/eits/repos/trunk/eits(_ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_ERKS6_S8_+0x2c)[0x8052b12] /home/user/eits/repos/trunk/eits[0x804f50d] /home/user/eits/repos/trunk/eits[0x805f298] /home/user/eits/repos/trunk/eits[0x804abd5] /lib/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb7a40455] /home/user/eits/repos/trunk/eits(_ZNSt8ios_base4InitD1Ev+0x49)[0x804a671] ======= Memory map: ======== 08048000-0806b000 r-xp 00000000 03:01 153996     /home/user/eits/repos/trunk/eits 0806b000-0806c000 rw-p 00023000 03:01 153996     /home/user/eits/repos/trunk/eits 0806c000-0813f000 rw-p 0806c000 00:00 0          [heap] b7600000-b7621000 rw-p b7600000 00:00 0 b7621000-b7700000 ---p b7621000 00:00 0 b77b3000-b77bd000 r-xp 00000000 03:01 47505      /lib/i686/cmov/libnss_files-2.7.so b77bd000-b77bf000 rw-p 00009000 03:01 47505      /lib/i686/cmov/libnss_files-2.7.so b77bf000-b77c1000 rw-p b77bf000 00:00 0 b77c1000-b77d6000 r-xp 00000000 03:01 47495      /lib/i686/cmov/libnsl-2.7.so b77d6000-b77d8000 rw-p 00014000 03:01 47495      /lib/i686/cmov/libnsl-2.7.so b77d8000-b77da000 rw-p b77d8000 00:00 0 b77da000-b77e3000 r-xp 00000000 03:01 47489      /lib/i686/cmov/libcrypt-2.7.so b77e3000-b77e5000 rw-p 00008000 03:01 47489      /lib/i686/cmov/libcrypt-2.7.so b77e5000-b780c000 rw-p b77e5000 00:00 0 b780c000-b7821000 r-xp 00000000 03:01 47493      /lib/i686/cmov/libpthread-2.7.so b7821000-b7823000 rw-p 00014000 03:01 47493      /lib/i686/cmov/libpthread-2.7.so b7823000-b7825000 rw-p b7823000 00:00 0 b7825000-b79cb000 r-xp 00000000 03:01 60606      /usr/lib/libmysqlclient_r.so.15.0.0 b79cb000-b7a0f000 rw-p 001a5000 03:01 60606      /usr/lib/libmysqlclient_r.so.15.0.0 b7a0f000-b7a11000 rw-p b7a0f000 00:00 0 b7a11000-b7a25000 r-xp 00000000 03:01 57372      /usr/lib/libz.so.1.2.3.3 b7a25000-b7a26000 rw-p 00013000 03:01 57372      /usr/lib/libz.so.1.2.3.3 b7a26000-b7a28000 r-xp 00000000 03:01 47497      /lib/i686/cmov/libdl-2.7.so b7a28000-b7a2a000 rw-p 00001000 03:01 47497      /lib/i686/cmov/libdl-2.7.so b7a2a000-b7b7f000 r-xp 00000000 03:01 47500      /lib/i686/cmov/libc-2.7.so b7b7f000-b7b80000 r--p 00155000 03:01 47500      /lib/i686/cmov/libc-2.7.so b7b80000-b7b82000 rw-p 00156000 03:01 47500      /lib/i686/cmov/libc-2.7.so b7b82000-b7b85000 rw-p b7b82000 00:00 0 b7b85000-b7b91000 r-xp 00000000 03:01 39363      /lib/libgcc_s.so.1 b7b91000-b7b92000 rw-p 0000b000 03:01 39363      /lib/libgcc_s.so.1 b7b92000-b7bb6000 r-xp 00000000 03:01 47485      /lib/i686/cmov/libm-2.7.so b7bb6000-b7bb8000 rw-p 00023000 03:01 47485      /lib/i686/cmov/libm-2.7.so b7bb8000-b7c9b000 r-xp 00000000 03:01 55434      /usr/lib/libstdc++.so.6.0.10 b7c9b000-b7c9e000 r--p 000e2000 03:01 55434      /usr/lib/libstdc++.so.6.0.10 b7c9e000-b7ca0000 rw-p 000e5000 03:01 55434      /usr/lib/libstdc++.so.6.0.10 b7ca0000-b7ca7000 rw-p b7ca0000 00:00 0 b7ca7000-b7d88000 r-xp 00000000 03:01 104385     /usr/local/lib/libmysqlcppconn.so.4.1.1.0 b7d88000-b7d92000 rw-p 000e0000 03:01 104385     /usr/local/lib/libmysqlcppconn.so.4.1.1.0 b7d92000-b7ecc000 r-xp 00000000 03:01 75152      /usr/lib/i686/cmov/libcrypto.so.0.9.8 b7ecc000-b7ee2000 rw-p 0013a000 03:01 75152      /usr/lib/i686/cmov/libcrypto.so.0.9.8 b7ee2000-b7ee5000 rw-p b7ee2000 00:00 0 b7ef0000-b7ef3000 rw-p b7ef0000 00:00 0 b7ef3000-b7ef4000 r-xp b7ef3000 00:00 0          [vdso] b7ef4000-b7f0e000 r-xp 00000000 03:01 39692      /lib/ld-2.7.so b7f0e000-b7f10000 rw-p 0001a000 03:01 39692      /lib/ld-2.7.so bffeb000-c0000000 rw-p bffeb000 00:00 0          [stack]   Program received signal SIGABRT, Aborted. [Switching to Thread 0xb77bf6c0 (LWP 2364)] 0xb7ef3424 in __kernel_vsyscall () (gdb) bt #0  0xb7ef3424 in __kernel_vsyscall () #1  0xb7a55640 in raise () from /lib/i686/cmov/libc.so.6 #2  0xb7a57018 in abort () from /lib/i686/cmov/libc.so.6 #3  0xb7a9234d in ?? () from /lib/i686/cmov/libc.so.6 #4  0x00000009 in ?? () #5  0xbfffdc30 in ?? () #6  0x00000400 in ?? () #7  0x000001e8 in ?? () #8  0xb7b68648 in ?? () from /lib/i686/cmov/libc.so.6 #9  0x00000017 in ?? () #10 0xbffffe65 in ?? () #11 0x00000020 in ?? () #12 0xb7b68661 in ?? () from /lib/i686/cmov/libc.so.6 #13 0x00000002 in ?? () #14 0xb7b655d1 in ?? () from /lib/i686/cmov/libc.so.6 #15 0x0000001b in ?? () #16 0xb7b68665 in ?? () from /lib/i686/cmov/libc.so.6 #17 0x00000004 in ?? () #18 0xbfffe1df in ?? () #19 0x00000008 in ?? () #20 0xb7b6866b in ?? () from /lib/i686/cmov/libc.so.6 #21 0x00000005 in ?? () #22 0x000094f4 in ?? () ---Type <return> to continue, or q <return> to quit--- #23 0xb7b86595 in ?? () from /lib/libgcc_s.so.1 #24 0x0806b6de in sha256(char const*)::oBuffer () #25 0x00000005 in ?? () #26 0xbfffe248 in ?? () #27 0xb7b6866b in ?? () from /lib/i686/cmov/libc.so.6 #28 0xb7b6866b in ?? () from /lib/i686/cmov/libc.so.6 #29 0x00000005 in ?? () #30 0xbfffdb60 in ?? () #31 0x00000003 in ?? () #32 0xbfffe1df in ?? () #33 0x00000008 in ?? () #34 0xbfffdb80 in ?? () #35 0xb7a92250 in ?? () from /lib/i686/cmov/libc.so.6 #36 0xbfffe1df in ?? () #37 0xb7a69cb7 in vfprintf () from /lib/i686/cmov/libc.so.6 #38 0xb7a9b256 in ?? () from /lib/i686/cmov/libc.so.6 #39 0x00000002 in ?? () #40 0xb7b68648 in ?? () from /lib/i686/cmov/libc.so.6 #41 0xbffffe65 in ?? () #42 0xb7b655d1 in ?? () from /lib/i686/cmov/libc.so.6 #43 0xbfffe1df in ?? () #44 0xb7b814e0 in ?? () from /lib/i686/cmov/libc.so.6 #45 0xb7a946b4 in _IO_file_sync () from /lib/i686/cmov/libc.so.6 ---Type <return> to continue, or q <return> to quit--- #46 0xb7a9c655 in malloc () from /lib/i686/cmov/libc.so.6 #47 0xb7c71fd7 in operator new () from /usr/lib/libstdc++.so.6 #48 0xb7c4cc04 in std::string::_Rep::_S_create () from /usr/lib/libstdc++.so.6 #49 0xb7c4d678 in std::string::_Rep::_M_clone () from /usr/lib/libstdc++.so.6 #50 0xb7c4e6e0 in std::string::reserve () from /usr/lib/libstdc++.so.6 #51 0xb7c4eb93 in std::string::append () from /usr/lib/libstdc++.so.6 #52 0x08052b12 in std::operator+<char, std::char_traits<char>, std::allocator<char> > (__lhs=@0xbfffe6f8, __rhs=@0xbfffe6f4)     at /usr/include/c++/4.3/bits/basic_string.h:2087 #53 0x0804f50d in answer (sock=7, r=         {static npos = 4294967295, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0xbfffec08 "4у06b230&bbЮКЪ©a"}}) at main.cpp:287 #54 0x0805f298 in Socket::ReadBytes (this=0x806b5e0,     answer=0x804b49f <answer(int, std::string)>)     at include/trsys/nb_socket.cpp:152 #55 0x0804abd5 in main () at main.cpp:367
Bash 
1 
*** glibc detected *** /home/user/eits/repos/trunk/eits: malloc(): memory corruption: 0x08088030 ***
Bash 
1 2 
#53 0x0804f50d in answer (sock=7, r=         {static npos = 4294967295, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0xbfffec08 "4у06b230&bbЮКЪ©a"}}) at main.cpp:287

287 строка в файле в моём предыдущем сообщении — это строка 19:

C++ 
1 2 3 4 
string message_start = prefToBytes(SU_START_TEST) + cmd.commands[0] +     'n' + test->Name() +     'n' + cmd.commands[1] +     'n' + cmd.commands[2]+'n'; // 287 строка

0

kazak

3096 / 2415 / 257

Регистрация: 11.03.2009

Сообщений: 5,455

21.05.2010, 13:18

7

Цитата
Сообщение от SSxMe
Посмотреть сообщение

287 строка в файле в моём предыдущем сообщении — это строка 19:

C++ 
1 2 3 4 
string message_start = prefToBytes(SU_START_TEST) + cmd.commands[0] +  'n' + test->Name() +  'n' + cmd.commands[1] +  'n' + cmd.commands[2]+'n'; // 287 строка

Могу предположить, что одна из функций возвращает значение, которое не может быть обработано string’ом. Попоробуй последовательно исключить слагаемые, и посмотри пропадет ошибка или нет.

1

SSxMe

14 / 14 / 2

Регистрация: 09.05.2010

Сообщений: 79

21.05.2010, 13:42

 [ТС]

8

Я часть кода убрал… и для Questions* выделил память статически:

C++ 
1 2 3 4 5 6 7 8 9 10 11 12 13 
                // cmd.commands[0] - ID теста                 // cmd.commands[1] - Количество вопросов под выдачу                 // cmd.commands[2] - Время на выполнение теста                 int test_id = boost::lexical_cast<int>(cmd.commands[0]);                 int questions_count = boost::lexical_cast<int>(cmd.commands[1]);                 set<Question*> questions = Eits.questions.GetListByTest(test_id);                 if(questions_count <= (int)questions.size()){                     Question* toSort[questions_count];// = new Question*[questions_count];                     int i=0;                     for(set<Question*>::iterator it = questions.begin(); it != questions.end(); it++,i++){                         toSort[i] = (*it);                     }                     Test* test = Eits.tests[test_id];

Отладчик:

Bash 
1 2 3 4 5 6 7 8 9 10 11 12 13 
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb78a06c0 (LWP 2482)] 0xb7cf69a2 in std::_Rb_tree_increment () from /usr/lib/libstdc++.so.6 (gdb) bt #0  0xb7cf69a2 in std::_Rb_tree_increment () from /usr/lib/libstdc++.so.6 #1  0xb7cf69fd in std::_Rb_tree_increment () from /usr/lib/libstdc++.so.6 #2  0x080520f4 in std::_Rb_tree_const_iterator<EITSystem::Question*>::operator++ (this=0xbfffc678) at /usr/include/c++/4.3/bits/stl_tree.h:265 #3  0x0804f46a in answer (sock=9, r=         {static npos = 4294967295, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0xbfffcde8 "4у06b230&bbюмЪ©t"}}) at main.cpp:10 #4  0x0805e74c in Socket::ReadBytes (this=0x806b8c0,     answer=0x804b40f <answer(int, std::string)>)     at include/trsys/nb_socket.cpp:152 #5  0x0804ab45 in main () at main.cpp:371

В 10 строке что-то..

0

3096 / 2415 / 257

Регистрация: 11.03.2009

Сообщений: 5,455

21.05.2010, 14:00

9

1)Что показал эксперимент с message_start?
2)Segmentation fault часто появляется при выходе за пределы массива. А при такой конструкции

Цитата
Сообщение от SSxMe
Посмотреть сообщение

if(questions_count <= (int)questions.size()){
Question* toSort[questions_count];// = new Question*[questions_count];
int i=0;
for(set<Question*>::iterator it = questions.begin(); it != questions.end(); it++,i++){
toSort[i] = (*it);
}

это вполне ожидаемо.

1

SSxMe

14 / 14 / 2

Регистрация: 09.05.2010

Сообщений: 79

21.05.2010, 14:22

 [ТС]

10

1)Что показал эксперимент с message_start?

с этим всё нормально

2)Segmentation fault часто появляется при выходе за пределы массива. А при такой конструкции

Это я оказался дураком)))
Просто questions_count Может быть меньше, чем questions.size(), поэтому массив toSort надо заполнять до элемента(questions_count-1).. то есть в цикл мне надо было вставить проверку:

C++ 
1 2 3 4 5 6 
int i=0; for(set<Question*>::iterator it = questions.begin(); it != questions.end();it++,i++){     if(i<=questions_count){         toSort[i] = (*it);     } }

Но лучше я наверно вместо set буду использовать vector, чтобы не проводить лишних проверок и циклов, тогда будет так:

C++ 
1 2 3 
for(int i=0; i < questions_count;i++){      toSort[i] = questions[i]; }

Извините, что потратил ваше время на свою глупость)

0
Автор Тема: free(): invalid next size (fast)  (Прочитано 5564 раз)
vulko

Гость

Ребята, столкнулся с таким вот крэшем.
То ли double free, то ли free/new, то ли delete/malloc…

Но все это происходит насколько я понимаю после ресайза виджета. Собсно ресайзы програмные происходят, причем могут очень часто.
Хотя возможно и не в этом причина…

Что это, баг Qt? Куда копать? Дебажить внутри Qt?
Я верно понимаю мне нужно будет пересобрать Qt в дебажную версию?
Умеет ли QtCreator дебажить внутри .so?

Qt предустановлен в пакетах уже, можно ли без пересборки? Может подтянуть пакет откуда? Или побилдить дебажные либы и подменить ими обычные?

Qt 4.8.5
Linux (X Windows) дебианоподобное.

0   __GI_raise   raise.c   64   0x7ffff519dbf5   
1   __GI_abort   abort.c   92   0x7ffff51a0d98   
2   __libc_message   libc_fatal.c   189   0x7ffff51d7d15   
3   malloc_printerr   malloc.c   6283   0x7ffff51e1dc6   
4   __GI___libc_free   malloc.c   3738   0x7ffff51e5d7c   
5   QBoxLayout::setGeometry(QRect const&)   /usr/lib/x86_64-linux-gnu/libQtGui.so.4   0   0x7ffff6b174fb   
6   QLayoutPrivate::doResize(QSize const&)   /usr/lib/x86_64-linux-gnu/libQtGui.so.4   0   0x7ffff6b31c73   
7   QLayout::activate()   /usr/lib/x86_64-linux-gnu/libQtGui.so.4   0   0x7ffff6b331bd   
8   QApplicationPrivate::notify_helper(QObject*, QEvent*)   /usr/lib/x86_64-linux-gnu/libQtGui.so.4   0   0x7ffff6b0916e   
9   QApplication::notify(QObject*, QEvent*)   /usr/lib/x86_64-linux-gnu/libQtGui.so.4   0   0x7ffff6b0d62a   
10   QCoreApplication::notifyInternal(QObject*, QEvent*)   /usr/lib/x86_64-linux-gnu/libQtCore.so.4   0   0x7ffff62906be   
11   QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*)   /usr/lib/x86_64-linux-gnu/libQtCore.so.4   0   0x7ffff62947a1   
12   ??   /usr/lib/x86_64-linux-gnu/libQtCore.so.4   0   0x7ffff62bee03   
13   g_main_context_dispatch   /lib/x86_64-linux-gnu/libglib-2.0.so.0   0   0x7ffff3a49355   
14   ??   /lib/x86_64-linux-gnu/libglib-2.0.so.0   0   0x7ffff3a49688   
15   g_main_context_iteration   /lib/x86_64-linux-gnu/libglib-2.0.so.0   0   0x7ffff3a49744   
16   QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)   /usr/lib/x86_64-linux-gnu/libQtCore.so.4   0   0x7ffff62bef96   
17   ??   /usr/lib/x86_64-linux-gnu/libQtGui.so.4   0   0x7ffff6baf0de   
18   QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)   /usr/lib/x86_64-linux-gnu/libQtCore.so.4   0   0x7ffff628f40f   
19   QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>)   /usr/lib/x86_64-linux-gnu/libQtCore.so.4   0   0x7ffff628f698   
20   QCoreApplication::exec()   /usr/lib/x86_64-linux-gnu/libQtCore.so.4   0   0x7ffff6294ab8   
21   main   main.cpp   23   0x417ecd   

Записан
Alex Custov

В 99.9% случаев это твоя ошибка при работе с указателями — двойное удаление, разыменование нулевого указателя и т.п. Ищи ошибку у себя в коде. Можно с помощью valgrind, но лучше руками.

Debug символы можно получить установив пакет qtbase5-dbg
« Последнее редактирование: Ноябрь 12, 2014, 15:08 от Alex Custov »
Записан
vulko

Гость

В 99.9% случаев это твоя ошибка при работе с указателями — двойное удаление, разыменование нулевого указателя и т.п. Ищи ошибку у себя в коде. Можно с помощью valgrind, но лучше руками.

Debug символы можно получить установив пакет qtbase5-dbg

Ты стэк смотрел? Там ниодного моего вызова нет)
Хотя не отрицаю, что мой код мог спровоцировать подобное поведение…
Либо creator как обычно криво дебажит… но уж стэк то не должен был перепутать.

valgrind я бы и рад, но с ним нереально будет воспроизвести ошибку вообще никак. я вижу дикое слайдшоу под валгриндом.
впрочем можно попробовать перерисовку делать не раз в 10мс а раз в 1секунду… надо попробовать. но это уже не то.
да и он мне очень много ошибок выдает, но 99% внутри qt, llvm и другой шляпы…

пакет попробую канеш, но у меня гемор с дебиановским и убунтовским репозиториями. т.к. линух «кастомный».
отдельно можно его где нибудь скачать и поставить ручками?

Записан
Alex Custov

Ты стэк смотрел? Там ниодного моего вызова нет)

Это ни о чём не говорит. В случае когда бьётся память (двойное удаление указателя), падение может произойти уже после него в совершенно нормальном месте.

пакет попробую канеш, но у меня гемор с дебиановским и убунтовским репозиториями. т.к. линух «кастомный».
отдельно можно его где нибудь скачать и поставить ручками?

Из репозиториев твоего дистрибутива. Ставить откуда-то ещё крайне не рекомендуется.

Записан
vulko

Гость

Ты стэк смотрел? Там ниодного моего вызова нет)

Это ни о чём не говорит. В случае когда бьётся память (двойное удаление указателя), падение может произойти уже после него в совершенно нормальном месте.

пакет попробую канеш, но у меня гемор с дебиановским и убунтовским репозиториями. т.к. линух «кастомный».
отдельно можно его где нибудь скачать и поставить ручками?

Из репозиториев твоего дистрибутива. Ставить откуда-то ещё крайне не рекомендуется.

В принципе да, ниочем не говорит, если бы не одно но…
Приложение у меня логирует свою работу. Соотв. логи позволяют повторять одни и те же действия записанные в файл.
Так вот при воспроизведении этих логов много раз подряд случается крэш.
Т.е. крэш рандомный. А действия эти даже не что-то типа автоматизированного тестирования, а куда более идентичные, в плане работы приложения.

И вот во время воспроизведения лога в эн-ный раз отваливается.
есть у меня модель, где лежать актуальные данные, которые берутся из логов. каждый раз перед новым воспроизведением они очищаются.

если бы это была проблема double free или free памяти выделенной new или delete памяти выделенной malloc’ом, то крэш не был бы рандомным наверное?
впрочем это я проверю все же…

Записан
Alex Custov

если бы это была проблема double free или free памяти выделенной new или delete памяти выделенной malloc’ом, то крэш не был бы рандомным наверное?

Поведение в такой ситуации не определено, и поэтому может быть любым.

Записан
vulko

Гость

Никаких double free, как я и предполагал нет.
Лики были, пофиксил.

Не понимаю причину крэша… Хотя возможно было как-то связано с тем что я хранил ссылки на QObject в модели… Эти же QObject’ы жили в QTableWidget, который очищался при очистке модели… правда они без parent’а были, поэтому при очистке таблицы они не удалялись…

В общем так и не понял я причину…

Записан
Bepec

Гость

Указатели new delete освобождение.
 Вот если б твоё приложение логировало полностью своё поеведение вплоть до занимаемых и очищаемых секторов памяти, тогда б ты мог уверенно сказать про причину Улыбающийся А так раз на раз не приходится Веселый

Записан

@zonkzonk

morn,

buf can be found as base64 encoded attachment.
in: 69921cd

,echo q| r2 -c "k `cat /tmp/buf`" /bin/ls *** Error in `r2': free(): invalid next size (normal): 0x0000000000e26390 *** ======= Backtrace: ========= /usr/lib/libc.so.6(+0x731ff)[0x7f06f7afa1ff] /usr/lib/libc.so.6(+0x789ae)[0x7f06f7aff9ae] /usr/lib/libc.so.6(+0x796b6)[0x7f06f7b006b6] /usr/local/lib/libr_core.so.0.9.8.git(+0x41a8e)[0x7f06fb98fa8e] /usr/local/lib/libr_core.so.0.9.8.git(+0x41a69)[0x7f06fb98fa69] /usr/local/lib/libr_core.so.0.9.8.git(r_core_cmd+0x275)[0x7f06fb991c44] /usr/local/lib/libr_core.so.0.9.8.git(r_core_cmd0+0x28)[0x7f06fb9921dd] r2(main+0x182f)[0x4043b5] /usr/lib/libc.so.6(__libc_start_main+0xf5)[0x7f06f7aa8b05] r2[0x4026d9] ======= Memory map: ======== 00400000-00406000 r-xp 00000000 08:03 10660036 /usr/local/bin/radare2 00606000-00607000 rw-p 00006000 08:03 10660036 /usr/local/bin/radare2 00607000-00668000 rw-p 00000000 00:00 0 00c10000-00e3f000 rw-p 00000000 00:00 0 [heap] 7f06f6942000-7f06f6957000 r-xp 00000000 08:03 17036383 /usr/lib/libgcc_s.so.1 7f06f6957000-7f06f6b57000 ---p 00015000 08:03 17036383 /usr/lib/libgcc_s.so.1 7f06f6b57000-7f06f6b58000 rw-p 00015000 08:03 17036383 /usr/lib/libgcc_s.so.1 ...

also with -d

greetings
z.

buf

@zonkzonk
zonkzonk

changed the title
free(): invalid next size (normal): 0x0000000000e26390 *** ( not -d )

free(): invalid next size (normal): 0x0000000000e26390 ***

Apr 30, 2014

@zonkzonk

Copy link


Contributor

Author

for teh record: this now prints:

*** Error in `r2': malloc(): memory corruption: 0x0000000001382670 ***

valgrind here: http://sprunge.us/VXZE

@radare

looks like a bug in SdbJSON. could you fuzz it? or test it more extensively? (open related bugs in sdb repo)

—pancake

On 06 May 2014, at 11:50, zonkzonk notifications@github.com wrote:

for teh record: this now prints:

*** Error in `r2′: malloc(): memory corruption: 0x0000000001382670 ***
valgrind here: http://sprunge.us/VXZE

—
Reply to this email directly or view it on GitHub.

@zonkzonk

Copy link


Contributor

Author

here is some gdb mess:

[0x0040487f]> k "`cat /tmp/buf`" Breakpoint 1, 0x00007ffff50708b0 in sdb_json_set@plt () from /usr/local/lib/libr_db.so.0.9.8.git (gdb) watch *0x00007ffff50708b0 Hardware watchpoint 2: *0x00007ffff50708b0 (gdb) reverse-continue Target multi-thread does not support this command. (gdb) si 0x00007ffff50708b6 in sdb_json_set@plt () from /usr/local/lib/libr_db.so.0.9.8.git (gdb) c Continuing. *** Error in `/usr/local/bin/r2': free(): invalid next size (normal): 0x00000000007bc900 *** *** Error in `/usr/local/bin/r2': malloc(): memory corruption: 0x00000000007bc9c0 *** ^C Program received signal SIGINT, Interrupt. 0x00007ffff3725f88 in pthread_once () from /usr/lib/libpthread.so.0 (gdb) x/i *0x00007ffff50708b0 0x1ffa25ff: Cannot access memory at address 0x1ffa25ff (gdb) i watch Num Type Disp Enb Address What 2 hw watchpoint keep y *0x00007ffff50708b0 (gdb) x/i *0x00007ffff50708b6 0x2e68: Cannot access memory at address 0x2e68 (gdb) !date Tue May 6 15:28:20 CEST 2014

@zonkzonk

Copy link


Contributor

Author

this is now an endless loop in r2 -v

radare2 0.9.8.git @ linux-little-x86-64 git.0.9.7-996-g34303f2 commit: 34303f266c5700d3fc28aad1ea5c857537f3a147 build: 2014-06-10

valgrind extract:

 ==11026== Invalid read of size 1 ==11026== at 0x4E8CC41: bin_relocs (bin.c:546) ==11026== by 0x4E8F411: r_core_bin_info (bin.c:1180) ==11026== by 0x4E8AD4D: r_core_bin_set_env (bin.c:47) ==11026== by 0x4E7B556: r_core_file_do_load_for_io_plugin (file.c:303) ==11026== by 0x4E7B91E: r_core_bin_load (file.c:429) ==11026== by 0x403D79: main (radare2.c:466) ==11026== Address 0xabf4e30 is 0 bytes inside a block of size 2,584 free'd ==11026== at 0x4C2999C: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==11026== by 0x84E9AB9: r_list_delete (list.c:92) ==11026== by 0x84E999C: r_list_purge (list.c:61) ==11026== by 0x84E99E7: r_list_free (list.c:71) ==11026== by 0x5981432: has_canary (bin_elf.c:429) ==11026== by 0x59815CC: info (bin_elf.c:455) ==11026== by 0x596275A: r_bin_object_set_items (bin.c:328) ==11026== by 0x5963F78: r_bin_object_new (bin.c:807) ==11026== by 0x59644F1: r_bin_file_new_from_bytes (bin.c:910) ==11026== by 0x5963328: r_bin_load_io_at_offset_as_sz (bin.c:521) ==11026== by 0x59633A6: r_bin_load_io_at_offset_as (bin.c:536) ==11026== by 0x5962ED2: r_bin_load_io (bin.c:448) ==11026== ==11026== Invalid read of size 1 ==11026== at 0x8D70AC7: vfprintf (in /usr/lib/libc-2.19.so) ==11026== by 0x8D9B1A8: vsnprintf (in /usr/lib/libc-2.19.so) ==11026== by 0x8D78281: snprintf (in /usr/lib/libc-2.19.so) ==11026== by 0x4E8CC79: bin_relocs (bin.c:547) ==11026== by 0x4E8F411: r_core_bin_info (bin.c:1180) ==11026== by 0x4E8AD4D: r_core_bin_set_env (bin.c:47) ==11026== by 0x4E7B556: r_core_file_do_load_for_io_plugin (file.c:303) ==11026== by 0x4E7B91E: r_core_bin_load (file.c:429) ==11026== by 0x403D79: main (radare2.c:466) ==11026== Address 0xabf4e30 is 0 bytes inside a block of size 2,584 free'd ==11026== at 0x4C2999C: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==11026== by 0x84E9AB9: r_list_delete (list.c:92) ==11026== by 0x84E999C: r_list_purge (list.c:61) ==11026== by 0x84E99E7: r_list_free (list.c:71) ==11026== by 0x5981432: has_canary (bin_elf.c:429) ==11026== by 0x59815CC: info (bin_elf.c:455) ==11026== by 0x596275A: r_bin_object_set_items (bin.c:328) ==11026== by 0x5963F78: r_bin_object_new (bin.c:807) ==11026== by 0x59644F1: r_bin_file_new_from_bytes (bin.c:910) ==11026== by 0x5963328: r_bin_load_io_at_offset_as_sz (bin.c:521) ==11026== by 0x59633A6: r_bin_load_io_at_offset_as (bin.c:536) ==11026== by 0x5962ED2: r_bin_load_io (bin.c:448) ==11026== ==11026== Invalid read of size 1 ==11026== at 0x8D9F118: _IO_default_xsputn (in /usr/lib/libc-2.19.so) ==11026== by 0x8D70B9B: vfprintf (in /usr/lib/libc-2.19.so) ==11026== by 0x8D9B1A8: vsnprintf (in /usr/lib/libc-2.19.so) ==11026== by 0x8D78281: snprintf (in /usr/lib/libc-2.19.so) ==11026== by 0x4E8CC79: bin_relocs (bin.c:547) ==11026== by 0x4E8F411: r_core_bin_info (bin.c:1180) ==11026== by 0x4E8AD4D: r_core_bin_set_env (bin.c:47) ==11026== by 0x4E7B556: r_core_file_do_load_for_io_plugin (file.c:303) ==11026== by 0x4E7B91E: r_core_bin_load (file.c:429) ==11026== by 0x403D79: main (radare2.c:466) ==11026== Address 0xabf4e30 is 0 bytes inside a block of size 2,584 free'd ==11026== at 0x4C2999C: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==11026== by 0x84E9AB9: r_list_delete (list.c:92) ==11026== by 0x84E999C: r_list_purge (list.c:61) ==11026== by 0x84E99E7: r_list_free (list.c:71) ==11026== by 0x5981432: has_canary (bin_elf.c:429) ==11026== by 0x59815CC: info (bin_elf.c:455) ==11026== by 0x596275A: r_bin_object_set_items (bin.c:328) ==11026== by 0x5963F78: r_bin_object_new (bin.c:807) ==11026== by 0x59644F1: r_bin_file_new_from_bytes (bin.c:910) ==11026== by 0x5963328: r_bin_load_io_at_offset_as_sz (bin.c:521) ==11026== by 0x59633A6: r_bin_load_io_at_offset_as (bin.c:536) ==11026== by 0x5962ED2: r_bin_load_io (bin.c:448) ==11026== ==11026== Invalid read of size 1 ==11026== at 0x8D9F127: _IO_default_xsputn (in /usr/lib/libc-2.19.so) ==11026== by 0x8D70B9B: vfprintf (in /usr/lib/libc-2.19.so) ==11026== by 0x8D9B1A8: vsnprintf (in /usr/lib/libc-2.19.so) ==11026== by 0x8D78281: snprintf (in /usr/lib/libc-2.19.so) ==11026== by 0x4E8CC79: bin_relocs (bin.c:547) ==11026== by 0x4E8F411: r_core_bin_info (bin.c:1180) ==11026== by 0x4E8AD4D: r_core_bin_set_env (bin.c:47)

@radare

@jvoisin

@zonkzonk

Copy link


Contributor

Author

still in

$ r2 -v radare2 0.9.8.git @ linux-little-x86-64 git.0.9.7-1006-g63ae19c commit: 63ae19c650b6d8d3780599ba4916f7e8421ee62b build: 2014-06-10 $ uname -sm Linux x86_64

wat are you guys testing on? ;)

@radare

i tested on linux32 and osx64

would be nice to address all those valgrind warns, but i cant reproduce them :P

On 10 Jun 2014, at 23:15, zonkzonk notifications@github.com wrote:

still in

$ r2 -v
radare2 0.9.8.git @ linux-little-x86-64 git.0.9.7-1006-g63ae19c
commit: 63ae19c build: 2014-06-10

$ uname -sm
Linux x86_64
wat are you guys testing on? ;)

—
Reply to this email directly or view it on GitHub.

@radare

try again plz i did some changes. paste default valgrind output (no need for memleak checks)

On 10 Jun 2014, at 23:15, zonkzonk notifications@github.com wrote:

still in

$ r2 -v
radare2 0.9.8.git @ linux-little-x86-64 git.0.9.7-1006-g63ae19c
commit: 63ae19c build: 2014-06-10

$ uname -sm
Linux x86_64
wat are you guys testing on? ;)

—
Reply to this email directly or view it on GitHub.

@zonkzonk

Copy link


Contributor

Author

@zonkzonk

Copy link


Contributor

Author

changed to

#0 0x00007f61ba1c0e92 in sdb_set_internal () from /usr/local/lib/libr_db.so.0.9.8.git (gdb) (gdb) bt #0 0x00007f61ba1c0e92 in sdb_set_internal () from /usr/local/lib/libr_db.so.0.9.8.git #1 0x00007f61ba1c0f4d in sdb_set_owned () from /usr/local/lib/libr_db.so.0.9.8.git #2 0x00007f61ba1baf18 in sdb_json_set () from /usr/local/lib/libr_db.so.0.9.8.git #3 0x00007f61ba1bf6d8 in sdb_querys () from /usr/local/lib/libr_db.so.0.9.8.git #4 0x00007f61bcdf3bc9 in cmd_kuery (data=0x606940 <r>, input=0x20e04b1 " 01Y") at cmd.c:396 #5 0x00007f61bce11bcd in r_cmd_call (cmd=0x1d97d10, input=0x20e04b0 "k 01Y") at cmd_api.c:179 #6 0x00007f61bcdf653f in r_core_cmd_subst_i (core=0x606940 <r>, cmd=0x20e04b0 "k 01Y") at cmd.c:1216 #7 0x00007f61bcdf4d09 in r_core_cmd_subst (core=0x606940 <r>, cmd=0x20e04b0 "k 01Y") at cmd.c:776 #8 0x00007f61bcdf6f81 in r_core_cmd (core=0x606940 <r>, cstr=0x7fffa832366f "k 01Y:216225256m371215a'Z213315vK20727420263b224є22177217217207r360z257237260v201s2043356516237367D234lp267taTݵd20126235361}F330%x342y3a360y33237004273357362U(T6=,35266267333v312r30302vFد232^23466u236263204e374344207320äR334MW222247322z330307SfL/241#35362342/376y:4zvx20621347267y177244tAp275 01300:235qA302332E22326m2Z{35603p32730211Ն177352212p354NO361361320O06/^251362235226[M)251203242/"..., log=0) at cmd.c:1405 #9 0x00007f61bcdf7527 in r_core_cmd0 (user=0x606940 <r>, cmd=0x7fffa832366f "k 01Y:216225256m371215a'Z213315vK20727420263b224є22177217217207r360z257237260v201s2043356516237367D234lp267taTݵd20126235361}F330%x342y3a360y33237004273357362U(T6=,35266267333v312r30302vFد232^23466u236263204e374344207320äR334MW222247322z330307SfL/241#35362342/376y:4zvx20621347267y177244tAp275 01300:235qA302332E22326m2Z{35603p32730211Ն177352212p354NO361361320O06/^251362235226[M)251203242/"...) at cmd.c:1528 #10 0x0000000000404421 in main (argc=4, argv=0x7fffa8321988, envp=0x7fffa83219b0) at radare2.c:564 (gdb)

@radare

Details on how to reproduce?

On 05 Aug 2014, at 22:24, zonkzonk notifications@github.com wrote:

changed to

#0 0x00007f61ba1c0e92 in sdb_set_internal () from /usr/local/lib/libr_db.so.0.9.8.git
(gdb)
(gdb) bt
#0 0x00007f61ba1c0e92 in sdb_set_internal () from /usr/local/lib/libr_db.so.0.9.8.git
#1 0x00007f61ba1c0f4d in sdb_set_owned () from /usr/local/lib/libr_db.so.0.9.8.git
#2 0x00007f61ba1baf18 in sdb_json_set () from /usr/local/lib/libr_db.so.0.9.8.git
#3 0x00007f61ba1bf6d8 in sdb_querys () from /usr/local/lib/libr_db.so.0.9.8.git
#4 0x00007f61bcdf3bc9 in cmd_kuery (data=0x606940 , input=0x20e04b1 » 01Y») at cmd.c:396
#5 0x00007f61bce11bcd in r_cmd_call (cmd=0x1d97d10, input=0x20e04b0 «k 01Y») at cmd_api.c:179
#6 0x00007f61bcdf653f in r_core_cmd_subst_i (core=0x606940 , cmd=0x20e04b0 «k 01Y») at cmd.c:1216
#7 0x00007f61bcdf4d09 in r_core_cmd_subst (core=0x606940 , cmd=0x20e04b0 «k 01Y») at cmd.c:776
#8 0x00007f61bcdf6f81 in r_core_cmd (core=0x606940 ,
cstr=0x7fffa832366f «k 01Y:216225256m371215a’Z213315vK20727420263b224є22177217217207r360z257237260v201s2043356516237367D234lp267taTݵd20126235361}F330%x342y3a360y33237004273357362U(T6=,35266267333v312r30302vFد232^23466u236263204e374344207320äR334MW222247322z330307SfL/241#35362342/376y:4zvx20621347267y177244tAp275 01300:235qA302332E22326m2Z{35603p32730211Ն177352212p354NO361361320O06/^251362235226[M)251203242/»…, log=0) at cmd.c:1405
#9 0x00007f61bcdf7527 in r_core_cmd0 (user=0x606940 ,
cmd=0x7fffa832366f «k 01Y:216225256m371215a’Z213315vK20727420263b224є22177217217207r360z257237260v201s2043356516237367D234lp267taTݵd20126235361}F330%x342y3a360y33237004273357362U(T6=,35266267333v312r30302vFد232^23466u236263204e374344207320äR334MW222247322z330307SfL/241#35362342/376y:4zvx20621347267y177244tAp275 01300:235qA302332E22326m2Z{35603p32730211Ն177352212p354NO361361320O06/^251362235226[M)251203242/»…) at cmd.c:1528
#10 0x0000000000404421 in main (argc=4, argv=0x7fffa8321988, envp=0x7fffa83219b0) at radare2.c:564
(gdb)
—
Reply to this email directly or view it on GitHub.

@zonkzonk

Copy link


Contributor

Author

apply exact payload [https://cloud.githubusercontent.com/assets/5694980/2818944/a0d56e32-cee9-11e3-93f7-a7062c6f73b4.png] and command [echo q| r2 -c «k cat /tmp/buf» /bin/ls] from initial post. don’t forget to base64 -d

@radare

Was this the same issue as «sdb — :» ?

On 05 Aug 2014, at 22:24, zonkzonk notifications@github.com wrote:

changed to

#0 0x00007f61ba1c0e92 in sdb_set_internal () from /usr/local/lib/libr_db.so.0.9.8.git
(gdb)
(gdb) bt
#0 0x00007f61ba1c0e92 in sdb_set_internal () from /usr/local/lib/libr_db.so.0.9.8.git
#1 0x00007f61ba1c0f4d in sdb_set_owned () from /usr/local/lib/libr_db.so.0.9.8.git
#2 0x00007f61ba1baf18 in sdb_json_set () from /usr/local/lib/libr_db.so.0.9.8.git
#3 0x00007f61ba1bf6d8 in sdb_querys () from /usr/local/lib/libr_db.so.0.9.8.git
#4 0x00007f61bcdf3bc9 in cmd_kuery (data=0x606940 , input=0x20e04b1 » 01Y») at cmd.c:396
#5 0x00007f61bce11bcd in r_cmd_call (cmd=0x1d97d10, input=0x20e04b0 «k 01Y») at cmd_api.c:179
#6 0x00007f61bcdf653f in r_core_cmd_subst_i (core=0x606940 , cmd=0x20e04b0 «k 01Y») at cmd.c:1216
#7 0x00007f61bcdf4d09 in r_core_cmd_subst (core=0x606940 , cmd=0x20e04b0 «k 01Y») at cmd.c:776
#8 0x00007f61bcdf6f81 in r_core_cmd (core=0x606940 ,
cstr=0x7fffa832366f «k 01Y:216225256m371215a’Z213315vK20727420263b224є22177217217207r360z257237260v201s2043356516237367D234lp267taTݵd20126235361}F330%x342y3a360y33237004273357362U(T6=,35266267333v312r30302vFد232^23466u236263204e374344207320äR334MW222247322z330307SfL/241#35362342/376y:4zvx20621347267y177244tAp275 01300:235qA302332E22326m2Z{35603p32730211Ն177352212p354NO361361320O06/^251362235226[M)251203242/»…, log=0) at cmd.c:1405
#9 0x00007f61bcdf7527 in r_core_cmd0 (user=0x606940 ,
cmd=0x7fffa832366f «k 01Y:216225256m371215a’Z213315vK20727420263b224є22177217217207r360z257237260v201s2043356516237367D234lp267taTݵd20126235361}F330%x342y3a360y33237004273357362U(T6=,35266267333v312r30302vFد232^23466u236263204e374344207320äR334MW222247322z330307SfL/241#35362342/376y:4zvx20621347267y177244tAp275 01300:235qA302332E22326m2Z{35603p32730211Ն177352212p354NO361361320O06/^251362235226[M)251203242/»…) at cmd.c:1528
#10 0x0000000000404421 in main (argc=4, argv=0x7fffa8321988, envp=0x7fffa83219b0) at radare2.c:564
(gdb)
—
Reply to this email directly or view it on GitHub.

@zonkzonk

Copy link


Contributor

Author

can’t reproduce in 424e166 build: 2014-11-04:

,cd /tmp/ ,echo q| r2 -c "k `cat /tmp/buf`" /bin/ls TODO(eddyb): uninmplemented ELF/x64 reloc type 5 TODO(eddyb): uninmplemented ELF/x64 reloc type 5 TODO(eddyb): uninmplemented ELF/x64 reloc type 5 TODO(eddyb): uninmplemented ELF/x64 reloc type 5 TODO(eddyb): uninmplemented ELF/x64 reloc type 5 TODO(eddyb): uninmplemented ELF/x64 reloc type 5 |ERROR| Invalid command 'k Y:���m�'Z��vK���b�є���r�z���v�s��5��D�lp�taTݵd���1}F�%x�y3a�y���U(T6=,��� � � Fد�^�6u���e����R�MW���z�S .Ka}L�r_ L/�#�2�/�y:4zvx��y�tAp� �:�qA�E�m2Z{�p��Ն�p�NO��O/^��[M)���/C�Tb�e�^M�ay!OB� ��Y�=�)=�K�bF�&&;�J�qzw~e���1_�B��������L$M��9/}&$�Gy�7f�����%U!�M.~�E�c�~��1˩z'�T'�J�]@U�?>�*�ۉp"��,Y``鷄���j���(��}��b�*c*���I��84&�����R�3�՟㱫w�%^)��&����*�j&���G�Ɗ�9W��^�h,�r� ' (0x6b) -- If you want to open the file in read-write mode, invoke r2 with '-w'

@ahmedhusnainjohar

Kuch nahi hona tm logon sy soday

Скорее всего, вы видите этот вопрос, потому что ваш вопрос был закрыт как дубликат этого. Для относительно полного списка связанных вопросов, пожалуйста, смотрите Длинный список возможных дубликатов — выделение памяти C и превышение границ на переполнении стека мета.

Пример вопроса

От свободный символ *: неверный следующий размер (быстрый) спросил Noobie 2014-04-11.

Я освобождаю char* после процесса конкатенации, но я получаю эту ошибку:

free(): invalid next size (fast): 0x0000000001b86170

Это мой код:

void concat(stringList *list) { char *res = (char*)malloc(sizeof(char*)); strcpy(res, list->head->string); list->tmp = list->head->next; while (list->tmp != NULL) { strcat(res, ","); strcat(res, list->tmp->string); list->tmp = list->tmp->next; } printf("%sn", res); free(res); }

Общий вопрос

При запуске моей программы я вижу сообщение об ошибке, подобное этому:

*** glibc detected *** ./a.out: free(): corrupted unsorted chunks: 0x12345678 ***

Подробная информация может содержать любое из следующего после *** glibc detected *** и имя программы, и сообщение сопровождается шестнадцатеричным адресом (показанным как 0x12345678) и другим ***:

  • free(): corrupted unsorted chunks: 0x12345678
  • free(): invalid next size (fast): 0x12345678
  • free(): invalid next size (normal): 0x12345678
  • free(): invalid pointer: 0x12345678
  • free(): invalid size: 0x12345678
  • malloc(): corrupted unsorted chunks: 0x12345678
  • malloc(): corrupted unsorted chunks 2: 0x12345678
  • malloc(): memory corruption: 0x12345678
  • malloc(): memory corruption (fast): 0x12345678
  • malloc(): smallbin double linked list corrupted: 0x12345678
  • munmap_chunk(): invalid pointer: 0x12345678
  • realloc(): invalid next size (fast): 0x12345678
  • realloc(): invalid old size (fast): 0x12345678
  • realloc(): invalid pointer: 0x12345678
  • corrupted double-linked list: 0x12345678

Это происходит во время вызова frobnicate() функция; что не так с этой функцией?

11

Решение

размотать дал принятый ответ к примеру вопроса:

Ваш код неверен.

Вы выделяете место для одного указателя (malloc(sizeof(char*))), но без символов. Вы перезаписываете выделенное пространство всеми строками, вызывая неопределенное поведение (в данном конкретном случае повреждение malloc()бухгалтерские данные).

Вам не нужно выделять место для указателя (res); это локальная переменная. Вы должен выделить место для всех символов, которые вы хотите сохранить по адресу, указанному указателем.

Так как вы собираетесь обходить список, чтобы найти строки для объединения, вы не можете знать общий размер заранее. Вам нужно сделать два прохода по списку: один для суммирования strlen() каждой строки, затем выделите этот пробел плюс для разделителя и терминатора, затем еще один проход, когда вы на самом деле делаете конкатенацию.

То, что вы видите, является результатом повреждения во внутренних структурах распределителя glibc. Когда вы выделяете или освобождаете динамическую память, распределитель должен управлять памятью, зарезервированной для ОС, и, в зависимости от запрашиваемого вами действия, найти новый блок для раздачи, отсортировать освобожденный блок в список тех, которые он можно раздать позже или вернуть память операционной системе. Эти сообщения об ошибках показывают, что структуры данных, которые он использует для управления этой функцией, повреждены.

Все эти ошибки означают, что часть вашего кода изменила память, которую он не дал использовать, вызывая неопределенное поведение. Скорее всего, это результат перезаписи некоторой памяти в вашей программе немного раньше, и вполне возможно, что ошибка не в frobnicate() функция.

Да, это означает, что ошибка может быть в любом месте вашей программы или сторонних библиотек, которые вы используете.

Это, вероятно, не очень хороший вопрос для переполнения стека. Если у вас нет простого простого воспроизведения вашей проблемы, это сообщество не сможет вам сильно помочь. Причиной ошибки может быть где-то в вашем коде (и очень часто это не в функции, где обнаружена ошибка), и это может быть в коде, который мы не можем видеть. Переполнение стека не сайт совместной отладки. Даже когда кто-то может найти недостаток в вашем коде, маловероятно, что ваш конкретный вопрос когда-либо поможет любому будущему посетителю.

Общие причины

  • Используйте после бесплатно. Вы освободили / удалили часть памяти и записали в нее потом, переписав структуры, необходимые glibc для бухгалтерии.
  • Ошибка выключения по N Вы записываете N байтов после выделенного фрагмента в нераспределенную память, которую glibc использует для своей внутренней бухгалтерии.
  • Неинициализированные указатели. Вы не инициализируете указатель. По совпадению это указывает на некоторую память, зарезервированную glibc, но не выделенную вашей программой, и вы записываете в нее.
  • Выделение неправильного количества места. Это может быть потому, что вы написали long *data = malloc(number * 4) вместо long *data = malloc(number * sizeof(long)); или лучше) long *data = malloc(number * sizeof(*data));, Есть много других способов сделать неправильный расчет размера. Другой распространенный способ — забыть учитывать нулевой символ-терминатор в конце строки: char *copy = malloc(strlen(str)); вместо char *copy = malloc(strlen(str)+1);,

Что вам нужно сделать сейчас, это закатать рукава и устранить эту проблему

Нет простого ответа, что искать или что исправить. Нет единой синтаксической конструкции, которую вы использовали неправильно. Причиной этой ошибки могут быть буквально тысячи разновидностей.

инструменты

  • Valgrind Инструмент, созданный в основном для поиска именно такого рода ошибок. Если он ничего не может найти, убедитесь, что вы используете последнюю версию, и вы также пробуете exp-sgcheck инструмент. Если вы используете многопоточный код, причина также может быть связана с состоянием гонки, поэтому вы можете попробовать использовать включенные средства проверки состояния гонки. drd а также helgrind для большего понимания. На момент написания этого valgrind поддерживает следующие платформы:
    • X86 / Linux,
    • AMD64 / Linux,
    • ARM / Linux,
    • Ppc32 / Linux,
    • PPC64 / Linux,
    • S390x / Linux,
    • MIPS32 / Linux,
    • MIPS64 / Linux,
    • ARM / Android (2.3.x и выше),
    • X86 / Android (4.0 и более поздние версии),
    • X86 / Дарвин и
    • AMD64 / Darwin (Mac OS X 10.7, с ограниченной поддержкой 10.8).
  • очищаться Подобный инструмент для valgrind, но коммерческий и нацеленный на другой набор платформ.
  • AddressSanitizer Аналогичный инструмент, но интегрированный в цепочку инструментов компилятора (gcc и clang).
  • efence Удаление замены распределителя, которое попытается завершить работу вашей программы раньше, так что вы сможете узнать с помощью обычного отладчика, где произошла запись в недействительную память.
  • пооддержки библиотека с той же целью, что и efence.

Нуждаюсь в большей помощи

Если вы не можете решить свою проблему с помощью одного из этих инструментов, вы должны попытаться создать MCVE (Как создать минимальный, полный и проверяемый пример?) или, что то же самое, SSCCE (Короткий, Автономный, Правильный (Компилируемый), Пример).

Не забудьте поработать над копией своего кода, потому что создание MCVE требует от вас безжалостного удаления кода, который не помогает воспроизвести проблему. Хорошая идея — использовать VCS (систему контроля версий); Вы можете записать промежуточные этапы в сокращении проблемы до минимума. Это может быть новый одноразовый репозиторий только для уменьшения вашей проблемы до приемлемого размера.

С хорошим модульным дизайном для вашего кода, создание MCVE должно быть относительно простым. Возможно, у вас уже есть модульный тест, который лучше подходит для использования в одном из вышеперечисленных инструментов. Вы также можете просто захотеть создать такой, который позже будет служить в качестве регрессионного теста для этой ошибки.

12

Другие решения

  • Forum
  • Beginners
  • «Error in … free(): invalid next size

«Error in … free(): invalid next size (normal):… Aborted (core dumped)»»

Hello,

I’m having an issue with this program that’s really bothering me. The code runs fine and goes to completion, but I get the error that’s in the post title. I’m familiar with core-dump-type errors; usually caused by trying to access memory that is out-of-bounds. This doesn’t seem to be that type of error, because my only dynamic memory allocation is in a single vector and I erase all of its elements using .erase() at the end of the program. The only other thing I can think of is that my file uses ifstream/ofstream inputs/outputs. I close them at the end of the file, but maybe that could be the issue? Anyways, I’ve commented out closing them and the issue still isn’t fixed.

Here’s a relevant snippet of the code, I can post more if needed. Note that the error is given to me after or right before the return call from int main()… I really don’t know what to make of that.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
 
int main( ) { //Establish and open input file string FileIn = "410nm_0002.atf"; string FileOut = "out"; //FileIn = GetFileIn( ); string Directory = "/home/"; FileIn = Directory + FileIn; FileIn_f.open( FileIn.c_str( ) ); FileOut_f.open( FileOut.c_str( ) ); block.resize( blocklength ); //Num bytes in memblock //Main loop if( FileIn_f.is_open( ) ) { FindTotalLines( FileIn ); ClearHeader( ); FindEvents( ); DeallocateMemory( ); FileIn_f.close(); FileOut_f.close(); } else { cout << "Couldn't open input filen"; } return 0; } void DeallocateMemory( ) { for( int i = 0; i < blocklength; i++ ) { block.erase(block.begin()); } cout << "block size: " << block.size() << "nn"; }

Last edited on 

1
2
3
 
for( int i = 0; i < blocklength; i++ ) { block.erase(block.begin()); }

Are you trying to win contest «slowest container clearing«? Why not use

.clear()

member function? Or even just let vector destructor do its job?

Nevertheless, problem is probably caused that you messed with one of the object memory (buffer overflow ir something similar) and now when its destructor invoked, it tries to free wrong memory.

Try to run your program through debugger and look where exactly it fails.

You have not shown enough code to isolate the problem.

Thanks for the replies, guys.

Are you trying to win contest «slowest container clearing»? Why not use .clear() member function? Or even just let vector destructor do its job?

I’ll be honest, while I like to think I’ve gotten good at programming in the past few months of self-teaching I still have HUGE gaps in my knowledge from a lack of formal training. Regardless, I originally had block.clear() in my code but I found this info about the function:

A reallocation is not guaranteed to happen, and the vector capacity is not guaranteed to change due to calling this function.

So, I thought that might be the issue and changed up the way I was clearing the vector just to eliminate the possibility that that was the issue.

Nevertheless, problem is probably caused that you messed with one of the object memory (buffer overflow ir something similar) and now when its destructor invoked, it tries to free wrong memory.

Sorry, not quite sure I understand this. Could the buffer flow you refer to be the buffer from an ifstream/ofstream?

I’ll run a debugger and try to pinpoint the exact location of the error. I’ll step it through gdb and come back.

Last edited on

So, I thought that might be the issue and changed up the way I was clearing the vector just to eliminate the possibility that that was the issue.

Actually after erase reallocation will not happen too (for sure this time) and capacity will not change.

If your code is not really big (under 300 lines) you can post it here.

From the debugger:

Breakpoint 2, main () at eventfinder.cpp:122
122 FileIn_f.close();
(gdb) step
123 FileOut_f.close();
(gdb) step
*** Error in `/home/preston/Desktop/Science/Research/ClampAnalyze/eventfinder/eventfinder’: free(): invalid next size (normal): 0x0000000000608620 ***

Program received signal SIGABRT, Aborted.
0x00007ffff722abb9 in __GI_raise (sig=sig@entry=6)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb)

The error occurs after all the meaningful parts of my code… Basically, like I said in my first post, it occurs when return 0; is called in int main().

Hi MiiNiPaa, thanks for sticking with me.

The code is ~450 lines. I wouldn’t want to do that to you. Still, as I mentioned in my previous post the error occurs at the very end of the program. It seems unlikely to me that something deep in the interior of the program could produce an error at the end of the code, especially considering the code compiles and runs perfectly except for that memory error.

EDIT: I also ran the program through valgrind and it found no memory leaks, and no other suspicious errors were posted.

Last edited on

Still, post it to the any paste site. Like http://pastebin.com/
It is not that big and I really need only to check on which destructor crashes.
Example of input file will be nice too.

It seems unlikely to me that something deep in the interior of the program could produce an error at the end of the code

It is very likely that violated invariants will not show themselves until object destruction.

link to code: http://pastebin.com/hTN9s6iW

I can’t post an entire sample of an input data file, because they are ~100 mb data text files. Here’s the general format, though:

ATF 1.0
7 4
«AcquisitionMode=Gap Free»
«Comment=»
«YTop=200000,200000,10»
«YBottom=-200000,-200000,-10»
«SweepStartTimesMS=0.000»
«SignalsExported=IN 0,IN 4,IN 5»
«Signals=» «IN 0» «IN 4» «IN 5»
«Time (s)» «Trace #1 (pA)» «Trace #1 (pA)» «Trace #1 (V)»
0 -12.207 -30322.3 0.298462
1e-4 0 -30334.5 0.297852
2e-4 0 -30334.5 0.296936
3e-4 -18.3105 -30334.5 0.297546
4e-4 -18.3105 -30328.4 0.296936
5e-4 -6.10352 -30346.7 0.297852
6e-4 -18.3105 -30328.4 0.297241
7e-4 -24.4141 -30340.6 0.297852

I cannot reproduce your problem, but if this code ever gains control:

1
2
3
4
5
6
 
 //This is used to kill false-events if( i > blocklength ) { FillBlock( i ); //Should be i - blocklength + (jumpahead) ? return; }

Then this: block[i + blocklength - blockstart] = ReadRow( ); will write before actual vector buffer, potentually wrecking vector internals. (I actually was able to reproduce it by manually writing garbage before vector).

Try to replace all index accesses (

block[something]

) with checked access (

block.at(something)

) If it will throw an exception, then this is the problem.

Ok I’ll look into it. Thanks for taking a look!

Topic archived. No new replies allowed.

вы, скорее всего, увидев этот вопрос, потому что ваш вопрос был закрыт как дубликат этого. Относительно полный список связанных вопросов см. В разделе длинный список возможных дубликатов-выделение памяти c/» class=»blnk»>C и переполнение границ о переполнении стека Meta.

Пример

С free char*: недопустимый следующий размер (быстро) попросил noobie on 2014-04-11.

я освободил char* после процесса объединения, но я получаю эту ошибку:

free(): invalid next size (fast): 0x0000000001b86170

это мой код:

void concat(stringList *list) { char *res = (char*)malloc(sizeof(char*)); strcpy(res, list->head->string); list->tmp = list->head->next; while (list->tmp != NULL) { strcat(res, ","); strcat(res, list->tmp->string); list->tmp = list->tmp->next; } printf("%sn", res); free(res); }

Универсальный Вопрос

при запуске моей программы, я получаю сообщение об ошибке вроде этого:

*** glibc detected *** ./a.out: free(): corrupted unsorted chunks: 0x12345678 ***

подробная информация может содержать любое из следующих после *** glibc detected *** и имя программы, а за сообщением следует шестнадцатеричный адрес (показано как 0x12345678) и другое ***:

  • free(): corrupted unsorted chunks: 0x12345678
  • free(): invalid next size (fast): 0x12345678
  • free(): invalid next size (normal): 0x12345678
  • free(): invalid pointer: 0x12345678
  • free(): invalid size: 0x12345678
  • malloc(): corrupted unsorted chunks: 0x12345678
  • malloc(): corrupted unsorted chunks 2: 0x12345678
  • malloc(): memory corruption: 0x12345678
  • malloc(): memory corruption (fast): 0x12345678
  • malloc(): smallbin double linked list corrupted: 0x12345678
  • munmap_chunk(): invalid pointer: 0x12345678
  • realloc(): invalid next size (fast): 0x12345678
  • realloc(): invalid old size (fast): 0x12345678
  • realloc(): invalid pointer: 0x12345678
  • corrupted double-linked list: 0x12345678

этот происходит при вызове ; что не так с этой функцией?

1 ответов

ответ, например, вопрос

отдыха дал принята ответ к вопросу примера:

ваш код неверен.

вы выделяете пространство для одного указателя (malloc(sizeof(char*))), но нет символов. Вы перезаписываете выделенное пространство всеми строками, вызывая неопределенное поведение (в данном конкретном случае, corrupting malloc()бухгалтерские данные).

вам не нужно выделять пространство для указателя (res); это локальная переменная. Вы должны выделите место для всех символов, которые вы хотите сохранить по адресу, удерживаемому указателем.

так как вы собираетесь пересекать список, чтобы найти строки для объединения, вы не можете знать общий размер заранее. Вам придется делать два прохода по списку: один на сумму strlen() каждой строки, затем выделите это плюс пространство для разделителя и Терминатор, затем еще один проход, когда вы действительно делаете конкатенацию.

Общий Ответ

то, что вы видите, является результатом коррупции во внутренних структурах распределителя glibc. Когда вы выделяете или освобождаете динамическую память, распределитель должен управлять памятью, зарезервированной из ОС, и, в зависимости от запрошенного вами действия, найти новый фрагмент для раздачи, отсортировать освобожденный фрагмент в списке тех, которые он может раздать позже или Верните память операционной системе. Эти сообщения об ошибках показывают, что структуры данных, используемые для управления этой функцией, повреждены.

все эти ошибки означают, что некоторые из вашего кода изменили память, которую не было дано использовать, вызывая неопределено поведение. Это, скорее всего, результат перезаписи некоторой памяти совсем немного раньше в вашей программе, и вполне возможно, что ошибка не лежит в frobnicate() функция.

Да, это означает, что ошибка может быть в любом месте вашей программы или сторонних библиотек вы используете.

наверное, это не очень хороший вопрос для переполнения стека. Если у вас нет хорошего простого воспроизведения вашей проблемы, это сообщество может быть не в состоянии помочь вам очень много. Причина ошибки может быть в любом месте вашего кода (и очень часто не в функции, где обнаружена ошибка), и это может быть в коде, который мы не видим. Переполнение стека не сайт для совместной отладки. Даже если кто-то может найти изъян в вашем коде, маловероятно, что ваш конкретный вопрос когда-либо поможет любому будущему посетителю.

распространенные причины

  • использовать после освобождения. вы освободили / удалили некоторую память и записываете в нее впоследствии, перезаписывая структуры, необходимые glibc для бухгалтерского учета.
  • Off-by-N ошибка. вы пишете n байт после выделенного куска в нераспределенную память, которую glibc использует внутренне для своей бухгалтерии.
  • неинициализированные указатели. вы не инициализируете указатель. По совпадению он указывает на некоторую память, зарезервированную glibc, но не выделенную вашей программой, и вы пишете в нее.
  • выделение неправильного объема пространства. это может быть потому, что ты написал long *data = malloc(number * 4) вместо long *data = malloc(number * sizeof(long)); или (лучше) long *data = malloc(number * sizeof(*data));. Есть много других способов получить неверный расчет размера. Еще один распространенный-забыть учитывать символ нулевого Терминатора в конце строки:char *copy = malloc(strlen(str)); вместо char *copy = malloc(strlen(str)+1);.

что вам нужно сделать сейчас, это засучить рукава и отладить эту проблему

нет простого ответа, что искать, или что исправить. Ни одной синтаксической конструкции, которую вы использовали неправильно. Причиной этой ошибки могут стать буквально тысячи разновидности.

инструменты

  • отчет инструмент, созданный в основном с целью поиска именно таких ошибок. Если он ничего не может найти, убедитесь, что вы используете последнюю версию, и вы также пробуете включенный . Если вы используете многопоточный код, причина также может быть связана с состоянием гонки, поэтому вы можете попробовать включить проверки состояния гонки drd и helgrind для больше понимания. На момент написания этой статьи valgrind поддерживает следующие платформы:
    • X86 / Linux,
    • AMD64 / Linux,
    • ARM / Linux,
    • PPC32 / Linux,
    • PPC64 / Linux,
    • S390X/Линукс,
    • MIPS32 / Linux,
    • MIPS64/Линукс,
    • ARM / Android (2.3 .x и позже),
    • X86 / Android (4.0 и более поздних версий),
    • X86 / Дарвин и
    • AMD64 / Darwin (Mac OS X 10.7, с ограниченной поддержкой 10.8).
  • очистить аналогичный инструмент для valgrind, но коммерческий и нацеленный на другой набор платформ.
  • AddressSanitizer аналогичный инструмент, но интегрированный в компилятор toolchain (gcc и clang).
  • efence падение в замене распределителя, которая попытается разбить вашу программу раньше, чтобы вы могли узнать с помощью обычного отладчика, где произошла запись в недопустимую память.
  • dmalloc библиотека с аналогичной целью, как efence.

нуждающихся в помощи!—52—>

если вы не можете решить свою проблему с помощью одного из этих инструментов, вы должны попытаться создать MCVE (как создать минимальный, полный и проверяемый пример?) или, что то же самое, в SSCCE (Короткий, Автономные, Правильный (Компилируемые), Пример).

не забудьте поработать над копией вашего кода, потому что создание MCVE требует от вас безжалостного удаления кода, который не помогает воспроизвести проблему. Использование VCS (системы управления версиями) для помощи-хорошая идея; вы можете записывать промежуточные этапы в сведении проблемы к минимуму. Это может быть новый выбрасываемый репозиторий только для уменьшения вашей проблемы до управляемого размер.

С хорошим модульным проектированием к вашему коду, должно быть относительно легко создать MCVE. Возможно, у вас уже есть модульный тест, который лучше подходит для подачи в один из вышеупомянутых инструментов. Вы также можете просто создать тот, который позже может служить регрессионным тестом для этой ошибки.

Источник
Автор Тема: free(): invalid next size (fast)  (Прочитано 5864 раз)
vulko

Гость

Ребята, столкнулся с таким вот крэшем.
То ли double free, то ли free/new, то ли delete/malloc…

Но все это происходит насколько я понимаю после ресайза виджета. Собсно ресайзы програмные происходят, причем могут очень часто.
Хотя возможно и не в этом причина…

Что это, баг Qt? Куда копать? Дебажить внутри Qt?
Я верно понимаю мне нужно будет пересобрать Qt в дебажную версию?
Умеет ли QtCreator дебажить внутри .so?

Qt предустановлен в пакетах уже, можно ли без пересборки? Может подтянуть пакет откуда? Или побилдить дебажные либы и подменить ими обычные?

Qt 4.8.5
Linux (X Windows) дебианоподобное.

0   __GI_raise   raise.c   64   0x7ffff519dbf5   
1   __GI_abort   abort.c   92   0x7ffff51a0d98   
2   __libc_message   libc_fatal.c   189   0x7ffff51d7d15   
3   malloc_printerr   malloc.c   6283   0x7ffff51e1dc6   
4   __GI___libc_free   malloc.c   3738   0x7ffff51e5d7c   
5   QBoxLayout::setGeometry(QRect const&)   /usr/lib/x86_64-linux-gnu/libQtGui.so.4   0   0x7ffff6b174fb   
6   QLayoutPrivate::doResize(QSize const&)   /usr/lib/x86_64-linux-gnu/libQtGui.so.4   0   0x7ffff6b31c73   
7   QLayout::activate()   /usr/lib/x86_64-linux-gnu/libQtGui.so.4   0   0x7ffff6b331bd   
8   QApplicationPrivate::notify_helper(QObject*, QEvent*)   /usr/lib/x86_64-linux-gnu/libQtGui.so.4   0   0x7ffff6b0916e   
9   QApplication::notify(QObject*, QEvent*)   /usr/lib/x86_64-linux-gnu/libQtGui.so.4   0   0x7ffff6b0d62a   
10   QCoreApplication::notifyInternal(QObject*, QEvent*)   /usr/lib/x86_64-linux-gnu/libQtCore.so.4   0   0x7ffff62906be   
11   QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*)   /usr/lib/x86_64-linux-gnu/libQtCore.so.4   0   0x7ffff62947a1   
12   ??   /usr/lib/x86_64-linux-gnu/libQtCore.so.4   0   0x7ffff62bee03   
13   g_main_context_dispatch   /lib/x86_64-linux-gnu/libglib-2.0.so.0   0   0x7ffff3a49355   
14   ??   /lib/x86_64-linux-gnu/libglib-2.0.so.0   0   0x7ffff3a49688   
15   g_main_context_iteration   /lib/x86_64-linux-gnu/libglib-2.0.so.0   0   0x7ffff3a49744   
16   QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)   /usr/lib/x86_64-linux-gnu/libQtCore.so.4   0   0x7ffff62bef96   
17   ??   /usr/lib/x86_64-linux-gnu/libQtGui.so.4   0   0x7ffff6baf0de   
18   QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)   /usr/lib/x86_64-linux-gnu/libQtCore.so.4   0   0x7ffff628f40f   
19   QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>)   /usr/lib/x86_64-linux-gnu/libQtCore.so.4   0   0x7ffff628f698   
20   QCoreApplication::exec()   /usr/lib/x86_64-linux-gnu/libQtCore.so.4   0   0x7ffff6294ab8   
21   main   main.cpp   23   0x417ecd   

Записан
Alex Custov

В 99.9% случаев это твоя ошибка при работе с указателями — двойное удаление, разыменование нулевого указателя и т.п. Ищи ошибку у себя в коде. Можно с помощью valgrind, но лучше руками.

Debug символы можно получить установив пакет qtbase5-dbg
« Последнее редактирование: Ноябрь 12, 2014, 15:08 от Alex Custov »
Записан
vulko

Гость

В 99.9% случаев это твоя ошибка при работе с указателями — двойное удаление, разыменование нулевого указателя и т.п. Ищи ошибку у себя в коде. Можно с помощью valgrind, но лучше руками.

Debug символы можно получить установив пакет qtbase5-dbg

Ты стэк смотрел? Там ниодного моего вызова нет)
Хотя не отрицаю, что мой код мог спровоцировать подобное поведение…
Либо creator как обычно криво дебажит… но уж стэк то не должен был перепутать.

valgrind я бы и рад, но с ним нереально будет воспроизвести ошибку вообще никак. я вижу дикое слайдшоу под валгриндом.
впрочем можно попробовать перерисовку делать не раз в 10мс а раз в 1секунду… надо попробовать. но это уже не то.
да и он мне очень много ошибок выдает, но 99% внутри qt, llvm и другой шляпы…

пакет попробую канеш, но у меня гемор с дебиановским и убунтовским репозиториями. т.к. линух «кастомный».
отдельно можно его где нибудь скачать и поставить ручками?

Записан
Alex Custov

Ты стэк смотрел? Там ниодного моего вызова нет)

Это ни о чём не говорит. В случае когда бьётся память (двойное удаление указателя), падение может произойти уже после него в совершенно нормальном месте.

пакет попробую канеш, но у меня гемор с дебиановским и убунтовским репозиториями. т.к. линух «кастомный».
отдельно можно его где нибудь скачать и поставить ручками?

Из репозиториев твоего дистрибутива. Ставить откуда-то ещё крайне не рекомендуется.

Записан
vulko

Гость

Ты стэк смотрел? Там ниодного моего вызова нет)

Это ни о чём не говорит. В случае когда бьётся память (двойное удаление указателя), падение может произойти уже после него в совершенно нормальном месте.

пакет попробую канеш, но у меня гемор с дебиановским и убунтовским репозиториями. т.к. линух «кастомный».
отдельно можно его где нибудь скачать и поставить ручками?

Из репозиториев твоего дистрибутива. Ставить откуда-то ещё крайне не рекомендуется.

В принципе да, ниочем не говорит, если бы не одно но…
Приложение у меня логирует свою работу. Соотв. логи позволяют повторять одни и те же действия записанные в файл.
Так вот при воспроизведении этих логов много раз подряд случается крэш.
Т.е. крэш рандомный. А действия эти даже не что-то типа автоматизированного тестирования, а куда более идентичные, в плане работы приложения.

И вот во время воспроизведения лога в эн-ный раз отваливается.
есть у меня модель, где лежать актуальные данные, которые берутся из логов. каждый раз перед новым воспроизведением они очищаются.

если бы это была проблема double free или free памяти выделенной new или delete памяти выделенной malloc’ом, то крэш не был бы рандомным наверное?
впрочем это я проверю все же…

Записан
Alex Custov

если бы это была проблема double free или free памяти выделенной new или delete памяти выделенной malloc’ом, то крэш не был бы рандомным наверное?

Поведение в такой ситуации не определено, и поэтому может быть любым.

Записан
vulko

Гость

Никаких double free, как я и предполагал нет.
Лики были, пофиксил.

Не понимаю причину крэша… Хотя возможно было как-то связано с тем что я хранил ссылки на QObject в модели… Эти же QObject’ы жили в QTableWidget, который очищался при очистке модели… правда они без parent’а были, поэтому при очистке таблицы они не удалялись…

В общем так и не понял я причину…

Записан
Bepec

Гость

Указатели new delete освобождение.
 Вот если б твоё приложение логировало полностью своё поеведение вплоть до занимаемых и очищаемых секторов памяти, тогда б ты мог уверенно сказать про причину Улыбающийся А так раз на раз не приходится Веселый

Записан

Источник

  • Ошибка fraps has been known to crash d3d11
  • Ошибка fr5252 на атего
  • Ошибка fr 40 41 мерседес atego
  • Ошибка fr 3130 мерседес актрос мп1
  • Ошибка fr 3130 мерседес аксор