| Summary: | panic in aio_process | ||
|---|---|---|---|
| Product: | Base System | Reporter: | mdiclaud <mdiclaud> |
| Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 3.4-RELEASE | ||
| Hardware: | Any | ||
| OS: | Any | ||
State Changed From-To: open->feedback Does this problem still occur in newer versions of FreeBSD, such as 4.3-RELEASE? State Changed From-To: feedback->closed Automatic feedback timeout. If additional feedback that warrants the re-opening of this PR is available but not included in the audit trail, please include the feedback in a reply to this message (preserving the Subject line) and ask that the PR be re-opened. |
the system panics with fatal trap 12 in aio_process when the file is close(2)'ed and there are outstanding aio requests. Fix: it works fine if close is called after the loop that is doing the aio_error and aio_return calls, which is where it belongs to begin with. How-To-Repeat: the problem occurred in a program i'm developing and the aio is mixed in with lots of other stuff. this code-like sample illustrates what i'm doing which is causing the problem. the code is zeroing the disk. if you need the exact code, let me now struct aiocb x[100]; int outstanding[100]; open(/dev/rda0) for(i=0;i<100;i++) { /* setup x[ i ] values */ aio_write(&x[i]); outstanding[i]=1; } close(/dev/rda0); /* bad thing to do here */ while( requests outstanding ) for(i=0;i<100;i++) { if( aio_error(&x[i]) == EINPROGRESS ) continue; if( outstanding[i] ) { aio_return(&x[i]); outstanding[i]=0; /* setup array for aio_suspend */ } } aio_suspend(); } exit();