signals

signals

Post by Martin Schmid » Thu, 22 Feb 2001 18:43:04



Hi,

I have difficulties with a Termination on signal 11 error .
Someone told me that this points to a misuse of memory
and indeed as tried to avoid the signal with
signal(11,SIG_IGN)
i got a segmentation fault .
Is there a way to use a signalhandler to get more
information about the place where the misuse of memory
occoured ?

Thanks in advance,
Martin

 
 
 

signals

Post by benoit mordele » Thu, 22 Feb 2001 19:04:48



> Hi,

> I have difficulties with a Termination on signal 11 error .
> Someone told me that this points to a misuse of memory
> and indeed as tried to avoid the signal with
> signal(11,SIG_IGN)
> i got a segmentation fault .

signal 11 is SIGSEGV (segmentation violation). you can read in signal(2)
man page:

According  to  POSIX, the behaviour of a process is undefined after it
ignores a SIGFPE, SIGILL, or SIGSEGV signal that was not generated by
the kill() or the raise() functions.

Quote:> Is there a way to use a signalhandler to get more
> information about the place where the misuse of memory
> occoured ?

just let your application crash and hope that it will generate a core
file you can then examin where the problem is with :

gdb application core
where

Quote:

> Thanks in advance,
> Martin

ben

 
 
 

signals

Post by Koushik Banerje » Fri, 23 Feb 2001 01:30:32




> > Hi,

> > I have difficulties with a Termination on signal 11 error .
> > Someone told me that this points to a misuse of memory
> > and indeed as tried to avoid the signal with
> > signal(11,SIG_IGN)
> > i got a segmentation fault .

> signal 11 is SIGSEGV (segmentation violation). you can read in signal(2)
> man page:

> According  to  POSIX, the behaviour of a process is undefined after it
> ignores a SIGFPE, SIGILL, or SIGSEGV signal that was not generated by
> the kill() or the raise() functions.

> > Is there a way to use a signalhandler to get more
> > information about the place where the misuse of memory
> > occoured ?

> just let your application crash and hope that it will generate a core
> file you can then examin where the problem is with :

> gdb application core
> where

> > Thanks in advance,
> > Martin

> ben

you can proceed as benoit has said , but this applies only if your
application is generating core files, if it is not, then the best way is
to
bash% gdb application
and then set break point at either the main method and proceed step by
step(becoz at times even the stack gets deleted)
or else just run the application in gdb and type backtrace or where to
see where it failed.
 
 
 

signals

Post by Nate Eldredg » Fri, 23 Feb 2001 03:30:00



> Hi,

> I have difficulties with a Termination on signal 11 error .
> Someone told me that this points to a misuse of memory

Yes.  Signal 11 is SIGSEGV => Segmentation Fault.  It indicates you've
accessed memory you don't own.

Quote:> and indeed as tried to avoid the signal with
> signal(11,SIG_IGN)

That merely masks the bug you have, and doesn't help fix it at all.
Don't do this.

Quote:> i got a segmentation fault .
> Is there a way to use a signalhandler to get more
> information about the place where the misuse of memory
> occoured ?

Run your program under a de*.  When the signal hits, you'll drop
back into the de*, and can then examine what was happening at the
time.

--

Nate Eldredge

 
 
 

signals

Post by Arthur H. Gol » Fri, 23 Feb 2001 04:50:42




> > Hi,

> > I have difficulties with a Termination on signal 11 error .
> > Someone told me that this points to a misuse of memory

> Yes.  Signal 11 is SIGSEGV => Segmentation Fault.  It indicates you've
> accessed memory you don't own.

> > and indeed as tried to avoid the signal with
> > signal(11,SIG_IGN)

> That merely masks the bug you have, and doesn't help fix it at all.
> Don't do this.

Actually, do it if you want...it'll have no effect. You
can't ignore a SIGSEGV.
Quote:

> > i got a segmentation fault .
> > Is there a way to use a signalhandler to get more
> > information about the place where the misuse of memory
> > occoured ?

Well, there is, but it's probably not what you want. Unless
you know _exactly_ what you're doing, you can't reasonably
recover from it anyway.
Quote:

