A_N_K Skrevet 11. desember 2003 Del Skrevet 11. desember 2003 Er det noen som kan si meg om det er noen måte å finne ut, i et program, om kjøringen foregår under kontroll av GDB? Grunnen til at jeg spør er at GDB kan forårsake interrupts, og jeg vil da ignorere disse i visse tilfeller. Lenke til kommentar
daysleper Skrevet 11. desember 2003 Del Skrevet 11. desember 2003 Kan tenke meg at GDB bruker ptrace(). man 2 ptrace Ta forresten også en titt her: http://www.iglu.org.il/lxr/source/arch/i38...l/ptrace.c#L160 if (current->ptrace & PT_PTRACED) Hvis det jeg sier, altså at GDB bruker ptrace(), ser det ut til at det går å sjekke om prossesen (din) blir "tracet". Lenke til kommentar
A_N_K Skrevet 11. desember 2003 Forfatter Del Skrevet 11. desember 2003 Hm.. hvis jeg da skal kunne sjekke om PT_TRACED er satt i current->ptrace, må jeg vel inkludere current.h? Dette blir jo en kjerne-header, kan ikke tenke meg at det er ment å inkluderes i userspace? Lenke til kommentar
daysleper Skrevet 12. desember 2003 Del Skrevet 12. desember 2003 Jeg vet rett og slett ikke. Kanskje det er en annen måte å gjøre det her på? Eventuellt en annen måte å "få tak i" current. Jeg vet ikke nok om dette .. Kanskje ikke helt det du er ute etter, og disse tar stort sett for seg det samme som man-siden til ptrace: http://www.linuxgazette.com/issue81/sandeep.html http://www.linuxgazette.com/issue83/sandeep.html http://www.linuxgazette.com/issue85/sandeep.html http://www.phrack.org/show.php?p=59&a=12 Si fra hvis du finner ut av dette! Lenke til kommentar
daysleper Skrevet 12. desember 2003 Del Skrevet 12. desember 2003 http://www.searchlores.org/cesa_lat.htm http://www.avet.com.pl/pipermail/bugdev/20...une/003872.html Fikk ikke koden til å kompilere sånn med det første - men med litt "forskning" finner du kanskje ut av det. Lenke til kommentar
daysleper Skrevet 12. desember 2003 Del Skrevet 12. desember 2003 eller .. her funka'n ja: #include <stdio.h> #include <sys/ptrace.h> int main() { if(ptrace(PTRACE_TRACEME, 0, 1, 0) < 0) { printf("DEBUGGING... Bye\n"); return(1); } printf("Hello\n"); return(0); } lars@blackbox tests $ ./test3Hello lars@blackbox tests $ gdb test3 GNU gdb 6.0 Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /mnt/home/lars/tests/test3 DEBUGGING... Bye Program exited with code 01. (gdb) ..stilig! Lenke til kommentar
A_N_K Skrevet 12. desember 2003 Forfatter Del Skrevet 12. desember 2003 Heheh, interessant løsning. Men tror ikke jeg ville puttet noe sånt i produksjonskode : | Lenke til kommentar
daysleper Skrevet 12. desember 2003 Del Skrevet 12. desember 2003 Åh? Hvorfor det? Hva er galt? Fra man -siden til ptrace: ...blablabla.. on error -1 is returned and errno is set .. errno: EPERM The specified process cannot be traced. This could be because the parent has insufficient privileges; non-root processes cannot trace processes that they cannot send signals to or those running setuid/setgid programs, for obvious reasons. Alternatively, the process may already be being traced, or be init (pid 1). Har du noen annen løsning? -- Si i fra hvis du finner noe bedre da .. Lenke til kommentar
daysleper Skrevet 12. desember 2003 Del Skrevet 12. desember 2003 Dessuten så er det vel uansett meningen å fjerne slik debuggings-spesifik kode når du skal "release" programvaren. Ikke at jeg vet helt hva du skal lage da.. Lenke til kommentar
A_N_K Skrevet 12. desember 2003 Forfatter Del Skrevet 12. desember 2003 (endret) Det er ikke meningen at det skal fjernes, det er til hjelp hvis man skulle trenge å debugge (blir vel aldri bugfritt ). Men jeg er redd for bieffekter ved å kalle ptrace: Any signal (except SIGKILL) delivered to this process will cause it to stop and its parent to be notified via wait; dessuten er det et bibliotek, koden bør helst være fri for noe tvilsomme løsninger. Edit: Jeg burde kanskje utdype hva jeg vil gjøre for noe. Tingen er at jeg har en bakgrunnstråd som poller på en deskriptor, og jeg vil gjerne at den skal fortsette å polle selv under debugging. Kan jo opprette en konstant som bestemmer om jeg skal ignorere EINTR eller ikke. Endret 12. desember 2003 av A_N_K Lenke til kommentar
daysleper Skrevet 12. desember 2003 Del Skrevet 12. desember 2003 En ennå enklere løsning: #include <stdio.h> #include <signal.h> #include <stdlib.h> static volatile int yup = 0; static void handler(int signo) { yup = 1; } int main(int argc, char *argv[]) { signal(SIGTRAP, handler); raise(SIGTRAP); if (yup == 0) { printf("Yup -- her har vi en debugger.\n"); return(1); } printf("Hello\n"); return(0); } lars@blackbox tests $ ./test3Hello lars@blackbox tests $ gdb test3 GNU gdb 6.0 Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /mnt/home/lars/tests/test3 Program received signal SIGTRAP, Trace/breakpoint trap. 0x401337f1 in kill () from /lib/libc.so.6 (gdb) c Continuing. Yup -- her har vi en debugger. Program exited with code 01. (gdb) Duger denne da? Lenke til kommentar
daysleper Skrevet 12. desember 2003 Del Skrevet 12. desember 2003 Angående dette med bakgrunnstråder og polling av deskriptorer så hadde jeg muligens et lignende problem (blokking) som jeg løste ved å bruke asynkrone sockets og signals fremfor de kanskje mer vanlige select og poll (og/eller bakgrunnstråd(er)) -baserte løsningene: Fra tcpscheme.cpp : /// Set the socket to non-blocking and asyncronous if(fcntl(_sd, F_SETFL, O_NONBLOCK | O_ASYNC) == -1) { perror("TCPScheme::open(): " + __LINE__); return; } /// Set the signals from this filedescriptor/socket to be sent to this process if(fcntl(_sd, F_SETOWN, getpid()) == -1) { perror("TCPScheme::open(): " + __LINE__); return; } /// Set the action to perform on SIGIO //sa_io = new struct sigaction; struct sigaction sa_io; sa_io.sa_sigaction = &sigioRoute; // sa_io.sa_mask = mask of (other) signals to block during handling; sa_io.sa_flags = SA_SIGINFO; if(sigaction(SIGIO, &sa_io, 0) == -1) { perror("TCPScheme::open(): " + __LINE__); return; } // Handle SIGPIPE sa_io.sa_sigaction = &sigioRoute; // sa_io.sa_mask = mask of (other) signals to block during handling; sa_io.sa_flags = SA_SIGINFO; if(sigaction(SIGPIPE, &sa_io, 0) == -1) { perror("TCPScheme::open(): " + __LINE__); return; } // Connect if(((connect(_sd, (struct sockaddr *)&server_addr, sizeof(struct sockaddr))) == -1) // Did it return an error? && (errno != EINPROGRESS)) { // and was the error something else than EINPGROGRESS? perror((toString("TCPScheme::open(): ") + toString(__LINE__)).c_str()); return; } sigioRoute ser slik ut: Fra sigiohandler.cpp : void sigioRoute(int signal, siginfo_t *siginfo, void *unknown) // {{{ { switch(siginfo->si_code) { case POLL_IN: //std::cerr << "sigioRoute::POLL_IN" << std::endl; ::_socket_delegation[siginfo->si_fd]->poll_in(); break; case POLL_OUT: //std::cerr << "sigioRoute::POLL_OUT" << std::endl; ::_socket_delegation[siginfo->si_fd]->poll_out(); break; case POLL_PRI: std::cerr << "sigioRoute::POLL_PRI" << std::endl; ::_socket_delegation[siginfo->si_fd]->poll_pri(); break; case POLL_ERR: std::cerr << "sigioRoute::POLL_ERR" << std::endl; ::_socket_delegation[siginfo->si_fd]->poll_err(); break; case POLL_MSG: std::cerr << "sigioRoute::POLL_MSG" << std::endl; ::_socket_delegation[siginfo->si_fd]->poll_msg(); break; case POLL_HUP: std::cerr << "sigioRoute::POLL_HUP" << std::endl; ::_socket_delegation[siginfo->si_fd]->poll_hup(); break; } // switch } // sigioRoute() // }}} Koden er som du sikkert skjønner muligens tatt fra en litt annen sammenheng og er skrevet i C++ fremfor C, men det skulle ikke ha noen betydning siden, som du ser; jeg bruker standard Linux-funksjoner. Den ligger her: http://scm.nostdal.net/cgi-bin/viewcvs.cgi...ra/oxymora/com/ Vet ikke om dette passer for ditt bruk eller om koden er noe god i det hele tatt, men dette fungerer fint for mitt bruk. Lenke til kommentar
A_N_K Skrevet 12. desember 2003 Forfatter Del Skrevet 12. desember 2003 (endret) Jeg liker ikke helt denne kommentaren: 'The effects of this call in a multi-threaded process are unspecified', dette foregår i en bakgrunnstråd. Dessuten vil jeg blokke for en eventuell annen signalhåndterer? Edit: Ok, var en grei alternativ framgangsmåte. Men jeg tror ikke det er løsningen i mitt tilfelle, det ville innebære en total omstrukturering med minimal gevinst. Dessuten er jeg potensielt avhengig av at flere deskriptorer blir ferdige, innen en viss tid, så jeg vet ikke hvor lett det ville være å oversette til asynkron behandling. Og jeg vet ikke om det er lurt å manipulere en fildeskriptor jeg ikke eier (tilhører underliggende bibliotek). Endret 12. desember 2003 av A_N_K Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå