[SLUG] K 2.6 help.
If anyone is on a very fresh version of K2.6 with extra patches can you
please run this code and see if it crashes. It fails on all K2.6 up to
Test6 release. I would be interested to hear of any success.
Here is what I get:
Getting from NULL
Setting Jump
Running
Signal 11 caught
After jump
Setting to NULL
Setting Jump
Running
Segmentation fault
There should be no segfault and another signal caught.
If there is any obvious blunder with this code let me know. Looks
pretty right to me though I don't use signals much at all.
--
Thanks
KenF
OpenOffice.org developer
#include
#include
#include
/*
|* Typdeclarations for memory access test functions
*/
typedef int (*TestFunc)( void* );
/*
*/
static jmp_buf check_env;
static int bSignal;
static void SignalHdl( int sig )
{
bSignal = 1;
fprintf( stderr, "Signal %d caught\n", sig );
longjmp( check_env, sig );
}
/*
*/
void check( TestFunc func, void* p )
{
int result;
fprintf( stderr, "Setting Jump\n" );
if ( !setjmp( check_env ) )
{
signal( SIGSEGV, SignalHdl );
signal( SIGBUS, SignalHdl );
fprintf( stderr, "Running \n" );
result = func( p );
fprintf( stderr, "Finished \n" );
signal( SIGSEGV, SIG_DFL );
signal( SIGBUS, SIG_DFL );
}
fprintf( stderr, "After jump \n" );
}
/*
*/
static int GetAtAddress( void* p )
{
return *((char*)p);
}
/*
*/
static int SetAtAddress( void* p )
{
return *((char*)p) = 0;
}
/*
*/
void CheckGetAccess( void* p )
{
check( (TestFunc)GetAtAddress, p );
}
/*
*/
void CheckSetAccess( void* p )
{
check( (TestFunc)SetAtAddress, p );
}
/*
*/
int main( int argc, char* argv[] )
{
{
char* p = NULL;
fprintf( stderr, "Getting from NULL\n" );
CheckGetAccess( p );
fprintf( stderr, "Setting to NULL\n" );
CheckSetAccess( p );
fprintf( stderr, "After Setting to NULL\n" );
}
exit( 0 );
}
--
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug
Re: [SLUG] K 2.6 help.
At Mon, 20 Oct 2003 23:07:40 +1000,Ken Foskey wrote: > If anyone is on a very fresh version of K2.6 with extra patches can you > please run this code and see if it crashes. It fails on all K2.6 up to > Test6 release. I would be interested to hear of any success. > > Here is what I get: > Getting from NULL > Setting Jump > Running > Signal 11 caught > After jump > Setting to NULL > Setting Jump > Running > Segmentation fault > > There should be no segfault and another signal caught. A C program is "undefined" after returning from a SIGSEGV handler. In particular that means its allowed to die in weird ways. (If this was intended for real use, you definately want to rethink your approach. "Testing" addresses for segfaults is always going to get you into trouble) -- - Gus -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: [SLUG] K 2.6 help.
Oh yeah - if you *really* want to do this, fork() first and test in the child. If the child exited with a segfault you know it was a bad idea. -- - Gus -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: [SLUG] K 2.6 help.
On Mon, Oct 20, 2003 at 11:07:40PM +1000, Ken Foskey wrote:
>
> If anyone is on a very fresh version of K2.6 with extra patches can you
> please run this code and see if it crashes. It fails on all K2.6 up to
> Test6 release. I would be interested to hear of any success.
I don't think it's related to the kernel version.
> There should be no segfault and another signal caught.
>
> If there is any obvious blunder with this code let me know. Looks
> pretty right to me though I don't use signals much at all.
The problem is that you never return from the signal handler. Now you're
getting a SIGSEGV during execution of the SIGSEGV handler and the signal is
probably forced to SIG_DFL, otherwise you could get an infinite signal
loop. Return from the handler instead of a longjmp and you should be ok.
/Martin
> #include
> #include
> #include
>
> /*
> |*Typdeclarations for memory access test functions
> */
> typedef int (*TestFunc)( void* );
>
> /*
> */
> static jmp_buf check_env;
> static int bSignal;
> static void SignalHdl( int sig )
> {
> bSignal = 1;
>
> fprintf( stderr, "Signal %d caught\n", sig );
> longjmp( check_env, sig );
> }
>
> /*
> */
> void check( TestFunc func, void* p )
> {
> int result;
>
> fprintf( stderr, "Setting Jump\n" );
> if ( !setjmp( check_env ) )
> {
> signal( SIGSEGV,SignalHdl );
> signal( SIGBUS, SignalHdl );
> fprintf( stderr, "Running \n" );
> result = func( p );
> fprintf( stderr, "Finished \n" );
> signal( SIGSEGV,SIG_DFL );
> signal( SIGBUS, SIG_DFL );
> }
> fprintf( stderr, "After jump \n" );
> }
>
> /*
> */
> static int GetAtAddress( void* p )
> {
> return *((char*)p);
> }
>
> /*
> */
> static int SetAtAddress( void* p )
> {
> return *((char*)p) = 0;
> }
>
> /*
> */
> void CheckGetAccess( void* p )
> {
> check( (TestFunc)GetAtAddress, p );
> }
> /*
> */
> void CheckSetAccess( void* p )
> {
> check( (TestFunc)SetAtAddress, p );
> }
>
> /*
> */
> int main( int argc, char* argv[] )
> {
> {
> char* p = NULL;
> fprintf( stderr, "Getting from NULL\n" );
> CheckGetAccess( p );
> fprintf( stderr, "Setting to NULL\n" );
> CheckSetAccess( p );
> fprintf( stderr, "After Setting to NULL\n" );
> }
>
> exit( 0 );
> }
--
"If there are no stupid questions, then what kind of questions do stupid
people ask? Do they get smart just in time to ask questions?"
- Scott Adams
--
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug
Re: [SLUG] K 2.6 help.
On Tue, 2003-10-21 at 18:43, Martin Johansson wrote:
> On Mon, Oct 20, 2003 at 11:07:40PM +1000, Ken Foskey wrote:
>
> >
> > If anyone is on a very fresh version of K2.6 with extra patches can you
> > please run this code and see if it crashes. It fails on all K2.6 up to
> > Test6 release. I would be interested to hear of any success.
>
> I don't think it's related to the kernel version.
>
> > There should be no segfault and another signal caught.
> >
> > If there is any obvious blunder with this code let me know. Looks
> > pretty right to me though I don't use signals much at all.
>
> The problem is that you never return from the signal handler. Now you're
> getting a SIGSEGV during execution of the SIGSEGV handler and the signal is
> probably forced to SIG_DFL, otherwise you could get an infinite signal
> loop. Return from the handler instead of a longjmp and you should be ok.
The following code behaves the same under K 2.4 and K 2.6 so there is
something different for SEGV to SIGINT. Can anyone explain?
If you run this:
./a.out and hit ^C twice with a delay you get:
$ ./a.out
Hello World
Hello World
OUCH - I got signal 2
Hello World
$
***but***
$ ./a.out x
Hello World
OUCH segv - I got signal 11
Segmentation fault
$
So returning from a segv signal will fail the program.
#include
#include
#include
void ouch_segv( int sig )
{
printf( "OUCH segv - I got signal %d\n", sig );
(void) signal( SIGSEGV, SIG_DFL );
}
void ouch( int sig )
{
printf( "OUCH - I got signal %d\n", sig );
(void) signal( SIGINT, SIG_DFL );
}
int main( int argc, char ** argv )
{
char a;
(void) signal( SIGINT, ouch );
(void) signal( SIGSEGV, ouch_segv );
while( 1 ) {
printf( "Hello World\n" );
fflush( stdout );
if( argc > 1 ) {
a = *((char*)0);
}
sleep( 1 );
}
}
--
Thanks
KenF
OpenOffice.org developer
--
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug
Re: [SLUG] K 2.6 help.
At 10:02 pm, Tuesday, October 21 2003, Ken Foskey mumbled: > The following code behaves the same under K 2.4 and K 2.6 so there is > something different for SEGV to SIGINT. Can anyone explain? > Of course. POSIX Says that behaviour after catching a SIGSEGV is undefined. Anything could happen. If you catch a SIGSEGV and your machine catches fire and jumps out the window, POSIX allows for it. Cheers, -- Steve Unix's elegant and suave design makes it seem slightly older than it really is. * StevenK waits for Unix to have a mid life crisis and start dating operating systems half it's age. StevenK: it's called samba. Mithrandir: Such lack of taste. If you're going to date operating systems half your age, then at least make sure they're bouncy and cute. Maybe it's just a sexual thing. Windows goes down easily, and Unix can stay up forever. -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: [SLUG] K 2.6 help.
On Tue, Oct 21, 2003 at 10:01:16PM +1000, Ken Foskey wrote: > On Tue, 2003-10-21 at 18:43, Martin Johansson wrote: > > On Mon, Oct 20, 2003 at 11:07:40PM +1000, Ken Foskey wrote: > > > > > > > > If anyone is on a very fresh version of K2.6 with extra patches can you > > > please run this code and see if it crashes. It fails on all K2.6 up to > > > Test6 release. I would be interested to hear of any success. > > > > I don't think it's related to the kernel version. > > > > > There should be no segfault and another signal caught. > > > > > > If there is any obvious blunder with this code let me know. Looks > > > pretty right to me though I don't use signals much at all. > > > > The problem is that you never return from the signal handler. Now you're > > getting a SIGSEGV during execution of the SIGSEGV handler and the signal is > > probably forced to SIG_DFL, otherwise you could get an infinite signal > > loop. Return from the handler instead of a longjmp and you should be ok. > > The following code behaves the same under K 2.4 and K 2.6 so there is > something different for SEGV to SIGINT. Can anyone explain? It was a bit more involved than what I remembered, but there are ways to handle SIGSEGV other than abort & dump core. You can handle page faults in user-space for example. Check out http://libsigsegv.sourceforge.net/ /Martin -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: [SLUG] K 2.6 help.
On Mon, 2003-10-20 at 23:07, Ken Foskey wrote: > If anyone is on a very fresh version of K2.6 with extra patches can you > please run this code and see if it crashes. It fails on all K2.6 up to > Test6 release. I would be interested to hear of any success. Unblock the signal handler before you raise the signal again. m. -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