> Run your program under a de*.  When the signal hits, you'll drop
> back into the de*, and can then examine what was happening at the
> time.

Further hint: if you discover that your SIGSEGV has occurred
in a malloc() or free(), for example, you've most likely
overrun a buffer somewhere (munging the allocator's internal
state or the meta-data attached to an allocated object)
_before_ the SIGSEGV actually occurs.

HTH,
--ag
--
Artie Gold, Austin, TX  (finger the cs.utexas.edu account
for more info)

--
Verbing weirds language.

 
 
 

signals

Post by Martin Schmid » Fri, 23 Feb 2001 19:12:56





> you can proceed as benoit has said , but this applies only if your
> application is generating core files, if it is not, then the best way is
> to
> bash% gdb application
> and then set break point at either the main method and proceed step by
> step(becoz at times even the stack gets deleted)
> or else just run the application in gdb and type backtrace or where to
> see where it failed.

Thanks for help all,

It seems that my case is a very unfortunate one. I wont get a core dump.
If i try to run the program with gdb i will get a crash at the points where
the Signal normally appears. Once crashed i was unable to get out of the
program other than rebooting. I even tried to telnet and than kill the
process with kill -9 process which wouldnt work. The program im working
on has a graphics output (window mode is not available) so to go step by
step
through the program seems no option too . Another konsole isnt available
once the program is started , because the library im working with turns off
switchig with ctrl + alt + fkey.

Martin

 
 
 

signals

Post by benoit mordele » Fri, 23 Feb 2001 20:25:24



> Thanks for help all,

> It seems that my case is a very unfortunate one. I wont get a core dump.

