Unix Programming - incorrect siginfo->si_addr value with solaris gdb

This is Interesting: Free IT Magazines  
Home > Archive > Unix Programming > June 2005 > incorrect siginfo->si_addr value with solaris gdb





You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

Author incorrect siginfo->si_addr value with solaris gdb
abhay_raghu@yahoo.com

2005-06-20, 6:05 pm

Hi

I have run into a problem with gdb on Solaris 2.8 and 2.9 where the
siginfo->si_addr value in a signal handler always has the incorrect
value for a memory exception when run within gdb. The problem has been
seen with gdb 5.0 and gdb 6.

The sample code below can be used to demostrate the problem.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <ctype.h>
#include <signal.h>
#include <ucontext.h>


/////////////////////////////////////////////////////////////////
void exception_handler (int signal, siginfo_t* p_siginfo,
void* p_ignored)
{
void* p_exception_address;
p_exception_address = p_siginfo->si_addr;

printf ("Exception address is %xx\n",
(unsigned int)p_exception_address);

exit (0);
}
////////////////////////////////////////////////////////////////
int main (int argc, char** argv)
{
//Define handler for segv.
int status;
struct sigaction act;
void* exception_address = (void*) 0xe0000012;

memset (&act, 0x00, sizeof(act));

act.sa_sigaction = exception_handler;
act.sa_flags = SA_SIGINFO;
status = sigaction(SIGSEGV, &act, NULL);

if (status)
{
printf ("Failed to setup exception handler.\n");

return (-1);
}

printf ("Setup exception handler.\n");

//Access exception address.
(*(unsigned int *)exception_address) = 1980;

return (0);
}
/////////////////////////////////////////////////////////////////

Compile and run the attached program.

The exception address that is printed out is correct: 0xe0000012.

Run the program within gdb.

An incorrect exception address is printed out.

bash-2.03$ g++ -o segv_handler segv_handler.cpp
bash-2.03$ segv_handler
Setup exception handler.
Exception address is 0xe0000012

bash-2.03$ gdb segv_handler
GNU gdb 5.0
Copyright 2000 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 "sparc-sun-solaris2.8"...

(no debugging symbols found)...

(gdb) handle SIGSEGV nostop noprint

Signal Stop Print Pass to program Description

SIGSEGV No No Yes Segmentation fault

(gdb) r

Starting program: /space/users/rags/segv_handler

Setup exception handler.

Exception address is 14cfx

Program exited normally.


Is there a fix for this problem within gdb?
OR
Is there a register on the sparc that is guaranteed to contain the
fault address like the CR2 register on the x86?

Thanks
Raghu

loic-dev@gmx.net

2005-06-21, 5:53 pm

Salut Raghu,

> I have run into a problem with gdb on Solaris 2.8 and 2.9 where the
> siginfo->si_addr value in a signal handler always has the incorrect
> value for a memory exception when run within gdb. The problem has been
> seen with gdb 5.0 and gdb 6.


There has been some known issues of gdb in the area of signal handling.
See for instance:
http://www.mail-archive.com/bug-gdb...g/msg06781.html

I tried with gdb 6.2.1 on Alpha/Tru64 and Intel/Linux, it worked fine.
Unfortunately, I cannot try on Sparc/Solaris 8 (our Blade server is
currently on strike).

Perhaps it would be good to try a more recent version of gdb?

Cheers,
Loic.

loic-dev@gmx.net

2005-06-21, 5:53 pm

Update!

>
> There has been some known issues of gdb in the area of signal handling.
> See for instance:
> http://www.mail-archive.com/bug-gdb...g/msg06781.html
>
> I tried with gdb 6.2.1 on Alpha/Tru64 and Intel/Linux, it worked fine.
> Unfortunately, I cannot try on Sparc/Solaris 8 (our Blade server is
> currently on strike).
>
> Perhaps it would be good to try a more recent version of gdb?


I tried with gdb 6.3 on Solaris 8, and I got the same problem as you.
Seems to be a gdb / Sparc issue.

Loic.

Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com