Dotaz: pthread_mutex_init ve strukture

[pou]

Dobrý den, píšu si jeden takový malinky program v C.

V tom programu definuji strukturu:

struct HANDLER{
    MEMORY * memory;
};


struct MEMORY{
    CMD action;
    pthread_mutex_t mutex;
    char * Buffer;
    int start;
    int stop;
};

a k ni inicializacni funkci:

HANDLER * init_handler(){
    HANDLER * handler;
    handler=new HANDLER;
    handler->memory=new MEMORY;
    handler->memory->Buffer=new char [BUFFER_SIZE];
    handler->memory->start=0;
    handler->memory->stop=0;
    pthread_mutex_init(&handler->memory->mutex, NULL);
    handler->memory->action=READY;
    return handler;
}

Pomocí debugu jsem zjistil, že ukazatel handler->memory->Buffer spravne ukazuje na nejake misto v pameti (konkretne 0x6126D0) ale po inicializaci funkci pthread_mutex_init se změní adresa na kterou ukazatel Buffer ukazuje na 0X00. Nevíte prosím někdo co dělám špatně? Místo pro pthread_mutex_t(32B) ve strukture je ale funkce pthread_mutex_init z nějakého důvodu přepíše i několik B za zvím místem!

Všem moc díky!

---

---

Odpovědi

[logik]

Zkompilovals to s valgrindem (nebo něčím podobným)? Pokud ne, tak s tím bych začal...

[pou]

