malloc: memory corruption

больше ненужных тегов!

и?

перепиши:

./a.out

gdb ./a.out <<EOF
r
EOF

Как и на что ругается отладчик?

p.s. Зачем нужна лишняя пара скобок?

*** Error in `/home/путь_до_исполняемого_файла': malloc(): memory corruption: 0x63c070 ***

на malloc(): memory corruption же

p.s. Зачем нужна лишняя пара скобок?

да на всякий. а вообще, там изначально reinterpret_cast был.

версии компилятора, отладчика и операционной системы

3.8.0-19-generic x86-64, gcc 4.7.3, gdb 7.5.91

Такой пример тоже не работает?

g++ -x c++ - <<EOF
#include <stdio.h>
#include <stdlib.h>
static int* data;
int main(){
  data = (int*)(calloc(40, sizeof(int)));
  printf("data = %p\n", data);
  return 0;
}
EOF

g++ -x c++ - <<EOF

gcc -x c - <<EOF

У тебя по-любому либо два раза вызывается SomeClass::func(), либо ты еще где-то некорректно работаешь с data.

Что-то тут не то, это, видимо, далеко не весь код. Ругается не отладчик, а glibc. И это последствие ошибки, а не сама ошибка, которая где-то в другом месте повредила управляющие структуры heap. С valgrind будет проще найти где настоящая проблема.

ошибка при запуске тоже происходит?

плюсовый же проект, не скомпилится. в с нет статических переменных внутри структур и функций внутри структур.

Такой пример тоже не работает?

так работает

У тебя по-любому либо два раза вызывается SomeClass::func()

ровно 1. иначе попадал бы в неё отладчиком, соответственно 2(+) раза.

либо ты еще где-то некорректно работаешь с data.

допустим даже так, при calloc в этом случае должна возникнуть утечка памяти, а не вылет по memory corruption

плюсовый же проект, не скомпилится.

а что ты под отладкой тогда запускал?

в с нет статических переменных внутри структур и функций внутри структур.

имелся ввиду запуск примера без структур с gcc компилятором.

плюсовый же проект,

зачем тогда calloc?

изначально там realloc был, но он ни так, ни так не работает

а надо new и delete использовать

они не умеют в реаллокацию и на больших объёмах, поэтому, тормозные

valgrind

для этого придумали new с размещением

а что ты под отладкой тогда запускал?

скомпилированный бинарник

ага, а память под это размещение выбивать тем же realloc-ом

все с тобой ясно, продолжай

так работает

этот пример работает?

Баг либо в железе, либо в ляликсе

memtest попробуй прогнать для начала

Пруф?

на malloc(): memory corruption же

Ну так давайте пример кода, где это происходит. То, что я вижу в топике не должно портить память.

Во-первых, кто тебя учил такому адовому форматированию? Во-вторых, где минимальная компилирующаяся и запускающаяся программа на которой проявляется проблема?

На свете есть классные автоматические детектилки порченной памяти (и других ошибок). Советую valgrind: http://code.haskell.org/~slyfox/trofi-valgrind-overview-2013-03-30.pdf

Проблема, скорее всего, где-то в другом месте. Такие баги бывают, если начать писать в какую-то левую память и случайно «переехать» служебную информацию malloc'а. valgrind тебе в помощь

Во-первых, это Horstmann. Во-вторых, она черезчур большая, чтобы на ЛОР её вот так запостить.

ага, спасибо. действительно, слегка был сбит с толку: подумал, может баг какой в гцц опять, версия-то старая. на самом деле, достаточно быстро нашёл место, в котором производился доступ к уже освобождённой памяти. даже валгринд не потребовался.

Запости куда-нибудь ещё, очевидно же.

и что будет? кто-то станет ковыряться в таком достаточно большом проекте?

Во-первых, это Horstmann.

Ну и? Говно ведь. Читать не удобно и писать не удобно. Не советую так писать — коллеги побьют.

Во-вторых, она черезчур большая, чтобы на ЛОР её вот так запостить.

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

и писать не удобно.

Правая кнопка мыши -> Format use AStyle

Читать не удобно

как раз наоборот, целая строчка экономится. отдавать её под единственную скобку — перебор

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

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

она черезчур большая, чтобы на ЛОР её вот так запостить.

поэтому тебе следует напрячься и написать на ее основе минимальную программу на которой проявляется твоя проблема.

целая строчка экономится. отдавать её под единственную скобку — перебор

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

как раз наоборот, целая строчка экономится.

Hint:

int foo()
{// это комментарий видно если складка свёрнута
  // code
  return 0;
}

Hint:

int foo() // этот комментарий видно, если складка свёрнута
{ // code
  return 0;
}

ИМХО заголовок функции и тело функции — разные сущности, и должны быть разделены комментарием или пустой строкой, если комментарий очевиден.

ИМХО, нет

хм, а почему нельзя править?

ты можешь вообще всё одной строкой написать, я не против.

/* комментарии к функциям надо писать * вот тут

а если для этой функции(блока) многострочный комментарий не нужен?

PS: править можно.

/* нууу... тогда можно написать однострочный :) */
int foo() {
  // code
  return 0;
}

PS: вот это malloc: memory corruption (комментарий) сообщение я править не мог еще до ответа на него

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