there is a linux system call (it's a real shame that I don't remember
it's name) that forces core dumping. maybe you should search for that
function and use it as a signal handler for SIGSEGV (with some prototype
adaptation perhaps).

ben

 
 
 

signals

Post by Friedrich Dominicu » Fri, 23 Feb 2001 22:14:31




> > Thanks for help all,

> > It seems that my case is a very unfortunate one. I wont get a core dump.

> there is a linux system call (it's a real shame that I don't remember
> it's name) that forces core dumping.

abort(3)

Regards
Friedrich

 
 
 

signals

Post by Koushik Banerje » Fri, 23 Feb 2001 23:49:36





> > > Thanks for help all,

> > > It seems that my case is a very unfortunate one. I wont get a core dump.

> > there is a linux system call (it's a real shame that I don't remember
> > it's name) that forces core dumping.
> abort(3)

> Regards
> Friedrich

there is one more way,easy but boring is to put some cout' in the code
and then u figure out with close proxomity as to where it fails. maybe
put them around malloc() or free() calls...mostly would happen there ..
 
 
 

signals

Post by benoit mordele » Sat, 24 Feb 2001 01:18:08



> you can proceed as benoit has said , but this applies only if your
> application is generating core files, if it is not, then the best way is

that makes me wonder : when is the core file dumped (and when isn't it
dumped) ? I noticed that both cases happen when doing a segmentation
violation. what about SIGFPE or other usually fatal signals ?

will that piece of code always generate a core file ?

void crash(void)
{
        float foo = 0.0;
        float bar = 1.0;
        bar /= foo;

Quote:}

ben
 
 
 

signals

Post by Chronos Tachyo » Sat, 24 Feb 2001 02:28:11




> > you can proceed as benoit has said , but this applies only if your
> > application is generating core files, if it is not, then the best way is

> that makes me wonder : when is the core file dumped (and when isn't it
> dumped) ? I noticed that both cases happen when doing a segmentation
> violation. what about SIGFPE or other usually fatal signals ?

> will that piece of code always generate a core file ?

> void crash(void)
> {
> float foo = 0.0;
> float bar = 1.0;
> bar /= foo;
> }

> ben

The signal(7) manpage says that the following signals dump core: SIGABRT,
SIGFPE, SIGSEGV, SIGTRAP.

--
Chronos Tachyon
Guardian of Eristic Paraphernalia
Gatekeeper of the Region of Thud
[Reply instructions:  My real domain is "echo <address> | cut -d. -f6,7"]

 
 
 

signals

Post by Bori » Sat, 24 Feb 2001 03:12:36




Quote:

> [...]
> It seems that my case is a very unfortunate one. I wont get a core dump.

Try this in the shell: ulimit -c
What does it say? If it's 0 it means applications are not allowed to create
core dumps.

Boris

 
 
 

signals

Post by benoit mordele » Sat, 24 Feb 2001 04:30:51



> The signal(7) manpage says that the following signals dump core: SIGABRT,
> SIGFPE, SIGSEGV, SIGTRAP.

you're right, it's in this man page. but it sometimes happens to some
apps to terminate with this message "Segmentation Fault" without dumping
core. at least it happened to me... weird...

ben

 
 
 

signals

Post by Chronos Tachyo » Sat, 24 Feb 2001 12:00:51




> > The signal(7) manpage says that the following signals dump core:
> > SIGABRT, SIGFPE, SIGSEGV, SIGTRAP.

> you're right, it's in this man page. but it sometimes happens to some
> apps to terminate with this message "Segmentation Fault" without dumping
> core. at least it happened to me... weird...

> ben

Sounds to me like your distro defaults to setting a soft ulimit of 0 for
coredumps.  Slackware does this, I'm not sure what other distros do.  A
"ulimit -Sc unlimited" will turn core dumps on with no maximum size.

--
Chronos Tachyon
Guardian of Eristic Paraphernalia
Gatekeeper of the Region of Thud
[Reply instructions:  My real domain is "echo <address> | cut -d. -f6,7"]

 
 
 

signals

Post by Martin Schmid » Sat, 24 Feb 2001 20:11:17






> > > The signal(7) manpage says that the following signals dump core:
> > > SIGABRT, SIGFPE, SIGSEGV, SIGTRAP.

> > you're right, it's in this man page. but it sometimes happens to some
> > apps to terminate with this message "Segmentation Fault" without dumping
> > core. at least it happened to me... weird...

> > ben

> Sounds to me like your distro defaults to setting a soft ulimit of 0 for
> coredumps.  Slackware does this, I'm not sure what other distros do.  A
> "ulimit -Sc unlimited" will turn core dumps on with no maximum size.

I use Suse 7.0 and ulimit is indeed 0. I can change this temporary with the
above command but when i login the next time ulimit is again 0.
Im getting the core dumped now only if a segmentation fault appears
but not on a termination on signal 11 . What confuses me is that i thought
this is basically the same . Furthermore if i write something like :
signal(11,SignalHandler);
...
void SignalHandler(int dummy)
{
    abort();
    return;

Quote:}

I wont get a core but termination on signal 6 (is this the abort ?) .
I thought abort() had the purpose to force a core dump .
My solution is at that moment to do :
signal(11,SIG_IGN);
to get the segfault rather than the terminate on signal 11 error .

Martin

 
 
 

1. Signal handlers are not reset after signal delivery

The man page for signal says

        Unlike on BSD systems, signals under Linux  are  reset  to
        their  default behavior  when  raised.  However, if you
        include <bsd/signal.h> instead of <signal.h> then signal is
        redefined as __bsd_signal and signal has the BSD
semantics.

However I tried the following simple program and found that if I install
a signal handler once, it remains installed over multiple deliveries of
the same signal. i.e. the signal does not get  reset to its default
behaviour when raised.

#include <stdio.h>
#include <signal.h>

void  handler( int x) {

        printf( "Got the signal\n");

main() {

        char c;
        signal(28, handler);

        sleep(3600);

        printf( "Woke up\n");
        sleep(3600);

and the I did 'kill -28 <pid>' twice. Both the times I got the
message from signal handler.

Can anyone help explain this contradiction or am I messing up
somewhere in the concepts?

Thanks,
-Kartik

2. Networks

3. Signal handling: signal() vs. sigaction()

4. Help with vnode needed.

5. blocking signals in signal handler -- True or False quiz

6. Dialup PPP-domain-resolver guru wanted!

7. ** POSIX signals limited to 32 signals?

8. Deleting rule by pref?

9. Registering signal inside signal handler

10. signal.c: wrong rt signals comment, 2.4.20-pre11

11. signal inside signal

12. trap "<new trap action>; $(get_old_trap SIGNAL)" SIGNAL

13. Registering client data on signal manager side andreceiving it in signal handler