GDB 6.8 (diskuse)

[oroborus]

mam pocit,ze v novom GDB je chyba :

mam zdrojak v C :

#include <pthread.h>
#include <stdio.h>
#include <unistd.h>

void* print_pokus(void *unused)
{
  while(1)
  {
	printf(" %s\n", (char *)unused);
  }

  return(NULL);
}

int main()
{
  pthread_t thread_id1;
  pthread_t thread_id2;
  pthread_t thread_id3;
 
  pthread_create(&thread_id1, NULL, &print_pokus, "1");
  pthread_create(&thread_id2, NULL, &print_pokus, "2");
  pthread_create(&thread_id3, NULL, &print_pokus, "3");

   while(1)
   {
 	sleep(1);
   }

   return(0);
}

skompilujem ho :
gcc -Wall -pedantic -g -O0 thread.c -lpthread

spustim pod novym gdb :
gdb ./a.out
break print_pokus
run
continue

( GDB si pameta prikazy a pri odentrovani prazdneho riadka sa pouzije posledny prikaz )

takze drzime enter cca 10 sekund

potom napiseme prikaz :

step

a znovu drzime cca 10 sekund

program skoci na nejake NOPy v zarovnani funkcii a nakoniec sa zruti
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb75d8b90 (LWP 3778)]
0x08048598 in ?? ()
(gdb)
Cannot find bounds of current function

PS:
uznavam, ze ten zdrojak je humus, neukoncujem vlakna, a program nevracia navratovu hodnotu.
Alebo, zeby je to tym, ze je pol dvanastej a som unaveny ?

gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
GNU assembler (GNU Binutils for Debian) 2.18.0.20080103
ln (GNU coreutils) 5.97
GNU gdb 6.8
Linux debian 2.6.24 #1 SMP Fri Jan 25 15:25:01 CET 2008 i686 GNU/Linux
glibc-2.7-6

[Creckx]

A když to napíšeš jako člověk tak to jede ok?:)

[Aleš Kapica]

Doposud jsem měl za to, že GDB je debugger, tzn. že by měl právě ty prasárny odhalit a ne se z nich zhroutit.

[kavol]

to je ovšem zajímavé řešení - jestliže se debugger z příliš velké prasárny zhroutí, autor prasárny ví, že to má přepsat od nuly

[oroborus]

IMHO ten kod je prasacky v tom, ze sa nestara o ukoncenie vlakien, ale preco aj, v procese su 4 vlakna ( 3 explicitne vytvorene ) a v tele vykonavaneho vlakna sa nachadza nekonecny cyklus. Takze porces moze byt preruseny jedine signalom. ( proces ziadne obsluhy signalu nevykonava. )

Ked sa ten program normalne spusti ako ./a.out tak ide

ak sa spusti cez vlagrind (valgrind ./a.out) , tak to tiez ide a nevypisuje to ziadne warningy.

Ak proces debugujem cez GDB-6.6 alebo GDB-6.7 porces sa nezruti.

Zrutenie je sposobene tym, ze EIP ukazuje na skupinu NOP-ov, ktore sa nachadza medzi funkciami a kompilatior ich tam dava ako zarovnanie.
V podstate je prasacky, ale je rovnako prasacky ako "Hello world" , tiez tam neobsluhujem signaly. ( viem, ze by sa to odrazilo na preonsitelnosti Hello world.)

A ta prasackost nesposobuje pad sameho seba v GDB. Keby tam aj obsluhy signalov boli, tak by sa nevykonali, lebo v tom pokusnom debagovani iba nadefinujem breakpoint a pri zisteni, ze som na breakpointe ho bud necham bezat dalej alebo ho krokujem

[Ivan]

Nejen GDB, ale i kernel linuxu ma se signaly trochu problem. Pokud trasujete aplikaci, tak neni uplne jasne, ktere signaly maji prijit trasovanemu/trasujicimu procesu. Behem nekolika poslednich releasu kernelu se to chovani melilo. Nekde na strankach mono projektu je o tom obsahlej clanek. Mozna ze jen gdb dostava signal, o kterym si mysli, ze by ho nemelo dostat, anebo jsem uplne mimo.

[alblaho]

Na tom zdrojáku nevidím nic španého... Prostě pár nekonečných smyček.

[michich]

Více threadů zapisuje současně do stejného stdio souboru, bez synchronizace. Netuším, jestli je standardem zaručeno, že to má fungovat.

[Abraxis]

Chodit by to melo, ale holt se muzou navzajem "michat" - coz by nemuselo vadit, ne?

[oroborus]