Valgrid je dobra rada, ale v podstatě mi řekl jen to co jsem věděl - definitně ztraceny blok paměti na řadku, kde alokuji pamět pro buffer (new char [BUFF_SIZE).

[Sten]

Pokud je to v C, mělo by tam být malloc místo new.

Neběží to na 64-bitovém systému? Tam by měl pthread_mutext_t mít 40 bajtů, takže problém by byl nejspíš s includy nebo nějakými define.

[pou]

Někde jsem se docetl, že pokud se ve struktuře objevuje např std::string není dobre volat na alokaci struktury malloc, protoze se nezavola prislusny konstruktor->proto volam radeji new - je pravda ze u bufferu muzu volat i malloc ale to je asi jedno.

Ano systém je 64b. Jak napravit ty špatny includy??

[Sten]

std::string ani konstruktory nejsou v C, jen v C++. V C++ bych nedělal žádné takovéhle struktury, ale pořádné objekty.

Jakým způsobem to kompilujete?

[benn]

Píšeš, že je to v C, tak zkusit nahradit new za malloc. Zda to dělá podobnou neplechu. U malloc vyloženě musíš určit velikosti. Pak se uvidí

HANDLER * handler;
handler                 = (HANDLER*) malloc(sizeof(HANDLER));
handler->memory         = (MEMORY*)  malloc(sizeof(MEMORY));
handler->memory->Buffer = (char*)    malloc(BUFFER_SIZE);

Pak snad prohodit ty definovaný struktury.

[DK]

malloc(BUFFER_SIZE * sizeof(char))

[Jakub Galgonek]

To není nutné, sizeof(char) je vždy jedna.

[Jardík]

Stejně tak přetypovávat jak kokot z void* na cokoliv*.

[rastos]

Ten kód v povodnej otázke nie je C, ale C++. C kompilátor by mu nadával na kľúčové slovo "new" na použitie "MEMORY" miesto "struct MEMORY" v definícii štruktúry HANDLER a podobne. S C kompilátorom by sa nedostal k tomu, aby to debugoval a videl kam ukazuje Buffer. Pri kompilovaní s C++ kompilácia prejde, ale ani tam nie je žiaden problém s prepisovaním pamäte.

Tak, ako to je napísané, je hodnota Buffer po vykonaní pthread_mutex_init() nedotknutá. Zádrhel je niekde inde. Niečo, čo tu v tom kóde nevidíme, tam urobí bordel.

[Michal Kubeček]

Zádrhel je niekde inde. Niečo, čo tu v tom kóde nevidíme, tam urobí bordel.

Souhlasím. Aby bylo možné určit, kde je problém, chtělo by to kompletní zdroják(y) (stačí minimalistický testcase, kde se to projevuje) a informaci, jak se to přesně překládalo a linkovalo (a na jaké architektuře).

[pou]

kus zdrojáku je v úvodním příšpěvku, jinde už jen volám tuto funkci a pristupuji k té struktuře, problém je (jak jsem psal) v té inicializační funkci, že inicializace mutexu přepíše ukazatel na tu přidělenou pamět.

A v tomto případě si myslím, že je jedno jestli tu pamět získám pomocí malloc nebo new.

kompiluji pomocí:

g++ -c -m64 -pipe -g -Wall -W -I/usr/share/qt4/mkspecs/linux-g++-64 -o test.o ../test.cpp

jinak sizeof mutexu vraci 32b

Honza

[pou]

OMLOUVAM SE!!! jinak sizeof(pthread_mutex_t) vraci 40

[Jakub Galgonek]

To s tím minimalistickým testcasem je ale dobrá rada. Při jeho vytváření dost možmá tu chybu najdeš sám. A i kdyby ne, tak ti pak více více lidí může pomoci s jejím hledáním.

[Michal Kubeček]

kus zdrojáku je v úvodním příšpěvku, jinde už jen volám tuto funkci a pristupuji k té struktuře, problém je (jak jsem psal) v té inicializační funkci, že inicializace mutexu přepíše ukazatel na tu přidělenou pamět.

A právě proto je potřeba vidět celý zdroják, protože pravděpodobné vysvětlení je, že na různých místech se pracuje s různým layoutem některé z těch struktur. Kvůli tomu by bylo dobré vidět celý soubor (resp. celé soubory, pokud to není v jednom).

A v tomto případě si myslím, že je jedno jestli tu pamět získám pomocí malloc nebo new.

To nepopírám. Problém by byl, kdybyste alokoval jedním a zkusil uvolnit druhým, ale to by se samozřejmě projevovalo jinak.

kompiluji pomocí:

g++ -c -m64 -pipe -g -Wall -W -I/usr/share/qt4/mkspecs/linux-g++-64 -o test.o ../test.cpp

Pokud používáte pthreads (což podle toho mutexu používáte), mělo by se všechno kompilovat s -pthread

[rastos]

Příloha:

• testcase.cpp (903 bytů)

Test case je v prílohe. A jeho výstupom je:

allocated       0x82a3048
before pthread_mutex_init()     0x82a3048
after pthread_mutex_init()      0x82a3048
after init_handler()    0x82a3048

[Michal Kubeček]

To ovšem znamená, že ten testcase nedemonstruje ten problém…

[rastos]

To znamená, že problém nie je v tom kóde, ktorý tu vidíme.

[Michal Kubeček]

Aha, pardon, nějak jsem automaticky předpokládal, že ten testcase sem dával tazatel. :-)

[pou]

Takže jsem zkusil testcase.cpp a vse funguje, patral jsem kde je tedy problem, nasel - přiznávám, je to moje blbost :-/.

Problém byl v tom, že program kompiluji i pro ARM, a tak mám nastavené u vývojového prostředí cesty i k tem ARM knihovnám -> ted kdyz muj kod zkompiluji se správnými cestami vse funguje bez problému.

Sam bych asi na tuto "moji hloupost" nepřišel.

Děkuji!! Vsem

[Radek Isa]

pthread_mutex_init(&(handler->memory->mutex), NULL); nevim ktery operator ma prednost &a->b tak to skus napsat &(a->b)

[pavlix]

Pokud C/C++ denně nepoužíváš, stačí se podívat na tabulku operátorů dle priority a nemusí se pak ani upravovat kód ani psát takovéto příspěvky.

[Michal Kubeček]

Doplnil bych, že ve většině případů funguje pravidlo, že autoři C se obvykle řídili zdravým rozumem a tím, co je praktičtější, takže je např. na rozdíl od autora Pascalu nenapadlo dát porovnávání nižší prioritu než logickým spojkám, aby se "a < b && b < c" muselo závorkovat. V tomto případě nemá smysl, aby "&a->b" znamenalo "(&a)->b", protože to lze jednoduše zapsat jako "a.b".

[pavlix]

+1