Gå til innhold

Anbefalte innlegg

Videoannonse
Annonse

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 .. :dontgetit:

 

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

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 $ ./test3

Hello

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

Å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 .. :dontgetit:

Lenke til kommentar

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 av A_N_K
Lenke til kommentar

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 $ ./test3

Hello

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

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

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 av A_N_K
Lenke til kommentar

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 konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...