Project

General

Profile

Actions

Bug #1322

closed

panic with high signal load

Added by josepht over 15 years ago. Updated over 15 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

Description

I managed to panic the kernel while doing some testing using signals.
The application was doing the following:

fork child

child sets up signal handler for SIGHUP then loops forever calling
pause().

parent set up signal handler for SIGHUP then parent loops count number
of times sending a SIGHUP to the child then calls pause().

child's SIGHUP handler just sends a SIGHUP to the parent.
parent's SIGHUP handler calculates the round-trip time for the signal.

This appears to work fine for count < 1000 or so. I tried an
iteration where count = 5000 and panic'ed the kernel. I was unable to
get the panic message from the serial console but was able to get the
following trace from DDB:

db> trace
Debugger(c03d444f) at Debugger+0x34
panic(c03c8398,c040a210,c03c7238,d2684d58,2) at panic+0x9f
userret(6,0,0,d2684d58,c041f11c) at userret+0x16a
syscall2(d8c9dd40) at syscall2+0x2d6
Xint0x80_syscall() at Xint0x80_syscall+0x36

I can attempt to reproduce this if needed and can also provide the
source for the application. I still have the debug kernel but wasn't
able to glean any useful information from it myself.

Thanks,
Joe

Actions

Also available in: Atom PDF