Dal som tam mutex a to iste :(

pre uplnost pridavam kod :

#include <pthread.h>
#include <stdio.h>
#include <unistd.h>

static pthread_mutex_t mutex;

void* print_pokus(void *unused)
{
  while(1)
  {
	pthread_mutex_lock(&mutex);
	printf(" %s\n", (char *)unused);
	pthread_mutex_unlock(&mutex);
  }

  return(NULL);
}

int main()
{
  pthread_t thread_id1;
  pthread_t thread_id2;
  pthread_t thread_id3;
 
 pthread_mutex_init(&mutex, NULL);

 pthread_create(&thread_id1, NULL, print_pokus, "1");
 pthread_create(&thread_id2, NULL, print_pokus, "2");
 pthread_create(&thread_id3, NULL, print_pokus, "3");

  while(1)
  {
	sleep(1);
  }

  return(0);
}

[alblaho]

Více threadů do jednoho souboru samozřejmě může, stejně jako s jedním souborem běžně pracuje více procesů. Určitě je to POSIXem definované. A zcela určitě tomu tak je i na Woknech. Tohle si prostě řídí jádro samo.

[Miloslav Ponkrác]

Okna jsou _důsledně_ multithreadová. Jsou celá vystavěná na threadech a práce s thready je tam bohužel daleko dokonalejší, než v Linuxu. A každý vývojový nástroj pro okna s tím počítá - a umí s více thready pracovat. Dá se říct, že v Unixech je leccos stavěno na forku, ve Windows na threadech.

Jinak POSIX je jedna věc a standard C/C++ knihoven věc druhá. Oba standardy vznikaly v době, kdy thready nebyly hlavním tahákem. Logicky standardní knihovna C musí být multithreadová, protože programátor v C by se jinak nehnul. Programátor v C by ani netušil, co vše musí synchronizovat proti threadům, protože logicky neznáte vnitřnosti konkrétní implementace standardní knihovny C. Tudíž by se nedala standardní knihovna C vůbec používat. To byste v threadech museli psát pak v C takto:

char* string;

ziskej_mutex()
string = malloc(100);
if (string != NULL)
  memcpy(string,zdroj,100);
vrat_mutex();

...

ziskej_mutex();
free(string);
vrat_mutex();

Céčko by bylo zhola nepoužitelné, pokud by C knihovna nebyla vnitřně multithreadová.

[Miloslav Ponkrác]

Také nevidím na zdrojáku nic špatného. A standardní knihovna C - u té automaticky předpokládám, že je multithreadová a pokud není, tak vyměním kompilátor i s knihovnou za něco pořádného.

A navíc na testování je zdroják zcela ok - předpokládám-li standardní funkce knihovny multrithreadové, pak ke kolapsu docházet nebude, maximálně k pomíchanému výstupu s neurčeným pořadím, a ten je pro tento test stejně nepodstatný.

A pokud se zhroutí debugger u _jakéhokoli_ zdrojáku, pak je to špatný debugger. Jiný závěr nelze určit.

[David Watzke]

pokud se zhroutí debugger u _jakéhokoli_ zdrojáku, pak je to špatný debugger

Nebo je v něm prostě chyba, že?

[Miloslav Ponkrác]

Nebo je v něm chyba

Nezlobte se na mě, ale já u programovacích nástrojů trávím značný čas - a první, naprosto první požadavek na ně je spolehlivost. Nechci už zažít (jak se mi kdysi stávalo s Borlandskými kompilátory) situace, kdy chybu hledám nejen v sobě, ale také prověřuji vývojové nástroje a hraju si na jejich alfatestera. Raději oželím cokoli jen proto, abych se mohl na vývojové nástroje na 100% spolehnout.

A zde se rozmáhá nešvar na abclinuxu jásat nedávno nad linkerem, který linkuje několikrát rychleji - co na tom, že neumí spolehlivě linkovat - kdo by se zdržoval takovou maličkostí, že? Teď se propaguje debugger, který se hroutí při debugování.

Copak nikdo nechápe, že právě chyby ve vývojových nástrojích se promítají do spolehlivosti všech programů, které vyvíjíte? Třeba zlikvidovat celý Linux se vším všudy stačí malá dlouho neobjevená, ale přesto závažná chyba v gcc kompilátoru. Zvláště s linux tendencí vše znovu zkompilovat by to bylo zvláště efektivní a rychlé odstřelení celé linuxové srandy.

[David Watzke]

A zde se rozmáhá nešvar na abclinuxu jásat nedávno nad linkerem, který linkuje několikrát rychleji - co na tom, že neumí spolehlivě linkovat - kdo by se zdržoval takovou maličkostí, že?

Jásalo se nad tím, že se novej a rychlej linker vyvíjí, nevím co je na tom za nešvar. Třeba já z něj mám radost, ale nepoběžím si ho hned nainstalovat.

[alblaho]

pokud se zhroutí debugger u _jakéhokoli_ zdrojáku, pak je to špatný debugger

Nebo je v něm prostě chyba, že?

Přemýšlím, jestli lze udělat debugger pro nativní kód, který přežije libovolně ošklivé chování laděného programu...

Ale jinak, Miroslave, s tou spolehlivostí programátorských nástrojů, to máte pravdu. Kdysi jsem narazil na chybu v Borland C++ Builderu, kdy pořádně nefungovala šablona std::list, no to byl vomrd.

Proto mám rád GCC. Jistě má své chyby, ale žiju s vědomím, že když to přeloží kompletní linuxovou distribuci, tak to snad nezhučí na mém tic-tac-toe, alébrž vygeneruje validní kód

[Miloslav Ponkrác]

Vzhledem k tomu, že debugger běží v odděleném procesu, tedy v jiném, než je laděný proces, tak nevím, proč by byl takový problém udělat festovní spolehlivý debugger. Jak dokazují řady jiných debuggerů. Navíc, když stejně hlavní práci udělá jádro operačního systému.

Jinak s názorem na gcc souhlasím. Sice do gcc občas šiju, ale v zásadě ho mám rád a jsem moc rád, že gcc projekt vůbec existuje. A nejenom kvůli C/C++, ale také kvůli Adě.

Jinak na Windows používám Microsoftí komplátor, který je také spolehlivý, dokonce generuje lepší kód, než gcc, ale MS to nějak zhoršuje. V MS kompilátoru v 64 bitovém režimu už není inline asm, funkce standardní knihovny Céčka MS svévolně označuje za deprecated a hází warningy, není schopen spočítat jako konstanty některé výrazy na rozdíl od GCC (třeba 0.0/0.0), a bohužel MS kompilátor nepodporuje na x86 platformě 80 bitový floating point (long double = 64 bitů). A verze od verze jde MS kompilátor do kopru a postupně se ubírají featury. Takže i proto jsem rád, že gcc je i na Windows. Na druhé straně MS kompilátor je velmi příjemný a přátelský, je schopen lépe a důkladněji hledat chyby, než gcc (gcc je schopno chybu označit o 30 řádků vedle, než skutečně je a popsat jí tak krypticky, že se nedá najít). MS kompilátor v debug režimu odhalí tak neskutečně moc problémů a chyb i za běhu, že je to to hlavní spolu s příjemností jeho IDE hlavní důvod proč ho používám. Je velmi častá situace, kdy mi program padá a já za boha nemůžu několik dní na to přijít proč, tak převedu projekt z gcc pod MS kompilátor a většinou do minuty je mi označen problém a řádka, kde je chyba (týká se i memory leaků, chybného volání STL knihovny, chyb na zásobníku, špatné synchronizace threadů, atd.).

[oroborus]

Este som spravil jeden test, ked kazde jedno vlakno pouziva inu funkciu vsetko ide OK, ale ak viac vlakien pouziva jednu funkciu ( priklad hore) debugovany program sa zruti.

pozrel som si coredump a nasiel som tam toto :

0x080484f4 <print_pokus+0>:     push   %ebp
0x080484f5 <print_pokus+1>:     mov    %esp,%ebp
0x080484f7 <print_pokus+3>:     sub    $0x8,%esp
0x080484fa <print_pokus+6>:     int3
0x080484fb <print_pokus+7>:     add    $0x24,%al
0x080484fd <print_pokus+9>:     int3
0x080484fe <print_pokus+10>:    xchg   %eax,%edi
0x080484ff <print_pokus+11>:    add    $0x8,%al
0x08048501 <print_pokus+13>:    call   0x8048440 <pthread_mutex_lock@plt>
0x08048506 <print_pokus+18>:    int3
0x08048507 <print_pokus+19>:    inc    %ebp
0x08048508 <print_pokus+20>:    or     %cl,0xc7042444(%ecx)
0x0804850e <print_pokus+26>:    add    $0x24,%al
0x08048510 <print_pokus+28>:    cwtl
0x08048511 <print_pokus+29>:    xchg   %al,(%eax,%ecx,1)
0x08048514 <print_pokus+32>:    call   0x8048420 <printf@plt>
0x08048519 <print_pokus+37>:    movl   $0x80497cc,(%esp)

Pri debugovani debuger dava do strojoveho kodu int3, ked vsak prepne na nejake ine vlakno, zabude tuto intrukciu inemu vlaknu zobrat, cim sa poskodi kod. Ked kazde vlakno poziva svoju vlastnu funkciu, nie su v tej funkcii int3 z debugovani inych vlakien. Samozrejme debuger by mal podporovat debugovat funkcie, ktore su pozivane sucastne viac vlaknami

[Jirka P]

Hm, tak to je dost na pikaču. Kam se dá napsat bugreport? Napsal jste ho (někdo)?

[David Watzke]

gdb --help|grep bugs
Report bugs to "bug-gdb@gnu.org".

[oroborus]

Prave sa chystam napisat bugreport, ale neviem ci to dostatocne opisem mojou LAMAnou anglictinou