BGAFC Vendégkönyv

Σ: 1 post

TCH (statz)

#1, Főfasz (10443)

3542 | #2f1f | ^ | Idézet | Sun, 30 Nov 2014 18:57:40 +01

46.139.*.*

*.catv.pool.telekom.hu

Most húztam le a slozin a GCC-t egyszer s mindenkor! Én ilyet még életemben nem basztam, amit ma ez a hulladék lószar produkált! Most dolgozom egy PNG => IFF konverteren és van nekem egy struct-om, ami így néz ki:

struct png_struct
{
	s32 width;
	s32 height;
	u8 bit_depth;
	u8 color_type;
	u8 compression_method;
	u8 filter_method;
	u8 interlace_method;
	u32 palette[256];
	size_t image_size;
	char *image;
};

És tartozik hozzá egy függvény:

open_png(char *src, png p, bool calc_crc)

Működött is a beolvasás, dekódolás, kitömörítés... Viszont ma eszembe jutott, hogy mi van, ha csak a header-t akarom parse-lni? Módosult a két cucc:

struct png_struct
{
	s32 width;
	s32 height;
	u8 bit_depth;
	u8 color_type;
	u8 compression_method;
	u8 filter_method;
	u8 interlace_method;
	u32 palette[256];
	bool data_loaded;
	size_t image_size;
	char *image;
};

open_png(char *src, png p, bool calc_crc, bool only_parse_header)

Eredmény? Segmentation fault. WTF?! És utána rájöttem, hogy akármit változtatok a struct-on, segfault az eredmény! Kishíján összeszartam magam, hát ilyet még az életben nem pipáltam! Utána kidebuggoltam, hogy a segfaultot ez a sor okozza:

p->image = realloc(p->image, new_size);

Mégpedig azért, mert az image valahogy nem NULL értékkel bírt, holott annál a sornál annak kéne lennie! Elkezdtem kidebuggolni, hogy hol változik meg és végül rájöttem, hogy ennél a sornál:

data = realloc(data, chunk_length + 4);

Előtte NULL a p->image, utána pedig 1024! DAFUQ?! Senki nem nyúl hozzá, se közel, se távol! Mi a fasz?! Mi az eres, retkes faszom ez?! Valami GCC bug?! CLANG fel. Compile. És működik bazdmeg. ÉS MŰKÖDIK BAZDMEG!!! IGEN, EZ EGY KIBASZOTT GCC BUG!!! Hát én ilyet még életemben nem pipáltam, hogy egy realloc egy totál másik pointert szétcsesszen és mindezt egy a kód által nem érintett struct megváltoztatása miatt! 4.6-os és 4.7-es GCC is dettó ugyanezt produkálja, 4.8-at meg nem lehet feltenni Debian 7-re csak úgy, hiába kerestem, mindenütt azt válaszolták a hogy lehet 4.8-at rakni Wheezy-re jellegű kérdésekre, hogy az nem jó ötlet, meg minek neked az. Minek nekem az?! Annak, hogy az előzőek bugosak! (Bár ki tudja, lehet, hogy az utána lévők is!) Nem lehet felrakni?! Ok! Akkor GCC => slozi!

root@Csabi:~# cd /usr/bin
root@Csabi:/usr/bin# unlink gcc
root@Csabi:/usr/bin# unlink g++
root@Csabi:/usr/bin# unlink cpp
root@Csabi:/usr/bin# ln -s clang gcc
root@Csabi:/usr/bin# ln -s clang g++
root@Csabi:/usr/bin# ln -s clang cpp

Good riddance!

Ne használjatok GCC-t, mert SZAR!

Sz*rk: A CLANG-gal bezzeg nincs olyan baj, hogy hogy rakom fel a legújabbat Debian 7-re! http://llvm.org/apt/

Sz*rk #2: Közben egyébként rájöttem, hogy mi okozta (a data változó nem volt NULL), de hogy ez MIÉRT okozta, amit okozott, miért baszik el egy teljesen másik pointert, egy a kód által nem érintett struct-ban és hogy akkor miért ment ez CLANG-ban...
Egyébként -O2 vagy -O3 kapcsolónál a CLANG is elszállt, de az ott és azért szállt el, ahol és amiért elbasztam, nem baszott szét teljesen véletlenszerűen valami egészen mást! Ezért is bírtam rájönni, hogy mi a franc van. Most már megy GCC-ben is, de most már akkor is a CLANG mellett maradok; ha elbaszok valamit, akkor az legyen elbaszva, amit elbasztam és ne totál más!