Что не нравится valgrind? (invalid write of size 4)

Снаружи приходят адекватные данные.

Не верю (с)

А откуда *index берется? Покажи код, который вызывает этот SmlWhsAdd

Для начала:

p = realloc(p, ...);

Правильней будет:

newsize = size + 50; 
if ((newp = realloc(p, newsize)) == NULL) { 
	free(p); 
	p = NULL; 
	size = 0; 
	return (NULL); 
} 
p = newp; 
size = newsize;

Еще один, блин. Бести, ну хоть ты не тупи и в ман не тыкай, а сначала код посмотри. В случае неудачного реаллока указатель откатывается на oldptr.

А да, сразу не приметил.

А что у нас с SmlIndex? Какой тип?

Судя по ошибке, туда пишется int32_t — то к чему приводится выражение, а что там на самом деле?

Судя по ошибке, туда пишется int32_t

uint32_t

/* E */ typedef uint32_t SmlIndex;

typedef struct
{
    SmlBool        halt;
    SmlAtoms       atoms;
    SmlEngine      engine;
    SmlScreen      screen;
    SmlElement   * elem;
    uint32_t       elemcount;
    SmlDirectories directories;
} Warehouse;

Покажи ещё тогда за одно, от куда идёт вызов.

Так уже ж показал. Начинается в main.c, дерево в Что не нравится valgrind? (invalid write of size 4) (комментарий)

А где выделение памяти под sprite и theme?

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

SmlWhsAdd >

warehouse.elem      = realloc(warehouse.elem,
                                  (++warehouse.elemcount) * sizeof(SmlElement));

typedef struct
{
	SmlGeometry  geometry;
	SmlIndex     sprite[SML_THEMEBLOCK_SIZE];
	SmlIndex     theme [SML_THEMEBLOCK_SIZE];
	int32_t      state;
	SmlBool      visible;
	char *       caption;
    SmlBool      enabled;
	SmlWidgetExt ext;
} SmlWidgetData;

typedef union
{
    SmlGenericData  gen;
    SmlWidgetData   wdg;
    SmlTimerData    tmr;
    SmlImageData    img;
    SmlFontData     fnt;
    SmlThemeData    thm;
    SmlGradientData grd;
    SmlMemoryData   mem;
} SmlElemData;

typedef struct
{
    SmlElemType    type;
    SmlElemSubtype subtype;
    SmlBool        exists;
    SmlIndex       parent;
    SmlElemData    data;
} SmlElement;

в жопу valgrind: по отметке «<---- Здесь» должен ругаться даже компилер.

Не понятно ничего из этого кода. Есть полные исходники? Я бы например добавил следилку, чтобы на каждый malloc realloc free на который имеет право(может) указывать этот твой SmlIndex * index создавался(malloc/alloca) или модифицировался(realloc) или удалялся(free) элемент из специального связного списка, вот примерно вот такого

struct l_l_memreg
{
    struct l_l_memreg *next;
    struct l_l_memreg *prev;
    void *fr_addr;
    void *to_addr;
};

*index = (warehouse.elemcount - 1); 

if (checkifallowed(index) == FAIL ) {error();}
*index = (warehouse.elemcount - 1);

Обоснуй

Думаю, идея ясна

Не ясна. malloc/realloc не фейлится, программа работает как надо. Зачем такие извращения? Я потом вообще все проверки malloc/realloc переделаю в mymalloc в котором буду громко падать. Утечек по тому же valgrind нет. Bitching только на выделенную строку (ну и каждый раз когда используется из другой функции).

warehouse.elem[warehouse.elemcount - 1] = element;

А у тебя этот warehouse.elemcount может теоретически стать нулем? И тогда warehouse.elem[0-1] - не будет ли тут ошибки?

и этому скажу — кривой у тебя код.

Мой код быстрее и оптимальнее твоего стандартного подхода - там ты выполняешь действия когда реаллок выполнился нормально, здесь - когда упал (что маловероятно и практически невероятно при малых данных).

Он в самом начале программы нуль. Но выше по коду, как можно заметить, есть ++warehouse.elemcount.

Идея не в том чтобы подсчитывать количество malloc/realloc и ловить утечки, а в том чтобы записывать регионы памяти, который этим malloc/realloc выделены для *index, и при попытке записи в *index просматривать эти регионы, и если адрес, по которому мы хотим записывать не значится в записях, падать и вызывать бектрейс

А может ли warehouse.elemcount переполниться и стать нулем?

размерности не сошлись, 4 байта пропали :-) пункт назначение 32 бита, отправки 64. или наоборот :-)

Кстати, возможно что именно это.

Edible, какая размерность системы?

IIRC, int при вычислениях приводится к системному типу.

Т.е. фикс вида:

/* E */ typedef uint SmlIndex;

http://goo.gl/9u8lkr кастуется оно все. Могу даже в стандарте порыться, там точно этот момент описан

стандарт бумага, а ты в реальной жизни - valgrind будет ругаться если считает что часть данных пропадает.

Мой код быстрее и оптимальнее твоего стандартного подхода

