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