Гы-гы-гы. Попробовал написать два варианта с добавлением в int[] массив. В «твоём» варианте в ожидаемом пути оказалось на одно обращение к памяти больше (к аналогу elemcount). В принципе, не страшно, но вынуждает сбросить записи раньше, чем возможно было.

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

int main(void)
{
  char *a = malloc(10);
  a[-1] = 0;
  return 0;
}

==14599== Invalid write of size 1
==14599==    at 0x40054B: main (in /path/to/file/a.out)
==14599==  Address 0x51fc03f is 1 bytes before a block of size 10 alloc'd
==14599==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14599==    by 0x40053E: main (in /path/to/file/a.out)
==14599== 
==14599== 

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

Тогда был бы invalid read, а у него write.

1. Что внутри у SML_CHECKPTR?
2. printf(«%zu %p\n», sizeof(index), &index) в main()
3. printf(«%zu %p\n», sizeof(*index), index) в SmlWhsAdd() + по всему стеку выше

Компилеры gcc и clang на такое ругаться не умеют. Почему не умеют - вопрос не ко мне

uint32_t. Не может. На создание одного элемента суммарно эдак 0.05 с. уходит. Пару лет до переполнения точно ждать.

// Moreo

Размерность системы 32.

1.

#define SML_CHECKPTR(X)\
if (!(X)) return SML_ERR_BADPOINTER;

Мой код быстрее и оптимальнее твоего стандартного подхода - там ты выполняешь действия когда реаллок выполнился нормально, здесь - когда упал (что маловероятно и практически невероятно при малых данных).

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

Почему бы не использовать reallocf?

reallocf

Чего только на ЛОРе не узнаешь.

Фигасе, ей знаешь сколько лет?

Фигасе, ей знаешь сколько лет?

Думаю, чуть больше семнадцати лет, двух месяцев и пары дней.

http://svnweb.freebsd.org/base?view=revision&revision=39191

Не ломается. Индесы находятся в статическом массиве, который находится в SmlElement. SmlElement корректно выделяется маллоком в том же WhsAdd, если не трогать создание текстур - то valgrind молчит, т.е. в самом WhsAdd проблемы нет.

Тогда копаю глубже в сторону проблемы с widget->sprite. Но даже намека на развязку не вижу.

typedef struct
{
	SmlGeometry  geometry;
	SmlIndex     sprite[SML_THEMEBLOCK_SIZE];
	SmlIndex     theme [SML_THEMEBLOCK_SIZE];
	int32_t      state;
	SmlBool      visible;
	char *       caption;
    SmlBool      enabled;
	SmlWidgetExt ext;
} SmlWidgetData;

Вот на данный момент, я поправил все остальные сообщения, выделил только текстуры для одного объекта, получил только вот эти сообщения:
http://s16.postimg.org/f3efs5tg5/Screenshot_17_11_2015_00_29_07.png

Кроме показанного, моих сообщений нет (есть утечка в fontconfig, не моя).

Мыслей нет совсем. Доп инфа, что удалось накопать - SmlWidgetSpritesCreate вызывается только единожды, SML_THEMEBLOCK_SIZE = 0x20. Как понять на какие индексы он ругается - не знаю. Было бы неплохо это узнать - облегчило бы поиск проблемы.

Как понять на какие индексы он ругается - не знаю. Было бы неплохо это узнать - облегчило бы поиск проблемы.

Вставил в 75ю строку printf i и слип на 10 секунд. путем переключения между окном вывода и окном анализатора выяснил что ругается показав «0». Т.е. походу сразу на первом же элементе.

Не помогло(

SZT, beastie, удалось получить минимальный пример (100 строк). Ошибка воспроизводится. http://pastebin.com/r5T5ZBPC

Вызов realloc освобождает warehouse.elem, а ты в него пишешь как в *index.

Чего?

warehouse.elem      = realloc(warehouse.elem,
                                  (++warehouse.elemcount) * sizeof(SmlElement));

1. elemcount = elemcount+1
2. sizeof() = 1030
3. realloc(elem, (elemcount+1)*1030)
4. warehouse.elem = newpointer.

Вот тут

SmlWhsAdd(sprite, &(warehouse.elem[window].data.wdg.sprite[0]));

второй параметр куда указывает?

Я понял в чём у тебя ошибка.

• line 86 — определение пустого элемента (NULL)
• line 96 — index(!) в пустой элемент определённый выше, передача в функцию по значению
• line 75 — запись «в никуда» по указателю на NULL

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

Там беда в том, что &(warehouse.elem[window].data.wdg.sprite[0]) пераётся в функцию, но при этом warehouse.elem == NULL!

ЗЫ: да, ты о том же. ;) Не заметил.

Тут надо помнить, что это минифицированный пример. Допустим, warehouse.elem не будет равно NULL'у. Всё равно ведь берётся указатель на место в памяти, а внутри функции эта память освобождается realloc'ом. Причём благодаря тому, что делается это не каждый раз, а только когда realloc'у перестанет хватать выделенного для блока места, баг получается «плавающим».

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